MTU handling in 6RD deployments
Templin, Fred L
Fred.L.Templin at boeing.com
Tue Jan 7 19:12:39 CET 2014
Hi Tore,
> -----Original Message-----
> From: Tore Anderson [mailto:tore at fud.no]
> Sent: Tuesday, January 07, 2014 9:57 AM
> To: Templin, Fred L; IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
>
> * Templin, Fred L
>
> > 6RD could use SEAL the same as any tunneling technology. SEAL makes
> > sure that packets up to 1500 get through no matter what, and lets
> > bigger packets through (as long as they fit the first-hop MTU) with
> > the expectation that hosts sending the bigger packets know what they
> > are doing. It works as follows:
> >
> > - tunnel ingress pings the egress with a 1500 byte ping
> > - if the ping succeeds, the path MTU is big enough to
> > accommodate 1500s w/o fragmentation
> > - if the ping fails, use fragmentation/reassembly to
> > accommodate 1500 and smaller
> > - end result - IPv6 hosts always see an MTU of at least 1500
>
> In order for the BR to support reassembly it must maintain state. That's
> going to have a very negative impact on its scaling properties...
A couple of things about this. First, reassembly is used only for packets
in the range of 1280-1500 bytes (smaller and larger packets are passed
w/o fragmentation). Second (and more importantly) reassembly is not needed
for packets of any size if the path can pass a 1500 byte ping packet. So
(as Ole said a few messages back) if the 6rd domain MTU can be made to be
>=1520 the fragmentation and reassembly process is suppressed and only
whole packets are transmitted.
Thanks - Fred
fred.l.templin at boeing.com
> Tore
More information about the ipv6-ops
mailing list