MTU handling in 6RD deployments

[Templin, Fred L]

Hi Mikael,

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike at swm.pp.se]
> Sent: Friday, January 17, 2014 12:24 AM
> To: Templin, Fred L
> Cc: ipv6-ops at lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
> 
> 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.

Thanks for the thought, and I agree that dealing with possible path changes
is required. SEAL says the following:

   "When the ITE is actively sending packets over a subnetwork path to an
   ETE, it also sends explicit probes subject to rate limiting to test
   the path MTU."

I think this might be better than probing once per minute, because it
gives more timely feedback for detecting path MTU changes while packets
are actively flowing and desists if no packets are actively flowing.

Thanks - Fred
fred.l.templin at boeing.com
 
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se