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

[Joe Touch <[e-mail]>]

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