IETF Logo Mail Archive

Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

Bill Jouris <bill.jouris@insidethestack.com> Thu, 20 June 2013 22:32 UTC

Return-Path: <bill.jouris@insidethestack.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 A934F21F9E59 for <ipv6@ietfa.amsl.com>; Thu, 20 Jun 2013 15:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
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 hb6dL29jLm9V for <ipv6@ietfa.amsl.com>; Thu, 20 Jun 2013 15:32:38 -0700 (PDT)
Received: from nm25-vm0.access.bullet.mail.sp2.yahoo.com (nm25-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.184]) by ietfa.amsl.com (Postfix) with ESMTP id 91AA221F9E1B for <ipv6@ietf.org>; Thu, 20 Jun 2013 15:32:38 -0700 (PDT)
Received: from [98.139.44.99] by nm25.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000
Received: from [98.139.44.89] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000
Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 894896.8173.bm@omp1026.access.mail.sp2.yahoo.com
Received: (qmail 34838 invoked by uid 60001); 20 Jun 2013 22:32:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371767557; bh=Zi2kdhxGKgaicaLT3rQRrdFdiUQA03XQ26TDOdayqbA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CYZt4+frrlCQVRfNk6jsFGpb1OSfjxwEDyHx0nyF/e+rDgjj+ZLGMhtWHjWvVVLIiHiw49MD780DbJ1v4rln/QdQs+morNIfP4D1+bRuPnpKGYIpAFJNh2aTj9ErSJiBJkXrNj/3n7US/TAD/I3KE8I+1+SeTeo6OISt4Zv0t6g=
X-YMail-OSG: _4JdUBkVM1nmfoe7y8ouK_u5QKucCEsskPgU4NMPhnY4Pk1 0agqJ7KzEhpFEAaV2LzLF1YKKfVrOJEKvRLE6rW8PVSNNjCW7CbuaJj9Yu_P fg511kb1bfDm18GFvJtkP_Pxg_rJwYrEuiO4fypKX6mIFQP1Zip9hY36ixVE DJozhbThatTGh3Lihl_hhDvbdgE8YGWqmy3.DCNfeb57JdcqbM3GxyLeeEJY nvX.CX3GGyh32TmvN.5JGO8b1SbZYxAVwn1ri6yhpEXwM0hBHzgHraCnxSTW et0BB9vHTRPOI2GUZu_1pUYqHkpInCGiMnxUAHKR3MwQ84LhfDmEbS4b3Xr2 bOjGWNRyxuwxNRTOzU5j2ei6RrI2UM_U56C0vnk3tvKWckU5KHfF8aWY.jZt FLC7fOT5sBlYEURrKmDKsscSRmy5h5.7oXuiMv5Ua1dBxiTXbK8cBcCeAAPF _Ky0jSsBDqd_eUwgF.ZhL.mo4i.zT.zviftpDj1pkfHzcl3f3onw4Ub5fCaM vFr7ZhrQYVr.9QYCF_fJuTew5.zGHGUfubQ1uCJ5G5Bf9Be5I.XYA7rnASSR AcpK2DPkDuzuLnnsXwnsrk.BN5KGml9X6A4fH.hStlLBwND1s9qexeUfsn17 oCjaFzHnSb.g_V_ZQLlJLGg--
Received: from [50.143.174.186] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 20 Jun 2013 15:32:37 PDT
X-Rocket-MIMEInfo: 002.001, SXMgaXQgdGhhdCB0aGUgb3BlcmF0aW9uYWwgKnJlcXVpcmVtZW50KiBpcyBsZXNzP8KgIE9yIHRoYXQgdGhlIGN1cnJlbnQgb3BlcmF0aW9uYWwgKmNhcGFiaWxpdHkqIGlzIGxlc3M_CgpJdCBzZWVtcyBsaWtlLCBnaXZlbiB0aGUgUkZDLCB0aGUgcmVxdWlyZW1lbnQgaXMgbm90IHlldCB3aXRoaW4gdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGV4aXN0aW5nIGJhY2tib25lLsKgIFdoaWNoIGlzLCBhdCBtb3N0LCBhbiBhcmd1bWVudCBmb3IgYWxsb3dpbmcgc29tZSBhZGRpdGlvbmFsIHRpbWUgZm9yIHRoZSBiYWMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.148.554
References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <F13710AB-0E74-45D1-81A6-1F22D01D5403@steffann.nl> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <m28v2ejufg.wl%randy@psg.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> <013101ce6944$cbb62e90$63228bb0$@tndh.net> <CAKD1Yr0XLG2yWdAR_vAwtubiZ_HdSXDe-KnCRHYorAQyN2GtYw@mail.gmail.com>
Message-ID: <1371767557.28978.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com>
Date: Thu, 20 Jun 2013 15:32:37 -0700
From: Bill Jouris <bill.jouris@insidethestack.com>
Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)
To: "v6ops@ietf.org WG" <v6ops@ietf.org>
In-Reply-To: <CAKD1Yr0XLG2yWdAR_vAwtubiZ_HdSXDe-KnCRHYorAQyN2GtYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1551098171-1454117559-1371767557=:28978"
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bill Jouris <bill.jouris@insidethestack.com>
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: Thu, 20 Jun 2013 22:32:43 -0000

Is it that the operational *requirement* is less?  Or that the current operational *capability* is less?

It seems like, given the RFC, the requirement is not yet within the capability of the existing backbone.  Which is, at most, an argument for allowing some additional time for the backbone to be upgraded.  And (since the RFC is how many years old by now?) not necessarily an enormous amount of additional time.

 
Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)




________________________________
 From: Lorenzo Colitti <lorenzo@google.com>
To: Tony Hain <alh-ietf@tndh.net> 
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>; IETF IPv6 Mailing List <ipv6@ietf.org> 
Sent: Friday, June 14, 2013 3:15 PM
Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)
 


On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain <alh-ietf@tndh.net> wrote:

Focus on the real operational requirement  (firewall functionality), then make sure that the constraint automatically tracks evolution in firewall
>functionality. Getting there leads to L4 in the first fragment, and anything
>else leads to artificial constraints that will need to be redone, if that is
>even possible.
>

The problem with that approach is that for a very substantial fraction of Internet backbones, the real operational requirement is substantially *less* capable than what is written in RFC 2460 and than what you propose here.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email