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

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 01 May 2003 08:43:02 -0700

[email-masked] wrote:
>>>	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.
> 
> 
> 	i disagree.

You disagree that IPv6 links should strive for greater efficiency by
setting a larger MTU than the IPv6 minimum of 1280 bytes if possible?

> what is the reasoning behind "1380"?

See: 'draft-ietf-ngtrans-isatap-13.txt', section 6.1.

Fred
[email-masked]

---

From: [email-masked]
Date: Fri, 02 May 2003 08:17:45 +0900

>setting a larger MTU than the IPv6 minimum of 1280 bytes if possible?

	correct.  if you want efficiency, dynamic MTU case in mech-v2
	should give you the efficiency.  leave non-dynamic as is (1280).

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 01 May 2003 16:26:23 -0700

> 	should give you the efficiency.  leave non-dynamic as is (1280).

Can you state your technical objections to setting a larger non-dynamic
value of 1380?

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 05 May 2003 17:18:09 -0700

Were there any technical objections to setting a larger non-dynamic
tunnel MTU of 1380?

Fred
[email-masked]

---

From: [email-masked]
Date: Tue, 06 May 2003 09:56:53 +0900

>Were there any technical objections to setting a larger non-dynamic

	keep it to 1280.  MTU of 1280 is the minimum MTU value any IPv6 link
	has to support, therefore even minimal router implementation has to
	support it.

	if you want to get more efficiency, use dynamic tunnel MTU discovery.
	keep the simple one "simple" (= 1280).  don't try to make simple
	mechanism more complex when there's more efficient variant (dynamic
	tunnel MTU) exists.

	and, i don't think you have convinced me on the technical benefits
	of 1380 (the particular value).

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 06 May 2003 13:32:01 -0400

Fred

> Were there any technical objections to setting a larger non-dynamic

If you start mandating a default static MTU of 1380 on a configured
tunnel, then you may very likely have interoperability problmes
with implementations of rfc 2893 that only support static
MTU of 1280.

Since v6ops-mech-v2-00 draft is updating RFC 2893, lets try to
keep it backwards compatible.  Neither drafts absolutely require
PMTU Discovery and thus having different default MTUs may cause
problems and will require reconfiguration.

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX Network Group
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 06 May 2003 13:29:41 -0700

Hi Vlad,

> If you start mandating a default static MTU of 1380 on a configured

Perhaps I havn't made myself clear on this point, but I'm not
seeking to mandate a static MTU of 1380. What I am meaning to
suggest is something along the lines that the static MTU assignment
"MUST be no less than 1280 and SHOULD be no greater than 1380".

> with implementations of rfc 2893 that only support static

On this point, it's not clear to me that RFC 2893 specifies a static
MTU of 1280. If you read section 3.2 of that document carefully, you
will see that 1280 is only mentioned within the context of using the
IPv4 path MTU to determine the tunnel MTU. The only text in RFC 2893
that speaks to a static MTU assignment is in the next-to-last paragraph
of section 3.2 where it says that a node may: "...avoid using the IPv4
Path MTU algorithm accross the tunnel and instead use the MTU of the
link layer (under IPv4)...". (But, in many cases, such a choice would
lead to excessive fragmentation).

> problems and will require reconfiguration.

As far as I can tell, it is OK for the MTU determination schemes
implemented by the tunnel endpoints to be asymmetric. For example,
if nodes A and B are the tunnel endpoints it could be the case that
A uses a static MTU assignment while B implements the dynamic mechanism.
The fact that A and B might be using different default MTUs does not
seem to me have any implications for interoperability.

Regards,

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 May 2003 00:30:34 +0300 (EEST)

> "MUST be no less than 1280 and SHOULD be no greater than 1380".

I think we were discussing the default value.  For default values, 
"something between 1280 and 1380" might not be sensible.  On the other 
hand, if this is not a default value, I certainly don't want anyone 
specifying how big MTU's I *SHOULD* use.

I may be missing something though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 06 May 2003 14:58:35 -0700

Pekka Savola wrote:
> I think we were discussing the default value.

Yes; can also be thought of as the default static or default
stateless value.

> For default values, 
> "something between 1280 and 1380" might not be sensible.

OK - then let's continue to discuss about 1380 and not dive
into the "something between" rathole. (I am meaning to answer
Itojun back on his question about the 1380.)

 > On the other

No - larger MTUs are certainly permissible in some circumstances.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 06 May 2003 16:03:57 -0700

Itojun,

> 	of 1380 (the particular value).

The Internet cell size is pretty much 1500 bytes these days, so an
IPv6/IPv4 tunnel MTU of 1500 - 20 = 1480 might seem like a
natural choice. However, link layer encapsulations below the IPv6/IPv4
tunnel may occur, e.g., when the tunnel is carried over a VPN interface.

Microsoft, cisco and others use 1400 bytes as the default MTU for VPN
interfaces in order to allow enough room for link layer encapsulations
(e.g., IPsec, L2TP, PPPoE, etc.) without exceeding the 1500 byte budget
and incurring fragmentation. So, the default IPv6/IPv4 tunnel MTU should
be set to at most 1400 - 20 = 1380.

There are two reasons to set the default MTU as large as 1380 bytes:

  1) 1380 provides a 7.8% efficiency gain over 1280.
  2) 1380 allows 100 bytes for an additional layer of
     IPv6 encapsulation above the IPv6/IPv4 tunnel.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 May 2003 10:00:25 +0300 (EEST)

> 	of 1380 (the particular value).

I'm trying to look at this from a different angle: what benefits would
1280 really have (except for simplicity etc.etc. vague things)?

To me, it seems that the features possibly gained by pushing 1280 
could be:

 - can hosts be implemented so that they do not implement fragmentation 
and reassembly? (no difference, it seems)
 - can hosts be implemented so that they don't need to participate 
actively in PMTUD? (no difference, it seems)
 - can hosts be implemented so that they don't need to care for received 
"packet too big" ICMP messages ("passive PMTUD")? (passive PMTUD would 
seem to be required if the host uses 1380 for sending)
 - can hosts be implemented so that they can have a lower MRU than
1500 bytes? (no difference, it seems)
 - ...

As for routers,
 - can routers be implemented so that they do not need to implement 
IPv4 fragmentation and reassembly *for tunnel packets* (note: IPv6 frag + 
reass may be needed anyway, from "host part")?
 - can routers be implemented so that they can have a lower MRU than 1500 
bytes? (can't implement that way, I think.)
 - ...

Please try to come up with some concrete thoughts on this?
(I'm not sure whether 1380 is the best choice anyway, but I'd like to get 
some harder data to back up some rather abstract reasons.)