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

[Gorry Fairhurst <[e-mail]>]

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. draft-ietf-intarea-tunnels 
discusses how a tunnel should be implemented to effectively work with a 
Tunnel MTU.

Gorry