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

Comments on draft-ietf-ngtrans-mech-v2-01.txt



In section 3.2, the following text appears (actually,
this is unchanged since mech-v2-00.txt):

   Encapsulating nodes that have a large number of tunnels might not be
   able to store the IPv4 Path MTU for all tunnels.  Such nodes can, at
   the expense of additional fragmentation in the network, avoid using
   the IPv4 Path MTU algorithm across the tunnel and instead use the MTU
   of the link layer (under IPv4) in the above algorithm instead of the
   IPv4 path MTU.

   In this case the Don't Fragment bit MUST NOT be set in the
   encapsulating IPv4 header.

When you say: "...and instead use the MTU of the link layer (under IPv4)
in the above algorithm...", it is not clear whether you mean the *full*
MTU of an arbitrary link layer, or the MTU of the link layer *up to
some limit* (e.g., 4400 bytes). If your meaning is the latter, then
it would help make things clearer if you re-iterate the 4400 byte
limit in this text also.

If instead your meaning is to use the full MTU of an arbitrary link
layer, then nodes implementing this specification run the risk of
creating "harmful fragmentation" in the network and/or reassembly
buffer overruns in receivers. So, I suggest this text be made clear.

I believe you should also state somewhere that section 3.2 provides
only a *limited* tunnel MTU configuration mechanism. A more generalized
mechanism is possible if explicit fedback from the decapsulator is
available. For example, see:

 http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt

Thanks,

Fred Templin
femplin@iprg.nokia.com