[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

My understanding from the previous discussion on the draft the WG did
not want to mandate the dynamic MTU discovery from encapsulator to decapsulator. Hence it is optional in the new draft.

No; I was only referring to the scheme that allows configured MTUs larger than 1280
when the DF bit is not set. But, see below:

But limiting the size of the packets sent into the tunnel to 1280+20
doesn't cause any more fragmentation than the dynamic scheme.
Essentially the mandatory part of the specification means that
the tunnel over IPv4 will provide the link specific fragmentation
(for the link that is IPv4) that the IPv6 base specification requires
for links that can not support 1280 bytes of IPv6 packets.


True; in some cases, link layer fragmentation is unavoidable.


Having the encapsulator discover the IPv4 MTU doesn't allow us to reduce the
amount of ressembly that the decapsulator needs to perform.
And I don't think the level of fragmentation is harmful - especially given
that most Internet paths support an MTU of 1500 bytes.
Yes, most paths support an MTU of 1500 bytes. But, the majority of those that don't
will fragment at 576 bytes. Hence, an MTU closer to 1480+20 bytes will result in no
more fragments (i.e., 3) than 1280+20 in most cases. Still to be considered are bumps
in the stack/wire and middleboxes that add further layers of encapsulation (e.g., L2TP,
IPsec, etc.) so a safe bet is to choose something like 1380+20 leaving 100bytes for
additional encapsulation.

Fred
ftemplin@iprg.nokia.com