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

Joe Touch <touch@isi.edu> Fri, 09 March 2012 06:12 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DDE21F85E1 for <int-area@ietfa.amsl.com>; Thu, 8 Mar 2012 22:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.401
X-Spam-Level:
X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmU+GWfc1M9P for <int-area@ietfa.amsl.com>; Thu, 8 Mar 2012 22:12:53 -0800 (PST)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B291C21F85D4 for <int-area@ietf.org>; Thu, 8 Mar 2012 22:12:53 -0800 (PST)
Received: from [192.168.1.89] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q296CLZQ007237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Mar 2012 22:12:25 -0800 (PST)
References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> <CFF1327F-D62D-4DDD-9382-7D083DBB6E65@cisco.com> <4F580B97.1070401@isi.edu> <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> <4F594A63.1060506@isi.edu> <5F06A352-AE71-4DFB-8B19-2DA80076406F@cisco.com>
In-Reply-To: <5F06A352-AE71-4DFB-8B19-2DA80076406F@cisco.com>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <B8338313-0904-4744-B538-75EF61B4EF2A@isi.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (9B176)
From: Joe Touch <touch@isi.edu>
Date: Thu, 08 Mar 2012 22:12:24 -0800
To: Naiming Shen <naiming@cisco.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 06:12:54 -0000

IANA reserves many things besides ports, just not ICMP IDs, FYI. 

"Legacy" usually means an old use that may be supported but is no longer common, too. 

Joe 

On Mar 8, 2012, at 7:04 PM, Naiming Shen <naiming@cisco.com> wrote:

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