Re: PMTUD and MTU < 1280

Rémi Després <despres.remi@laposte.net> Mon, 25 July 2011 17:43 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08B21F8C00 for <ipv6@ietfa.amsl.com>; Mon, 25 Jul 2011 10:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.93
X-Spam-Level:
X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxMM29Mw8LUa for <ipv6@ietfa.amsl.com>; Mon, 25 Jul 2011 10:43:02 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39421F8BDC for <ipv6@ietf.org>; Mon, 25 Jul 2011 10:43:01 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 30E7870000A0; Mon, 25 Jul 2011 19:43:00 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 9603C700009E; Mon, 25 Jul 2011 19:42:59 +0200 (CEST)
X-SFR-UUID: 20110725174259614.9603C700009E@msfrf2117.sfr.fr
Subject: Re: PMTUD and MTU < 1280
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <04db01cc4acf$d9074600$8b15d200$@com>
Date: Mon, 25 Jul 2011 19:42:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98B94666-CD24-4D1A-B25F-F6238CC3708E@laposte.net>
References: <264DF4B8-A7F3-4DB3-B58D-BBAC2A48B470@gmail.com> <A3E346FA-E5A4-4755-9D35-08CB10494424@apple.com> <01d201cc48e1$0784d8d0$168e8a70$@com> <010826E2-D6DF-488D-B5C4-CE14E47C7EE7@free.fr> <04db01cc4acf$d9074600$8b15d200$@com>
To: Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 25 Jul 2011 11:59:15 -0700
Cc: ipv6@ietf.org, 'RJ Atkinson' <rja.lists@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 17:43:02 -0000

Dan, 

1.
The point I wanted to check is just, slightly reformulated):
"May a simple IPv6 host have no support of packet-reassembly, and simply accept packets up to 1280 octets."

In my understanding, the answer should be yes.
- This doesn't depend on whether sources know or not whether their destinations are IPv6 or IPv4 only. 
- If the destination happens to be IPv6, current RFC's don't permit intermediate nodes to refuse 1280 packets as being too big.

2. 
How sources can be sure to have e2e transparency in IPv6 is a different question, but IMHO an important one.

For instance, if a destination address is obtained from the DNS in a AAAA, with no A for the same URL  and without any well-known prefix indicating that there is an embedded-IPv4-address, I hope the source can be guaranteed that e2e transparency won't be broken? 

I won't have time personally to contribute much on this, but the subject would usefully be clarified, IMHO.

Regards,
RD
 

 Le 25 juil. 2011 à 15:36, Dan Wing a écrit :

>>>> 
>>>> ...
>>> 
>>> Its behavior violates the last paragraph of Section 5 of RFC2460.
>> 
>> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4
>> destination".
> 
> But how does one determine an IPv6 packet is, or isn't, going 
> to an IPv4 destination?  I don't think it's possible to determine
> if there is an IPv6/IPv4 translator on the path.
> 
> -d
> 
> 
>> If the destination is IPv6, a PMTU below 1280 remains therefore a
>> network failure.
>> This authorizes a simple IPv6 host to refuse packets beyond 1280 octets
>> and to have no support of packet-reassembly.
>> 
>> Right?
>> 
>> Regards,
>> RD
>> 
>> 
>> 
>>> 
>>> -d
>>> 
>>>> 
>>>> --
>>>> james woodyatt <jhw@apple.com>
>>>> member of technical staff, core os networking
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>