Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 02 February 2011 21:52 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A39E3A6DCA for <ietf@core3.amsl.com>; Wed, 2 Feb 2011 13:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.693
X-Spam-Level:
X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 707tTAOgZZNY for <ietf@core3.amsl.com>; Wed, 2 Feb 2011 13:52:56 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 294E13A6D4D for <ietf@ietf.org>; Wed, 2 Feb 2011 13:52:55 -0800 (PST)
Received: (qmail 76491 invoked from network); 2 Feb 2011 22:02:18 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 2 Feb 2011 22:02:18 -0000
Message-ID: <4D49D2C9.50508@necom830.hpcl.titech.ac.jp>
Date: Thu, 03 Feb 2011 06:55:21 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <4D48B4EA.20503@isi.edu>
In-Reply-To: <4D48B4EA.20503@isi.edu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2011 21:52:57 -0000

Joe Touch wrote:

>> 9. ICMP
>>
>> ICMP does not carry any port information and is consequently
>> problematic for address sharing mechanisms.
> 
> ICMP messages are specifically intended to include enough of the 
> transport header to enable port demuxing at the end receiver.

I think it says ICMP information messages such as echo request
do not have port numbers.

However, ID and sequence number field of echo request can be
used (overridden) as source and destination port numbers,
respectively.

As the fields are copied as is from echo request to echo reply,
ID and sequence number field of echo request must be
used as destination and source (reversed) port numbers,
respectively.

It's implemented for end to end NAT and is working with "ping"
and "traceroute".

>> 11. Fragmentation
>>
>> When a packet is fragmented, transport-layer port information (either
>> UDP or TCP) is only present in the first fragment. Subsequent
>> fragments will not carry the port information and so will require
>> special handling.
> 
> ?INT? The ID will be incorrect too; it may not be unique as required 
> when viewed from the outside.

Port based redirection MUST be done after fragmentation reassembly.

That's all and is no special.

						Masataka Ohta