MTU handling in 6RD deployments

Sander Steffann sander at
Thu Jan 16 23:45:03 CET 2014


> 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.


More information about the ipv6-ops mailing list