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

Joe Touch <> Wed, 02 February 2011 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34C9D3A6C3A for <>; Wed, 2 Feb 2011 14:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.617
X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wy6c0+EIDXAo for <>; Wed, 2 Feb 2011 14:11:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 116013A6AF5 for <>; Wed, 2 Feb 2011 14:11:44 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p12MEse2008012 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 14:14:54 -0800 (PST)
Message-ID: <>
Date: Wed, 02 Feb 2011 14:14:54 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Masataka Ohta <>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p12MEse2008012
X-ISI-4-69-MailScanner: Found to be clean
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Feb 2011 22:11:49 -0000

On 2/2/2011 1:55 PM, Masataka Ohta wrote:
> 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.

I quoted the start of the section. The first sentence, without further 
qualification, is inaccurate, IMO.

ICMP messages do not themselves have port numbers, but they are intended 
to *carry* port numbers of the messages that caused their generation (if 
they report errors).

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

This is relevant to the generation of new ICMPs that are not the result 
of errors - e.g., echo request. The section is written so generally as 
to include ICMPs that are responses to errors too, typically as 
generated by packet arrivals.

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

IMO, any device that initiates packets MUST verify that the IDs emitted 
follow spec. Once a packet's address(es) are rewritten, the NAT is 
responsible for ensuring that the IDs are unique across the 
src/dst/proto triple.

I'm not aware of NATs that do this; they typically copy the ID field, 
and this can easily cause reassembly errors later - even if the packet 
is reassembled at the NAT itself.

See draft-ietf-intarea-ipv4-id-update for more a discussion of this 
issue and the proposed requirements to address it.