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

[Naiming Shen <[e-mail]>]

Ok, if IANA does not reserve non-"port" items, we'll remove this from the IANA consideration
section then. By legacy I only meant the default or everyday usage of traceroute or ping.

thanks for the note.

- Naiming

On Mar 8, 2012, at 4:10 PM, Joe Touch wrote:

> I remain confused.
> 
> ICMP doesn't use ports; it uses IDs, and the ID space is not registered by IANA, so there's no meaning to a reserved ICMP echo ID value.
> 
> As I noted, there is a specific value - not legacy, but current utility - in sending TCP or UDP packets to specific ports to test reachability.
> 
> I don't see any value in reserving a port here.
> 
> Joe
> 
> On 3/8/2012 4:04 PM, Naiming Shen wrote:
>> 
>> 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
>>> 
>>> 
>>> 
>>> 
>>