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