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