IETF Logo Mail Archive

RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 14 October 2013 19:55 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 2B80311E81A3; Mon, 14 Oct 2013 12:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.482
X-Spam-Level:
X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 RJrnivfBp7yA; Mon, 14 Oct 2013 12:55:26 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 179E611E816D; Mon, 14 Oct 2013 12:55:10 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r9EJt5Eb001824; Mon, 14 Oct 2013 14:55:05 -0500
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r9EJt4eX001804 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 14 Oct 2013 14:55:05 -0500
Received: from XCH-BLV-207.nw.nos.boeing.com (10.57.37.63) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 14 Oct 2013 12:55:04 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-207.nw.nos.boeing.com ([10.57.37.63]) with mapi id 14.03.0158.001; Mon, 14 Oct 2013 12:55:03 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Thread-Topic: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Thread-Index: AQHOyRRhebc9KTehbEGO6mhunuAlj5n0mDGA
Date: Mon, 14 Oct 2013 19:55:02 +0000
Message-ID: <2134F8430051B64F815C691A62D9831812D8F7@XCH-BLV-504.nw.nos.boeing.com>
References: <20131002185522.20697.96027.idtracker@ietfa.amsl.com> <9300F272-E282-41C3-9DA8-59134B975FC7@employees.org> <9e33a47bb2834c15ba4269ae8c79c46f@BLUPR05MB433.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D9831811EB23@XCH-BLV-504.nw.nos.boeing.com> <D1F5CE61-253E-4F07-AED1-4A4AB4C4AB68@employees.org> <2134F8430051B64F815C691A62D9831811EE66@XCH-BLV-504.nw.nos.boeing.com> <E29381FD-C839-4DBA-8711-3A4EBA83E379@employees.org> <2134F8430051B64F815C691A62D9831811EF1C@XCH-BLV-504.nw.nos.boeing.com> <5255D6EE.4050300@gmail.com> <2134F8430051B64F815C691A62D9831811F688@XCH-BLV-504.nw.nos.boeing.com> <5257AD5E.9090806@globis.net> <5257B870.1060003@si6networks.com> <2134F8430051B64F815C691A62D9831812C120@XCH-BLV-504.nw.nos.boeing.com> <52582F8B.8040306@si6networks.com> <52585658.50205@gmail.com> <2134F8430051B64F815C691A62D9831812C654@XCH-BLV-504.nw.nos.boeing.com> <52587EB8.4020506@gmail.com> <2134F8430051B64F815C691A62D9831812D718@XCH-BLV-504.nw.nos.boeing.com> <525C473D.4080403@gmail.com>
In-Reply-To: <525C473D.4080403@gmail.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Cc: Fernando Gont <fgont@si6networks.com>, 6man Mailing List <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Ray Hunter <v6ops@globis.net>
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, 14 Oct 2013 19:55:44 -0000

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Monday, October 14, 2013 12:34 PM
> To: Templin, Fred L
> Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> Fred,
> 
> On 15/10/2013 06:38, Templin, Fred L wrote:
> ...
> >> We could have that discussion in 6man, sure, but I don't believe
> that
> >> it's
> >> relevant to the question of whether draft-ietf-6man-oversized-
> header-
> >> chain
> >> is ready.
> >
> > If it messes up tunnels, then it's not ready.
> 
> That doesn't follow. See below.
> 
> >> This draft mitigates a known problem in terms of the current
> >> IPv6 standards.
> >
> > If that problem is also mitigated by a measure that does not mess
> > up tunnels, then wouldn't that be worth considering before
> > finalizing this publication.
> 
> The draft mitigates a known problem with communication paths that
> do not include nested tunnels requiring nested fragmentation,
> where the nested tunnel has to deal with an MTU <1280 *and* where
> the nested tunnel goes through a firewall that wants to analyse
> the complete header chain of the innermost packet.

But tunnels - and tunnels within tunnels - need to be considered
as part of the architecture. I have visibility into the network
operations of a major multi-national corporation, and I can tell
you that I see tunnels within tunnels in operational practice today.
I also have visibility into civil aviation and DoD networks, and
I see an emerging trend for mobile networks. Consider a mobile
network B that comes onto a link offered by mobile network A.
Then, mobile network C comes onto a link offered by B. Then, etc.
Then, the next thing you know, it's turtles all the way down.

Fragmentation is the tool that enables endless recursion. Or, at
least, recursion up to some defined limit. At least for the first
several levels of recursion, middleboxes should be able to see all
host-inserted headers within the first fragment.

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


> No, I don't think it's worth considering that case before specifying
> this mitigation.
> 
>      Brian

v2.34.0 | Report a Bug | By Email | System Status