MTU handling in 6RD deployments

[Templin, Fred L]

Hi Sander,

> -----Original Message-----
> From: Sander Steffann [mailto:sander at steffann.nl]
> Sent: Thursday, January 16, 2014 2:45 PM
> To: Templin, Fred L
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: MTU handling in 6RD deployments
> 
> Hi,
> 
> > In the reverse direction, when a 6RD BR forwards a packet to a CE
> > router that it hasn't ping'd before (or hasn't ping'd recently),
> > have it ping the CE with a 1520 byte ping. If it gets a reply, set
> > the MTU to the CE to infinity. If it doesn't get a reply, set the
> > MTU to 1480 (or maybe 1472). Again, no fragmentation and reassembly.
> >
> > The only state in the BR then is an MTU value for each CE that it
> > talks to - in the same way ordinary IPv4 nodes maintain a path MTU
> > cache for the destinations they talk to.
> 
> Since we assume that 6RD packets between the BR and the CE go over infrastructure that the ISP
> controls, wouldn't it be easier to just try to send bigger (IPv4) packets from the BR to the CE with
> the DF bit set, and look for PTB messages? On the public internet relying on PTBs might be a bad idea,
> but on controlled infrastructure you might be able to reply on those. If you can raise the MTU to 1520
> you should be able to make PTBs work, right? ;-)  It might save an extra roundtrip with a ping and use
> standard ICMP messages and associated state.

The difference is that a PTB is a negative acknowledgement from a
router on the path from the BR to the CE, while a ping reply is a
positive acknowledgment from the CE itself. But, I failed to mention
that the ping would have DF=1, so it would give advantages of both,
i.e., a negative confirmation if the ping is too big for the path
MTU or a positive confirmation that the path MTU is sufficient.

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.

Thanks - Fred
fred.l.templin at boeing.com
 
> Cheers,
> Sander