Re: transmech MTU comments

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

> The latter paragraph implies that either all links on the path will
> be at least as large as the static MTU, or that nodes with constricting
> links will use IPv4 fragmentation to split the packet into pieces small
> enough to traverse the constricting link. The former case will not be
> true in general, because certain bandwidth constrained links will choose
> smaller-than-1280-byte MTUs for their IPv4 interfaces if BCP 48, 50,
> and 71 recommendations are followed. 

Agreed that there might be IPv4 fragmentation in this case.

> Also, we cannot be assured that
> all forwarding nodes will correctly implement IPv4 fragmentation.
> So, we have a very real possibility for black holes here.

Huh? If we can't assume that IPv4 fragmentation works we might as well
assume that IP routing doesn't work and we should be using the postal
service to have this discussion instead of email.

> But, shouldn't the encapsulator send a "packet too big" to the source
> in this case even if the MTU it reports is less than 1280 bytes? In 
> response,
> the source should then include a fragment header in the packets it sends
> as a signal to the encapsulator that IPv4 fragmentation is permissible
> (see RFC 2460, section 5). More discussion on this below:

IPv4 fragmentation is always permissible.
The text you are referring to in RFC 2460 is to enable SIIT (and NAT-PT?)
to operate over IPv4 paths with a path MTU less than 1280 bytes without
having to make up IPv4 fragment IDs on the fly.
RFC 2460 says "undergoes translation" as the motivation.
Thus this has nothing to do with encapsulation.

  Erik