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

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 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.

Thanks for catching this inconsistency.
The intent is that this be limited by the magic number as well - and
the magic number (currently) in the document for encapsulators that
don't do path MTU discovery  is 1280. So how about adding:
	In that case the IPv6 MTU for the tunnel SHOULD be limited
	to 1280 and MUST not exceed 4400.


> 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

Hmm - I don't know how to do this without creating a reference
against that draft. Perhaps you can suggest concrete text that we can
look at.

  Erik