IETF Logo Mail Archive

RE: Meta-issues: On the deprecation of the fragmentation function

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 10 July 2013 19:39 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 D9A1B21F9EBD for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2013 12:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn8R+YQ0+snK for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2013 12:39:30 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2D21F9EB7 for <ipv6@ietf.org>; Wed, 10 Jul 2013 12:39:30 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r6AJdTBE016894 for <ipv6@ietf.org>; Wed, 10 Jul 2013 14:39:29 -0500
Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r6AJdSCv016872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Jul 2013 14:39:29 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.89]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 12:39:28 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: james woodyatt <jhw@apple.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Meta-issues: On the deprecation of the fragmentation function
Thread-Topic: Meta-issues: On the deprecation of the fragmentation function
Thread-Index: AQHOfZp7EVtgyhVSFES4anVAs4ggI5leTEDg
Date: Wed, 10 Jul 2013 19:39:27 +0000
Message-ID: <2134F8430051B64F815C691A62D983180B86A9@XCH-BLV-504.nw.nos.boeing.com>
References: <FAD482FE-4583-472A-8B57-E789A942686E@gmail.com> <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC48F7.2080901@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FA39E2@BL2PRD0512MB646.namprd05.prod.outlook.com> <51DC5955.4030700@dougbarton.us> <2CF4CB03E2AA464BA0982EC92A02CE2509FB8317@BY2PRD0512MB653.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180B812F@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2509FBAB7B@BY2PRD0512MB653.namprd05.prod.outlook.com> <B5A72885-678A-442A-86D7-D710D2324A28@apple.com>
In-Reply-To: <B5A72885-678A-442A-86D7-D710D2324A28@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
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: Wed, 10 Jul 2013 19:39:36 -0000

Hi James,

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> james woodyatt
> Sent: Wednesday, July 10, 2013 11:23 AM
> To: ipv6@ietf.org
> Subject: Re: Meta-issues: On the deprecation of the fragmentation
> function
> 
> On Jul 10, 2013, at 08:49 , Ronald Bonica <rbonica@juniper.net> wrote:
> > [...]
> > Probably, the best alternative is for the tunnel ingress router to
> tunnel ingress router to discover the PMTU to the egress. When the
> tunnel ingress router receives a packet that is so large that it cannot
> be forwarded through the tunnel, it discards the packet and sends an
> ICMP PTB to the packet's originator. The packet's originator then
> modifies its sending behavior based upon its new estimate of the PMTU
> associated with the destination.
> > [...]
> 
> ICMPv6 packet too big errors are unreliable on the real-world Internet.
> 
> I hate to sound like a broken record, but I will: I look forward to
> reviewing a proposal to update to Generic Packet Tunneling in IPv6 [RFC
> 2473] for implementing tunnel path MTU discovery at the encapsulation
> layer [c.f. RFC 4821].

Wrap your RFC2473 tunnel in SEAL and you are good to go
(see draft-templin-intarea-seal). A quick read of Section
4 of my new draft should be all you need to understand
what I'm talking about:

  http://tools.ietf.org/html/draft-generic-6man-tunfrag-08


Note however that all the tunnel needs is a limited application
of RFC4821 to ensure that the *required* packet sizes are
accommodated. For larger packets, assume that the hosts sending
large packets are using RFC4821 themselves (so the tunnel doesn't
have to). All the tunnel needs to do is "take care of the smalls,
and let the bigs take care of themselves".

Thanks - Fred
fred.l.templin@boeing.com

> --
> james woodyatt <jhw@apple.com>
> core os networking
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email