Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt

[Joe Touch <[e-mail]>]

Hi, all,

On 3/5/2012 11:46 PM, Naiming Shen wrote:
...
> The previous version of this draft didn't have this well-known port defined, and we got
> many comments on how to distinguish the packets with new features from the general
> traceroute/ping packets on the Internet, as you mentioned below, it needs more deeper
> packet inspection. With this well-known port, a provider's internal use of certain feature with
> this extension can be more easily sort out from normal trace/ping packets (before the deeper
> packet inspection).

A ping (ICMP echo request) message has no port. It has an Identifier 
field that is used "like a port in TCP or UDP to identify a session" 
[RFC792], but it identifies a session not a protocol. I.e., it should 
change for subsequent echo requests, so this should not be fixed at a 
specific value.

Traceroute uses ICMP with varying TTLs, so a port number is equally 
meaningless there.

Sec 5 of this doc redefines how ping works - when it reaches the valid 
destination, an echo response is sent back. That's how ping knows it 
works, and how traceroute knows to stop.

If you intend on using these inside UDP or TCP segments, you need to be 
much more specific about what you mean by 'traceroute/ping' - notably, 
citing an RFC or other spec on the variant you're using. However, it 
would be important to first make the case that this information is 
relevant for those protocols.

However, why would you then want to limit those protocols to a specific 
UDP or TCP port number? their value is in being used to test various 
port numbers that are blocked (or not) along various paths - e.g., to 
find out that HTTP isn't blocked all the way to a destination, or if so 
on what hop.

Joe