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

http://tools.ietf.org/html/draft-templin-intarea-seal

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

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com at lists.cluenet.de] On Behalf Of Tore Anderson
> Sent: Tuesday, January 07, 2014 3:38 AM
> To: IPv6 Ops list
> Subject: MTU handling in 6RD deployments
> 
> Hi list,
> 
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any problems stemming
> from the reduced IPv6 MTU? Some possibilities that come to mind are:
> 
> * Having the 6RD CPE lower the TCP MSS value of SYN packets as they
> enter/exit the tunnel device
> * Having the 6RD BR lower the TCP MSS value in the same way as above
> * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options
> * Several (or all) of the above in combination
> 
> Also, given that some ISPs offer [only] Layer-2 service and expect/allow
> their customers to bring their own Layer-3 home gateway if they want
> one, I would find it interesting to learn if any of the most common
> off-the-shelf home gateway products (that enable 6RD by default) also
> implement any such tricks by default or not.
> 
> Tore