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

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 10 Mar 2003 16:08:22 -0800

Erik,

I notice that in the latest draft version, you are no longer requiring an
MRU of 4420 bytes in decapsulators and seem to be taking a less
aggressive approach in the dynamic MTU discovery in the encapsulator.
Can you say more as to the reasons for the change?

Thanks,

Fred Templin
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 09:24:14 +0100 (CET)

> Can you say more as to the reasons for the change?

This change (the non-need for the 4420 limit) was presented in
Atlanta even though it was not in the previous version of the draft.

The basic results (which I think were on the slides, or perhaps only
in the discussion in Atlanta) is that the decapsulator needs to
support reassembly of up to the max (of its interface MTUs) and 1280+20.
(There is a note in the spec about it really being its neighbors MTU
that matter when the MTU != MRU).

Then the encapsulator can choose between the static approach of
a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic 
tunnel MTU detection using IPv4 path MTU discovery. The latter will never 
result in IPv4 packets at the decapsulator larger than the max of the
decapsualtor's interface MTUs.

Finally the spec allows for manual configuration to override the 1280 number
in the static/fixed MTU case, but only if the receiver can handle reassembly
of the larger IPv4 packets. Thus it requires manual coordination between
the encapsulator and decapsulator to do this manual override.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 11 Mar 2003 20:18:45 -0800

>that matter when the MTU != MRU).
Makes sense; it seems the 4420 requirement may have been too big for 
some low-end
devices anyway.

>decapsualtor's interface MTUs.
Sure. Setting the DF bit prevents packets that are too big from reaching 
the decapsulator.

>the encapsulator and decapsulator to do this manual override.
Are there any concerns for denial of service based on receive buffer overrun
at the decapsulator in this case?

Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2003 23:13:56 +0100 (CET)

> >of the larger IPv4 packets. Thus it requires manual coordination between >
>the encapsulator and decapsulator to do this manual override.  >

Not any worse than a factor MTU/1460 than in the normal case.
I.e. if the decapsulator has been configured to use e.g. 9kbyte buffers for a 
particular tunnel it might use 9k/1460 times more memory for buffers
for that tunnel.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 12 Mar 2003 20:56:04 -0800

>particular tunnel it might use 9k/1460 times more memory for buffers
I understand what you are saying about the buffer reqt's. But, when IPv4 
fragmentation
is occurring in the path between the encapsulator and decapsulator, 
there is no way
for the encapsulator to learn this and decrease its MTU estimate.

As currently worded, the specification could result in harmful levels of 
fragmentation in
the network when encapsulators implement only the base specification.

Fred
[email-masked]