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

[Naiming Shen <[e-mail]>]

Hi Joe,

some replies inline,

On Mar 7, 2012, at 5:29 PM, Joe Touch wrote:

> 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.

Actually the current implementations I have looked, this ID of ICMP echo request
is used to identify a ping process in a multi-threaded system such as linux/bsd. It
is fixed during the session, which the "Sequence number" field changes with each
packet. In this draft, we suggest if the implementation uses this fixed ID in the
ICMP echo-request, the multi-thread process-id information can be moved to the
firest 64 octets, which is reserved for private use.

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

For traceroute application, it's the same usage for the ID field as above.

> 
> 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.

That is true. But for udp traceroute stops or udp ping reaches the destination,
it uses the property of either the destination port is not open, or the port is open
but the source address of the udp packet does not match with any of the socket.
Here in this draft is a little different, the port is a well-known, and is intended to
receive this ping or traceroute packet, thus we just emphasis that so there is no
confusion.

> 
> 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.

This is only applied to traceroute/ping type of the applications. Although there is no
specific RFCs to cover those applications, we can certainly add more text to describe
them more clearly.

> 
> 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.

It's just an option offered by this extension, it's not a must. As mentioned above,
this is for providers to distinguish new services using this extension from the trace
and ping packets of legacy usage.

thanks.
- Naiming

> 
> Joe
> 
> 
> 
>