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