Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

[Joe Touch <[e-mail]>]

Hi, Gorry  (et al.),


On 2/16/2017 6:04 AM, Gorry Fairhurst wrote:
> On 15/02/2017 21:25, Joe Touch wrote:
>> Hi, Gorry (et al.),
>>
>> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote:
>>> There is no mention that paths including tunnels can eat ICMPv6 PTB
>>> messages on the tunnel segment, blackholing them, which prevents
>>> reaching the destination.
>>
>> Nor should there be, IMO.
>>
>> A tunnel is a link layer to the network whose packets it transits.
>>
>> ICMPs generated inside a tunnel aren't "eaten", so much as they operate
>> at a different layer for a different reason (e.g., to tune
>> ingress-egress source fragmentation of encapsulated packets).
>>
>> PTB messages inside a tunnel are (IMO) most correctly interpreted by the
>> ingress (which is an *interface* on a router or host, most correctly
>> IMO) as changing the MTU of the tunnel as a link. If that MTU change
>> affects packets that arrive later, then it would be the router where the
>> ingress is attached that would generate the ICMP, never the (ingress)
>> interface whose MTU is insufficient.
>>
>> Again, I'm in the process of updating draft-ietf-intarea-tunnels to be
>> much more clear on this point (the update should be issued in a day
>> or two).
>>
>> Joe
>>
>
> I really disagree Joe - not in what you say about how things need to
> be, nor the relevance of draft-ietf-intarea-tunnels.
>
> The point of disagreement, is that I think the text needs to explain
> enough that people do NOT blindly believe this always works. the
> current text mentions tunnels in more than one place, as if they are
> just another usage of PMTUD.
>
> Tunnels can make path MTU diiscovery unreliable, because many deployed
> tunnel ingresses do not propagate ICMPv6 PTB messages upstream to
> reflect the limits of the Tunnel MTU. 

I'll send you a preview of the updated tunnel text privately (it will be
posted in a few days). Even the last version, however, explains why
individual PTB messages should not be relayed directly upstream.

The solution is as follows: PTB messages should update the ingress's
link MTU (where the tunnel is a link and the ingress is a network
interface). Subsequent messages at a router where the ingress is
attached would already generate the correct ICMP errors when they
receive later packets that are larger than that updated MTU.

> draft-ietf-intarea-tunnels discusses how a tunnel should be
> implemented to effectively work with a Tunnel MTU.
The above is a brief summary of what it discusses.

This document doesn't need to do much on this matter at all, except NOT
provide contradictory advise or imply otherwise.

IMO, whether a tunnel works correctly or not is a tunnel issue, not an
issue for a network protocol, just as this doc shouldn't enumerate other
link layer issues, such as problems with the need for broadcast on NBMA
links, etc.

Joe