Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt

["Fred L. Templin" <ftemplin@IPRG.nokia.com>]

itojun@iijlab.net wrote:
> > I fail to see your point; how is 1280 "simpler" than 1380? It's
> > just a static MTU assignment in either case. You will need to
> > define "simplicity" for your arguement to even make sense.
>
> 	1280 is the only link MTU requirement value appears in RFC2460, and it
> 	is the minimum required value for any IPv6 links  (which does not
It is true that 1280 is the minimum required value for an IPv6 link. But,
the reason we use, e.g., 1500 for Ethernet instead of 1280 is that 1500
provides greater efficiency w/o resulting in black holes or excessive link
layer fragmentation. IPv6-in-IPv4 tunnels should strike a similar balance
by setting an MTU of up to 1380 bytes.

> 	require wacky fragmentation header rule at the end of 2460 section 5).
Is the fragmentation header rule at the end of 2460, section 5 "whacky"?
Perhaps. But, is it relevant to this discussion? Absoultely not.

It is true that we do not want to receive an ICMPv6 "packet too big" message
from the IPv6-in-IPv4 tunnel with a next-hop MTU of less than 1280 bytes, since
this would give a false indication of an IPv6 to IPv4 translating router in the
path. But, this just means that we always need to allow link layer (i.e., IPv4)
fragmentation when the IPv6-in-IPv4 tunnel interface uses a static MTU, and we
already do this by specifying that the DF flag not be set in the encapsulating
IPv4 header.

> 	i dunno what word other than "simple" would capture this.
All that you've convinced me of is that 1280 is the mimimum MTU for IPv6 links,
but this is already plain for all to see in RFC 2460, etc. The fragmentation
header rule at the end of 2460, section 5 is irrelevant. So, too, is the term
"simple" since all you're really referring to is the IPv6 minimum link MTU.

Fred
ftemplin@iprg.nokia.com