Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

[Joe Touch <[e-mail]>]

On 3/25/2016 10:05 AM, Tom Herbert wrote:
>> On another hand, this problem of multiplexing at multiple levels makes
>> > it that there is no 'traceroute' program that meaningfully reports
>> > number of hops through tunnels.  This is a universal tool for network
>> > debugging, maybe as loved as ping is.
>> >
> I believe https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-01
> is the proposed solution for that.

I would not recommend that doc as an example of how to handle this issue
- it has more than a few issues:

- the reason that IP hopcounts of payloads should not be decremented in
a tunnel is because hopcount is a measure of time at routers, not time
in links. Because a tunnel is a link, the encapsulated packets
experience no forwarding themselves. This has nothing to do with whether
the source and dest IP are in the same IP subnet (end Sec 1).

- TTLs are decremented when forwarding; it makes no sense to decrement
the outer TTL upon encapsulation. That decrement happens later in the
path inside the tunnel. Otherwise, a packet whose hopcount is 0 might be
discarded at the ingress, even though it can legitimately reach its
destination over the tunnel link.

- The decrement of the inner packet might be done to correspond to the
cost of the link itself, as noted. In that case, the error goes back to
the inner packet's source host -- never to the tunnel ingress. ICMPs go
to the tunnel ingress if the encapsulation header TTL falls below zero
along the tunnel path only.

- RFC1122 does not ensure that there is enough information to relay
tunnel ICMPs back to the origin source. Packets could be fragmented to
traverse the tunnel (lacking an inner header altogether) or could have
too much encapsulation to allow that.

These issues are all discussed in intarea-tunnels, which should have
been cited there. FWIW.

Joe