Re: [v6ops] PMTUD issue discussion

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 08 September 2014 22:11 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634DA1A03F5 for <v6ops@ietfa.amsl.com>; Mon, 8 Sep 2014 15:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fTGYDYQNMGn for <v6ops@ietfa.amsl.com>; Mon, 8 Sep 2014 15:11:34 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFD71A035F for <v6ops@ietf.org>; Mon, 8 Sep 2014 15:11:34 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id fp1so2091389pdb.14 for <v6ops@ietf.org>; Mon, 08 Sep 2014 15:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OIG8iZETxn7ZoW3huxKsC8mLV8y7tJD8KHRn98JjhY=; b=zvkG3qwD3IQZGcBrbbYPpuNBXRCrhfG2bTYWR+H1M+9E55MHMLGf0Pla7Dwyp4hd61 /iEKUaf+AQvaPxPfex4xSiydsp0a3pw23xYhKxuAKCUzYiBiLpdsDDj3ho5nZekQzZqd oIrhBnpweUXs66dEuCWU3Dnjw8gu7KKBdydblsRa0jlrx2PVdAyXJUSNV8IUdE4IwxZD 6Ct6+CEptormxvMEbB0vN2Vi8qRfTFbZ477bGF4/93hw0+CQDeb76kIchTsH1Orv05DD rXkw2WDi4oZq7MbXk+gY+5DzyuOGQSrkRzDbzoRhduZNFEAwo+fZ31ylyHwVq1GqBH97 30dA==
X-Received: by 10.70.96.74 with SMTP id dq10mr51968430pdb.112.1410214294261; Mon, 08 Sep 2014 15:11:34 -0700 (PDT)
Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id na4sm9867279pdb.96.2014.09.08.15.11.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 15:11:33 -0700 (PDT)
Message-ID: <540E2995.1020208@gmail.com>
Date: Tue, 09 Sep 2014 10:11:33 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <CAPi140PMeM9omtm11+NHa2ywUfof_tE7HknKExtoEb32mm7L_w@mail.gmail.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <CAEmG1=redpYUnv9R-uf+cJ4e+iPCf6zMHzVxeKNMGjcC=BjR+Q@mail.gmail.com> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> <540A6645.7020408@gmail.com> <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r_ENbrEnK2KOHnFXcDKAVY0Vxuk
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Tom Perrine <tperrine@scea.com>, Fernando Gont <fgont@si6networks.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [v6ops] PMTUD issue discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 22:11:36 -0000

Fred,

On 09/09/2014 06:47, Templin, Fred L wrote:
> Hi Brian,
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Friday, September 05, 2014 6:41 PM
>> To: Templin, Fred L
>> Cc: Joe Touch; Fred Baker (fred); Fernando Gont; v6ops@ietf.org; Tom Perrine; Fernando Gont
>> Subject: Re: [v6ops] PMTUD issue discussion
>>
>> On 06/09/2014 02:48, Templin, Fred L wrote:
>>>> -----Original Message-----
>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch
>>>> Sent: Friday, September 05, 2014 7:00 AM
>>>> To: Fred Baker (fred); Fernando Gont
>>>> Cc: v6ops@ietf.org; Tom Perrine; Fernando Gont
>>>> Subject: Re: [v6ops] PMTUD issue discussion
>>>>
>>>>
>>>>
>>>> On 9/4/2014 5:58 PM, Fred Baker (fred) wrote:
>>>>> On Sep 5, 2014, at 10:47 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>>>>
>>>>>> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote:
>>>>>>> On Sep 5, 2014, at 9:33 AM, Fernando Gont <fernando@gont.com.ar>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> What happens when/if such lins employ v6 (whether they really
>>>>>>>> offer a "virtual" MTU >=1280).. I just don't know.
>>>>>>> 802.15.4?
>>>>>> No. I seem to recall that it was more of a packet radio sort of thing
>>>>>> (something predating 802.15.4). I could ask some folks if interested
>>>>>> in more details...
>>>>> I think you missed my point. We have a case in point today, which is
>>>>> IPv6 in an IPv6 tunnel encapsulation running on a packet network whose
>>>>> MTU is 127 bytes. We call it "6lowpan", and it runs on IEEE 802.15.4.
>>>> That's not IPv6. I don't know what it is, but RFC2460 is clear on the
>>>> minimum MTU for IPv6.
>>> Joe is right - for IPv6 there is only one magic number (1280). Beyond
>>> that, any size up to and including jumbograms must be accommodated,
>>> subject to path MTU limitations.
>> Actually jumbograms, according to RFC 2675, are only available
>> when the *link* MTU is big enough:
>>
>> "  The Jumbo Payload option is relevant only for IPv6 nodes that may be
>>    attached to links with a link MTU greater than 65,575 octets (that
>>    is, 65,535 + 40, where 40 octets is the size of the IPv6 header).
>>    The Jumbo Payload option need not be implemented or understood by
>>    IPv6 nodes that do not support attachment to links with MTU greater
>>    than 65,575."
>>
>> Note that it says "nodes", so it applies to routers as well as hosts.
>> My recollection is that efficent use of HIPPI within data centres
>> was the main motivation for jumbograms, and there is no expectation
>> that they will work on the Internet in general. Running jumbograms
>> over an adaptation layer would be craziness.
>>
>> Also
>> "  The Jumbo Payload option must not be used in a packet that carries a
>>    Fragment header."
>>
>> So I think it's "any size up to 65,575 octets" that must be
>> accomodated. Jumbograms are optional.
> 
> The key phrase in my text that you quoted was "subject to path MTU
> limitations". For example, if the source's IPv6 layer presents a 4MB
> packet, and if all links in the path support an MTU that is at least
> that large, then the packet will be forwarded to the destination just
> fine. If the path MTU is deficient at any hop along the path, however,
> the packet is dropped and a PTB message returned.
> 
> We may be a long way off from having paths in the Internet (or even
> in private networks) that supports such large sizes, but the protocols
> will be ready when and if such links come online.

The key phrase in my comment was "Jumbograms are optional" (which
is explicit in RFC 6434). So the only Internet-wide expectation
is a maximum of 65,575, and that is the largest size that can ever
be fragmented.

   Brian