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

Masataka Ohta <> Thu, 03 February 2011 09:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FC733A68D2 for <>; Thu, 3 Feb 2011 01:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.606
X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6L+0kZEpPiEM for <>; Thu, 3 Feb 2011 01:47:08 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 6EEE43A68A0 for <>; Thu, 3 Feb 2011 01:47:06 -0800 (PST)
Received: (qmail 92760 invoked from network); 3 Feb 2011 09:56:07 -0000
Received: from (HELO ? ( by with SMTP; 3 Feb 2011 09:56:07 -0000
Message-ID: <>
Date: Thu, 03 Feb 2011 18:48:29 +0900
From: Masataka Ohta <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Joe Touch <>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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: Thu, 03 Feb 2011 09:47:09 -0000

Joe Touch wrote:

>>>> 9. ICMP

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

Anyway, most of the discussion in the section is inapplicable to
end to end NAT where public source addresses are used even within
private networks.

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

FYI, traceroute both with UDP or ICMP ECHO is working to/from
/between private network behind end to end gateway is working.

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

IC. We can rely on random id and transport checksum, then.

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

It should be noted that packet smaller than 69B is also atomic.

The problem of the draft (and IPv6) is that it depends on PMTUD.

PMTUD just does not work. Worse, PMTUD is inefficient. That is,
that PMTUD periodically sends oversized packets means PMTUD
overloads routers, just as IPv4 fragmentation overloads routers.

If we write a draft on IPv6 issues, it should contain a lot
more and a lot more serious issues than those of shared

						Masataka Ohta