[153409] in North American Network Operators' Group
RE: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Templin, Fred L)
Tue Jun 5 18:03:17 2012
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Tue, 5 Jun 2012 15:01:55 -0700
In-Reply-To: <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
> Sent: Tuesday, June 05, 2012 2:44 PM
> To: Templin, Fred L; nanog@nanog.org
> Subject: Re: IPv6 day and tunnels
>=20
> Templin, Fred L wrote:
>=20
> > 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.
>=20
> Infinity? You can't carry 65516B in an IPv4 packet.
I should qualify that by saying:
1) For tunnels over IPv4, let infinity equal (2^16 - 1)
minus the length of the encapsulation headers
2) For tunnels over IPv6, let infinity equal (2^32 - 1)
minus the length of the encapsulation headers
> > 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.
>=20
> Instead, see the last two lines in second last slide of:
>=20
> http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf
>=20
> It is a common condition.
Are you interested in only supporting tinygrams? IMHO,
go big or go home!
Fred
fred.l.templin@boeing.com
> Masataka Ohta
