MTU handling in 6RD deployments

[Templin, Fred L]

Hi Mark,

> -----Original Message-----
> From: Mark Townsley [mailto:mark at townsley.net]
> Sent: Friday, January 17, 2014 12:41 AM
> To: Mikael Abrahamsson
> Cc: Templin, Fred L; ipv6-ops at lists.cluenet.de
> Subject: Re: MTU handling in 6RD deployments
> 
> 
> On Jan 17, 2014, at 9:24 AM, Mikael Abrahamsson wrote:
> 
> > On Thu, 16 Jan 2014, Templin, Fred L wrote:
> >
> >> The key is that we want to probe the path between the BR and CE (in both directions) *before*
> allowing regular data packets to flow. We want to know ahead of time whether to allow large packets
> into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or something) and clamp the
> MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a degenerate MTU indefinitely
> or at least for a long time.
> >
> > This method makes some sense, but since network conditions can change, I would like to see periodic
> re-checks of the tunnel still working with the packet sizes, perhaps pinging itself over the tunnel
> once per minute with the larger packet size if larger packet size is in use.
> 
> Section 8 of RFC 5969 could be relevant here.

In that section, I see:

   "The link-local
   address of a 6rd virtual interface performing the 6rd encapsulation
   would, if needed, be formed as described in Section 3.7 of [RFC4213].
   However, no communication using link-local addresses will occur."

So, if we were to construct the pings from the IPv6 level we would
want to use link-local source and destination addresses. But, that
raises a question that would need to be addressed - should the pings
be constructed at the IPv6 level, the IPv4 level, or some mid-level
like SEAL?

One other thing about this is that we are specifically not testing
to determine an exact path MTU. We are only trying to answer the
binary question of whether or not the tunnel can pass a 1500 byte
IPv6 packet.

Thanks - Fred
fred.l.templin at boeing.com

> - Mark
> 
> >
> > --
> > Mikael Abrahamsson    email: swmike at swm.pp.se