Subject: RE: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

From: "Christian Huitema" <[email-masked]>
Date: Mon, 9 Sep 2002 09:00:19 -0700

> 556 looks very strange. I was indeed attempting a *reductio ad
absurdum*.
> (http://www.dictionary.com/search?q=reductio%20ad%20absurdum)
> 
> As you point out we already have an IPv6 MTU definition, which happens
> to be compatible with the normal observed IPv4 MTU size, as
Christian's
> data
> showed. But if you want to be mathematically strict and strictly avoid
> IPv4 fragmentation, the answer would be 556. Which is silly. So let's
> just say nothing about the 6to4 MTU. It inherits the MTU from RFC
2460.

The IPv4 minimum MTU is 68 octets, per page 25 of RFC 791:

    Every internet module must be able to forward a datagram of 68
    octets without further fragmentation.  This is because an internet
    header may be up to 60 octets, and the minimum fragment is 8 octets.

The next paragraph specifies the minimum MRU:

    Every internet destination must be able to receive a datagram of 576
    octets either in one piece or in fragments to be reassembled.

What we are mentioning here is an additional constraint on top of the
default MRU of 576 bytes. Those nodes who behave would have to support a
larger MRU. The hard constraint, as mentioned by itojun, is:

	6to4-MRU >= 6to4-MTU + headers >= 1280 + headers.

"Headers" must account for the difference between the IPv4 and IPv6
computation of MTU -- payload plus header in IPv4, payload only in IPv6.
We must also account, as Randy mentioned, for a liberal dose of tunnels
and authentication data.

The "simplicity argument" would dictate that the "6to4-MTU + headers" be
chosen so that we don't actually get segmentation in most IPv4 networks,
knowing full well that some segmentation is in fact unavoidable. From
the CAIDA paper, I notice that in 98% of the current cases of IPv4
fragmentation cases, the fragment length is >= 1484 bytes, hence:

	1484 >= 6to4-MTU + headers >= 1280 + headers.

My vote would thus be to require an IPv4 MRU of 1484 bytes for 6to4
routers, but 1480 would be also correct.

-- Christian Huitema

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Sep 2002 11:26:48 -0700

How about this as a compromise:
All nodes SHOULD configure a 6to4 MRU at least as large as their
interface MTU, but that value MUST NOT be smaller than 1480. 

This would allow for the future case where both ends were GigE, but
would also allow for IPv6 PMTU discovery to figure out that one end was
limited to < 1500.

Tony 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Christian Huitema
> Sent: Monday, September 09, 2002 9:00 AM
> To: Brian E Carpenter; [email-masked]
> Cc: [email-masked]
> Subject: RE: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - 
> need WG consensus]
> 
> 
> What we are mentioning here is an additional constraint on 
> top of the default MRU of 576 bytes. Those nodes who behave 
> would have to support a larger MRU. The hard constraint, as 
> mentioned by itojun, is:
> 
> "Headers" must account for the difference between the IPv4 
> and IPv6 computation of MTU -- payload plus header in IPv4, 
> payload only in IPv6. We must also account, as Randy 
> mentioned, for a liberal dose of tunnels and authentication data.
> 
> The "simplicity argument" would dictate that the "6to4-MTU + 
> headers" be chosen so that we don't actually get segmentation 
> in most IPv4 networks, knowing full well that some 
> segmentation is in fact unavoidable. From the CAIDA paper, I 
> notice that in 98% of the current cases of IPv4 fragmentation 
> cases, the fragment length is >= 1484 bytes, hence:
> 
> My vote would thus be to require an IPv4 MRU of 1484 bytes 
> for 6to4 routers, but 1480 would be also correct.
> 
> -- Christian Huitema
>

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 10 Sep 2002 08:31:28 +0900

>interface MTU, but that value MUST NOT be smaller than 1480.=20
>

	we are talking about 6to4, correct?  if so, even if you have GigE and
	I have GigE, you are not sure where 6to4 packet will travel to.  it can
	go to anywhere (based on value on 3rd to 6th octet in ip6_dst).
	this is why i have been proposing to have fixed MTU value for 6to4
	interface.

itojun

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Sep 2002 17:16:11 -0700

> 	this is why i have been proposing to have fixed MTU 

Yes the packet might go through a router without a 100bT interface, so
the router upstream from it would have to fragment. As long as the
receiving 6to4 router is able to reassemble the fragments, there is no
problem. 

Are we talking about MTU or MRU??? There is no need for a fixed IPv6 MTU
since that is already defined as something between 1280 and the physical
link. Also there is no need for a defined IPv4 MTU since that is
something between 68 and the physical link. What I thought the point of
the thread was about is finding a minimum IPv4 MRU that would support
reassembly of IPv4 fragments into IPv6 packets. If any specific receiver
can't support an IPv4 MRU larger than 1280, the IPv6 PMTU discovery will
fail until it gets down to an acceptable value. The only real
interoperability problem will be when the IPv4 MRU is less than 1280.
Everything else is simply an optimization. 

We shouldn't need to specify that a node should implement an MRU that is
at least as large as the physical interface MTU, but if that is
confusing then I don't think it hurts. I also don't believe we need to
specify that a 6to4 MRU needs to be at least 1280 since that is already
specified, but if there were problems getting that to work between
implementations, then again it doesn't hurt to pick a value. If we are
going to do that we should pick one that is large enough to accommodate
the common option headers. 

I personally don't see why anything smaller than 4k for an MRU makes any
sense, but I also don't see that there is anything here worth arguing
over. If all nodes can receive as much as they can transmit, with a
minimum greater than 1280, then the overall system will self correct. I
don't see why a fixed value is needed.

Tony