ietf
[Top] [All Lists]

Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06

2017-04-26 15:09:53

On Apr 26, 2017, at 11:35 AM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:

Hi, Stewart,


On 4/26/2017 1:48 AM, Stewart Bryant wrote:


On 25/04/2017 19:26, Joe Touch wrote:
Hi, Stewart,

...

SB>
SB> Otherwise I would have thought that this was entirely a matter
SB> for the host whether it wanted to use a Path MTU below the IPv6
SB> link minimum. Nothing breaks if the host takes a more conservative
SB> decision.
I don't agree; the host at that point is violating RFC2460. It should
never think that an IPv6 link or path with an MTU below what RFC2460
requires is valid.

Joe


That is as maybe, but a host can do more or less what it wants, so
this is surely an
unenforceable constraint, or are you telling me that the receiving
host MUST drop a
fragment that is shorter than this? In which case the question whether
in practice
they do, and whether such a constraint is reasonable.

A "path MTU" is a value calculated from information from various sources
(attached links, ICMP messages, and perhaps other information), but IMO
it's never appropriate to set a "path MTU" smaller than the limit
established by IPv6 for a single link.

You are, of course, quoting RFC 1981:
   A node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

Individual packets and fragments can be smaller than the MTU, of course.
Nothing forces fragments to push up against any MTU limit at all. But I
would not describe that has a host changing its path MTU; it's just
sending packets.

I disagree, both on the definition and the action. You are correct in "how the 
Path MTU is calculated". But the Path MTU, by definition, is the largest packet 
that can be sent end to end under current routing conditions. It is not, 
actually, an IP concept: it's a TCP concept if anything, or a transport layer 
concept (if UDP ever decides to have one). I can imagine TCP probing the Path 
MTU by trying packets that are larger than its current estimate to see if the 
estimate is still accurate (1981 section 4), but I can't imagine any reason 
that TCP would send packets larger than the "largest packet that can be sent 
end to end under current routing conditions" in the normal case, as those 
packets will by definition either be fragmented or not arrive.