IPv6 day and tunnels

Templin, Fred L Fred.L.Templin at boeing.com
Tue Jun 5 20:09:26 UTC 2012


> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Tuesday, June 05, 2012 12:42 PM
> To: Templin, Fred L
> Cc: nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
> 
> Templin, Fred L wrote:
> 
> > I am making a general statement that applies to all tunnels
> > everywhere.
> 
> General statement?

General statement for IPv6-in-IPv4 tunneling, yes. But
inner fragmentation applies equally for *-in-* tunneling.

> Even though you assume tunnel MTU 1500B

What I am after is a tunnel MTU of infinity. 1500 is
the minimum packet size that MUST get through. 1501+
packets are admitted into the tunnel unconditionally
in hopes that they MIGHT get through.

> and tunnel overhead 20B?

The size "20" represents the size of the IPv4 encaps
header. The size "40" would represent the size of an
IPv6 encaps header. The size "foo" would represent the
size of some other encapsulation overhead, e.g., for
IPsec tunnels, IP/UDP tunnels, etc. So, let the size
of the encaps header(s) be "X", substitute X for 20
everywhere and you will see that the approach is
fully generally applicable.

> > For those, specs say that all that is required
> > for MRU is 1500 and not 1500+20.
> 
> That is a requirement for hosts with Ethernet interface, which
> is, by no means, general and has nothing to do with tunnels.

RFC2460 says the MinMRU for IPv6 nodes is 1500. RFC1122
says that IPv4 hosts should reassemble as much as their
connected interfaces (1500 for Ethernet). RFC1812 says
the MinMRU for IPv4 routers is 576.  

> For the general argument on tunnels, see, for example,
> RFC2473 "Generic Packet Tunneling in IPv6", where there
> is no requirement of 1500.
> 
> Note that the RFC uses outer fragmentation:
> 
>         (b)  if the original IPv6 packet is equal or  smaller  than  the
>              IPv6 minimum link MTU, the tunnel entry-point node
>              encapsulates the original packet, and subsequently
>              fragments the resulting IPv6 tunnel packet into IPv6
>              fragments that do not exceed the Path MTU to the tunnel
>              exit-point.

Wow - that is an interesting quote out of context. The
text you quoted is describing the limiting condition to
make sure that 1280 and smaller get through even if the
path MTU is deficient. In that case alone, outer
fragmentation is needed.

My document also allows for outer fragmentation on the
inner fragments. But, like the RFC4213-derived IPv6
transition mechanisms treats outer fragmentation as
an anomalous condition to be avoided if possible - not
a steady state operational approach. See Section 3.2
of RFC4213.

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

> 					Masataka Ohta




More information about the NANOG mailing list