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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 03 February 2011 21:37 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 A770C3A6A0B for <ietf@core3.amsl.com>; Thu, 3 Feb 2011 13:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.479
X-Spam-Level:
X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[AWL=0.569, 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 Q-MrZVHJRdgU for <ietf@core3.amsl.com>; Thu, 3 Feb 2011 13:37:12 -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 620713A69EF for <ietf@ietf.org>; Thu, 3 Feb 2011 13:37:11 -0800 (PST)
Received: (qmail 11316 invoked from network); 3 Feb 2011 21:46:48 -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; 3 Feb 2011 21:46:48 -0000
Message-ID: <4D4B208F.1000101@necom830.hpcl.titech.ac.jp>
Date: Fri, 04 Feb 2011 06:39:27 +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: Joe Touch <touch@isi.edu>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <4D48B4EA.20503@isi.edu> <4D49D2C9.50508@necom830.hpcl.titech.ac.jp> <4D49D75E.1010808@isi.edu> <4D4A79ED.1060104@necom830.hpcl.titech.ac.jp> <4D4AEFC6.70901@isi.edu>
In-Reply-To: <4D4AEFC6.70901@isi.edu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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: Thu, 03 Feb 2011 21:37:13 -0000

Joe Touch wrote:

>>>>>> 9. ICMP

>> FYI, traceroute both with UDP or ICMP ECHO is working to/from
>> /between private network behind end to end gateway is working.
> 
> Understood, but my issue is that "ICMP" is more than just ICMP echo;
> many other messages are the result of sending a regular packet (as with
> traceroute), and those are intended to include both the address and port
> of the packet that causes the ICMP.

Yes, ICMP time exceeded including UDP can be routed and is actually
working.

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

> Transport checksum works only if the entire transport packet is included
> in the ICMP response,

ICMP? I'm afraid the only ICMP possibly affected by reassembly
is port unreachable. Moreover, as long as destination port number
is correct, proper response can be returned. Purely theoretically,
wrong reassembly of IPv6 (or IPv4 with fragmented ICMP error) can
make the destination port number wrong. Still, as the source port
number is assured to be in the same fragment as the destination
port number, the port unreachable message itself is correct.

You should better worry about the theoretical possibility that
port numbers are not included in the first fragment of IPv6
packet (because of lengthy optional headers).

>> It should be noted that packet smaller than 69B is also atomic.
> 
> Packet size is not a consideration in whether a packet is atomic.
> 
> Packets under 69B must be able to be carried without fragmentation by a
> link as per RFC791, but there's nothing in RFC791 that prohibits such
> packets from being fragmented anyway.

RFC791 specifies fragmentation occur only "when necessary":

  The internet modules use fields in the internet header to fragment and
  reassemble internet datagrams when necessary for transmission through
  "small packet" networks.

and "necessary" is defined as:

    Fragmentation of an internet datagram is necessary when it
    originates in a local net that allows a large packet size and must
    traverse a local net that limits packets to a smaller size to reach
    its destination.

NetBSD, for example, assumes so:

	if (m->m_pkthdr.len < IP_MINFRAGSIZE) {
		ip->ip_id = 0;

thanks to IPv6, we can safely assume not only IPv6, but also IPv4,
packets smaller than 1281B is atomic.

BTW, note that atomic packets may be fragmented within a tunnel as
is specified in RFC2473, which is used for IPv6 mobility.

> But nothing in RFC791 requires that this be the original packet.

That a fragment can be 28B long does not mean 68B packet may be
fragmented unnecessarily. Note also a suggestion in RFC791:

      An alternative might produce less
      than the maximum size datagrams.  For example, one could implement
      a fragmentation procedure that repeatly divided large datagrams in
      half until the resulting fragments were less than the maximum
      transmission unit size.

which is seemingly ignored but should be useful today with nested
tunneling.

>> The problem of the draft (and IPv6) is that it depends on PMTUD.
> 
> Please explain how and where. PMUTD isn't even discussed or cited.

You can't safely send an IPv4 (with DF=1) or IPv6 packet larger
than 1280B unless you know path MTU.

It's an issue of IPv6, not specific to the draft.

						Masataka Ohta