Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
Robert Raszuk <robert@raszuk.net> Tue, 14 July 2020 19:40 UTC
Return-Path: <robert@raszuk.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 225BF3A09F3 for <ipv6@ietfa.amsl.com>; Tue, 14 Jul 2020 12:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 57LMNr-hMb4a for <ipv6@ietfa.amsl.com>; Tue, 14 Jul 2020 12:39:57 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233603A084E for <6man@ietf.org>; Tue, 14 Jul 2020 12:39:56 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a21so3962433ejj.10 for <6man@ietf.org>; Tue, 14 Jul 2020 12:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=00WzxrFwWp5UFh190Zx01SVUPcI+SUjJ6w1V34FUz5Q=; b=OzILqM+vda+kxwajIgYmkAbziIc5lrwoCyB9i+hX7gpQXzkqkNiGfk/+CLMg9hFDkK C9xwv6+nCJ3zpgjipfTQ9TGeLysRckTx/KyhOh5Aoxoq2Bph5ggRp7SQgVtARDXhjBvR F/sWl0H4xLW/vZs2hP1qh72ME8pUi+9MhknP6AsnUuBesMpQJXlp3qfO8KuBcbcS7/qh NlS0FKqgcj0tnFzdbOF8Mt8tDoz2LfZ459bPVxX+W5MNvw5d7CNE3G48rAj6NpP1rbif JmD3sKQrKo3sGTQjUrlfX3DSCOGc2uPs5Fox50jG1Rs9YvnGXHN5TncrFjXx6h8XpY4w u3rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=00WzxrFwWp5UFh190Zx01SVUPcI+SUjJ6w1V34FUz5Q=; b=DEwMwZGbaisFWFtpfAxtcTszgW71ThDPByRAa2WM7kYrpLz6RDTVl/yNemkzUyAyZW iP/z834L9yLbQI6q746dTpYTvwm3mohCz39d//JO6wpAbvOt45qUx+oUpISHyBIEdwpJ Dz1is9QJQvr6RqY51pAJvRpBwoGVGDyF5PBKtewG6chAcJEM3typhz/urILcrHQX7LEQ IRw4FDEnzZJRSYAjS/xaBwsSlmWM60qmXh0xVBY93FLYork//FYnGjpMsBdxmVoGXEc+ RFHjRvIYi8IcGLpfCiEqx+s6WZzOJadInvMpDzm2JlsMmwWPV6NVNjBJ/zpIip9jqL/+ LpiA==
X-Gm-Message-State: AOAM530Oqlhq5o8xWzDN29eNn86g6telIvALgbelzwEGAxgK194wPrIH pSRxP1960p1tUW8mNgFX/fFpgBHB2P/wk+pBPiLVzdIw
X-Google-Smtp-Source: ABdhPJwSPT54denZ7jngQp8loO3xa61QboHNhETqa4C2o5NuQa2Aafq2QjiWLZ2kvZ3cXa1cxJAq9NMod5NpdJh5ul0=
X-Received: by 2002:a17:906:e210:: with SMTP id gf16mr5818323ejb.386.1594755595345; Tue, 14 Jul 2020 12:39:55 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR05MB6348708352E1EE4421A61D63AE650@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S34e21BLHRfx+p7agrzzDsx-M-XxB6cZQnWc-d0wqSesRQ@mail.gmail.com> <DM6PR05MB6348BCE5DDB6A8AF52D04FFAAE650@DM6PR05MB6348.namprd05.prod.outlook.com> <20200713191832.GC38490@faui48f.informatik.uni-erlangen.de> <CALx6S34TzXzHY1SK7te6-bcxO8V=kE1+o1AjL2S2oAPVTNbTBg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE19160AFC@DGGEML532-MBX.china.huawei.com> <CABNhwV1w0JS0Rz-8KWUGAZ8o577=ciWgVXn9SLxS-sA5mjsRHA@mail.gmail.com> <20200714073612.GM38490@faui48f.informatik.uni-erlangen.de> <BYAPR11MB3207F6893A9A66F23B6564E0C0610@BYAPR11MB3207.namprd11.prod.outlook.com> <CALx6S37JxsYHJGcB0iq_96OJHqsyYR=zbBpcmnAG5+zDBVc5XA@mail.gmail.com>
In-Reply-To: <CALx6S37JxsYHJGcB0iq_96OJHqsyYR=zbBpcmnAG5+zDBVc5XA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 14 Jul 2020 21:39:45 +0200
Message-ID: <CAOj+MMFZXAQJ8kUQxvbU8fWhsq5OL1AGpFeoEuq8xf+1Fr3Wuw@mail.gmail.com>
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
To: Tom Herbert <tom@herbertland.com>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c3b64505aa6bf888"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BUKU0xasv-b87uYoP5Gebg9Tbdo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 14 Jul 2020 19:40:02 -0000
I am watching this thread and have one question ... how any draft can mandate to any implementation how it should process a packet ? One implementation can use 100% programmable hardware, the other can not. Some process all packets in CPUs. Some may offload some processing to on line card CPU vs punting it to RE/RP. Some may punt only first packet and then install forwarding state in the dataplane so any subsequent packets are fully hardware switched. I am really not sure what is the value of this thread .... Many thx, R. On Tue, Jul 14, 2020 at 9:24 PM Tom Herbert <tom@herbertland.com> wrote: > On Tue, Jul 14, 2020 at 12:03 PM Jakob Heitz (jheitz) > <jheitz=40cisco.com@dmarc.ietf.org> wrote: > > > > BFD is a control function by definition, but is executed on the line > card. > > Is it in the data plane or the control plane? > > A label action that causes a second lookup may occur in one pass or > > may require to recirculate the packet for a second pass. > > To walk the list of extension headers to find the TCP ports to run an ACL > > may be done inline or require more passes. > > How slow is the slow path? > > > > There was a time when TCP SYNs were processed in the slow control > plane path, but then that gave rise to some very effective SYN attacks > and we quickly realized that they really need to be processed in the > fast path. Subsequently, we have seen this story line repeat itself > time and time again at several levels of the stack: "slow path" in the > data path == "DOS vector" in the data path. The answer is either to > change the implementation to be able to process more efficiently, or > to limit the processing it's willing to do which is okay if the > potential limits are commonly understood. > > Tom > > > Regards, > > Jakob. > > > > -----Original Message----- > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Toerless Eckert > > Sent: Tuesday, July 14, 2020 12:36 AM > > To: Gyan Mishra <hayabusagsm@gmail.com> > > Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; 6man@ietf.org > > Subject: Re: Death by extension header (was:RE: New Version Notification > for draft-li-6man-hbh-fwd-hdr-00.txt) > > > > Hi Gyan, > > > > On Tue, Jul 14, 2020 at 02:37:12AM -0400, Gyan Mishra wrote: > > > >From a historical perspective the slow path and fast path has some > vendor > > > connotations into it ???cxxxx???. > > > > I think its used pretty consistently throughout the industry. > > If you have an example of a router that has something other vendors > > would call slowpath but calls it differently, i would be interested to > > know such alternative terms. > > > > > I think any document within the IETF should stay clear of anything > that is > > > a vendor terminology. > > > > Definitely agreed if something is really specific to a subset of vendors > > instead of the most widely used term. I think its the most widely used > term. > > > > > The concept of ???punt??? meanIng send to control plane also has vendor > > > connotation and should not be used. > > > > I think the same applies here as what i said above for slow/fast path. > > > > Btw: these are just comments about my best understanding about > terminology. > > Not an endorsement to base any upcoming work on those terms. I already > > sent emails as to the opposite. > > > > > I personally like control plane and data plane processing of extension > > > headers. > > > > Do you have a good definition for control-plane and data-plane > processing ? > > E.g.: inband-signaling, is that decidedly control-plane for data-plane > > to you ? > > > > Cheers > > Toerless > > > > > Gyan > > > > > > On Mon, Jul 13, 2020 at 11:35 PM Pengshuping (Peng Shuping) < > > > pengshuping@huawei.com> wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > > > > > Sent: Tuesday, July 14, 2020 3:31 AM > > > > > To: Toerless Eckert <tte@cs.fau.de> > > > > > Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; > 6man@ietf.org > > > > > Subject: Re: Death by extension header (was:RE: New Version > Notification > > > > > for draft-li-6man-hbh-fwd-hdr-00.txt) > > > > > > > > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert <tte@cs.fau.de> > wrote: > > > > > > > > > > > > And now find me any single IETF RFC that even uses the term > slow-path > > > > > > and fast-path to formalize requirements against them. We are > just not > > > > > > explicit enough about this. Hence my example of redooing > router-alert > > > > > > as the most simple example. Not that i think this would be most > > > > > > important, but just to make the community consider that we need > to be > > > > > > more diligent about protocol specs in this respect. > > > > > > > > > > > > > > > > Toerless, > > > > > > > > > > I wouldn't expect any IETF to use the term "slow path" and "fast > path". > > > > RFCs > > > > > tend to describe protocol behavior and generally themselves don't > care > > > > > whether they are processed in a slow path or fast path as long as > the > > > > > external behavior is conformant. If you want to make these terms > > > > explicit it > > > > > seems like we would need to quantify in exact terms what a slow > path is > > > > and > > > > > exactly what a fast path is-- that is, they need normative > definitions > > > > if we are > > > > > to set normative requirements around them. > > > > > > > > But do we still need to differentiate "control plane" and "forwarding > > > > plane"? The processing capability in bps and pps of the two planes > are > > > > different, so the corresponding terms are used as "slow path" and > "fast > > > > path", respectively. > > > > > > > > There are some HBH options such as RA* that carry the information > that > > > > need to be consumed by the "control plane", so they will be sent to > the > > > > "control plane" anyway. While other HBH options carry the > information that > > > > will not be consumed by the "control plane" but still sent to the > "control > > > > plane" / "slow path", which cause problems. > > > > > > > > * > > > > > https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml#ipv6-routeralert-values-1 > > > > > > > > Shuping > > > > > > > > > > > > > > Tom > > > > > > > > > > > Some maximum amount of fast-path extensions is already in specs > as an > > > > > > example, but it too is not comprehensive enough to feel more > confident > > > > > > about safe extensibility. > > > > > > > > > > > > And we need to break free of the rfc8200 constraints whenever we > > > > > > deploy the network protocol in controlled networks. rfc8200 is > such a > > > > > > career limiter when comparing IPv6 with MPLS for this type of > > > > > > use-cases. Not to speak of the unnecessary long addresses. > > > > > > > > > > > > Oh well... > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > On Fri, Jul 10, 2020 at 06:43:59PM +0000, Ron Bonica wrote: > > > > > > > Tom, > > > > > > > > > > > > > > Given that you parse the extension header chain on the fast > path, HBH > > > > > and destination options can be categorized as follows: > > > > > > > > > > > > > > 1) unrecognized (ACT 00, 01, 10, and 11) > > > > > > > 2) recognized and processed on the fast path > > > > > > > 3) recognized and processed on the slow path > > > > > > > > > > > > > > Types 1 and 2 cannot be used in a DoS attack, because they are > never > > > > > sent to the slow path. Type 3 is the dangerous one. > > > > > > > > > > > > > > I think that an implementation is safe if it only recognizes > options > > > > that it > > > > > can process on the fast path. It may also be safe if it severely > rate > > > > limits > > > > > packets as it sends them to the slow path. > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > > Sent: Friday, July 10, 2020 2:29 PM > > > > > > > To: Ron Bonica <rbonica@juniper.net> > > > > > > > Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; > > > > > > > 6man@ietf.org > > > > > > > Subject: Re: Death by extension header (was:RE: New Version > > > > > > > Notification for draft-li-6man-hbh-fwd-hdr-00.txt) > > > > > > > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica < > rbonica@juniper.net> > > > > > wrote: > > > > > > > > > > > > > > > > Tom, > > > > > > > > > > > > > > > > I am forking a new thread since this is not directly related > to > > > > Shuping's > > > > > draft. > > > > > > > > > > > > > > > > Any variable length extension header can be used in a DoS > attack. > > > > So, if > > > > > a node encounters a packet that satisfies any of the following > criteria, > > > > it > > > > > should discard the packet and send an ICMP message as described in > > > > > > > > > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-6ma > > > > > n-icmp-limits-03__;!!NEt6yMaO-gk!XnKPvkz9vBtVNlSCx0SqcojVpo2uBgeSDJ > > > > > zZEJa2fLd1NTKb53H0w3Ue2Xxv7iGB$ . > > > > > > > > > > > > > > > > - The extension header chain is longer than the node can > process > > > > > > > > - An individual extension header is longer than the node can > > > > > > > > process > > > > > > > > - The total number of options contained by all instances of > the > > > > HBH and > > > > > Destination Options header exceeds the number or options that the > node > > > > > can process. > > > > > > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > > > Right, those are the ICMP errors for the allowance to drop or > ignore > > > > > extension headers in section 5.3 of RFC8504, there's also default > limits > > > > > suggested in that doc. Do you think this is sufficient in routers > to get > > > > past the > > > > > DOS concern? > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > > > Sent: Friday, July 10, 2020 1:13 PM > > > > > > > > To: Ron Bonica <rbonica@juniper.net> > > > > > > > > Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; > > > > > > > > 6man@ietf.org > > > > > > > > Subject: Re: New Version Notification for > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt > > > > > > > > > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 7:59 AM Ron Bonica > > > > > <rbonica=40juniper.net@dmarc.ietf.org> wrote: > > > > > > > > > > > > > > > > > > Peng, > > > > > > > > > > > > > > > > > > While your solution may require refinement, I think that > you have > > > > > latched on to a problem that needs to be solved. HBH Options, as > they > > > > were > > > > > originally conceived in RFC 1883, are very useful. > > > > > > > > > > > > > > > > > > When IPv6 was first implemented on high-speed routers > (circa > > > > 2000), > > > > > HBH options were not yet well-understood and ASICs were not so > capable as > > > > > they are today. So, early IPv6 implementation dispatched all > packet that > > > > > contain HBH options to their slow path. In these implementations, > a large > > > > > flow of IPv6 packets could congest the slow path, causing other > critical > > > > > functions that are executed on the slow path to fail. These > critical > > > > functions > > > > > include routing and network management. > > > > > > > > > > > > > > > > > > To mitigate this DoS vulnerability, many operators deployed > > > > Access > > > > > Control Lists (ACLs) that discard all packets containing HBH > Options. > > > > This > > > > > introduced a circular problem: > > > > > > > > > > > > > > > > > > - An implementation problem caused HBH to become a DoS > vector > > > > > > > > > - Because HBH was a DoS vector, network operators deployed > ACLs > > > > > > > > > that discard packets containing HBH > > > > > > > > > - Because network operators deployed ACLs that discard > packets > > > > > > > > > containing HBH, network designers stopped defining new HBH > > > > > > > > > Options > > > > > > > > > - Because network designers stopped defining new HBH > Options, > > > > > > > > > the community was not motivated to fix the implementation > > > > > > > > > problem that cause HBH to become a DoS vector > > > > > > > > > > > > > > > > > > If we can fix the implementation problem that caused HBH to > > > > > become a DoS vector, we can break this cycle and start using HBH > Options. > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > > > > > I think there were "protocol problems" in the original > design of > > > > HBH. > > > > > > > > The requirement that _all_ routers in the path process > Hop-by-Hop > > > > > options was in retrospect too austere, and the possibility that an > > > > attacker > > > > > could stuff a packet with hundreds of bogus options, only limited > by MTU, > > > > > was, again in retrospect, a pretty obvious DOS vector. > > > > > > > > I believe these problems have been addressed in RFC8200 and > > > > > RFC8504. > > > > > > > > We certainly welcome the feedback from router vendors > whether these > > > > > mitigations are sufficient to make HBH options deployable. > > > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > Let's continue to work on a solution. > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of > Pengshuping > > > > > > > > > (Peng > > > > > > > > > Shuping) > > > > > > > > > Sent: Thursday, July 2, 2020 12:07 PM > > > > > > > > > To: 6man@ietf.org > > > > > > > > > Subject: FW: New Version Notification for > > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt > > > > > > > > > > > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Folks, > > > > > > > > > > > > > > > > > > We have just uploaded a new draft aiming to analyze and > tackle > > > > the > > > > > issues faced by the Hop-by-Hop Options Header, which has been > sparsely > > > > > used without any form of large scale deployment. > > > > > > > > > > > > > > > > > > However, as IPv6 is being rapidly and widely deployed > worldwide, > > > > > more and more new services that requires hop-by-hop forwarding > process > > > > > behavior are emerging, and also the already defined over ten HBH > Options > > > > > are going to be used widely in practice. > > > > > > > > > > > > > > > > > > We look forward to hearing your feedback and comments, and > try to > > > > > release the benefits that could be provided by HBH Options header > > > > > altogether. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Shuping > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: internet-drafts@ietf.org [mailto: > internet-drafts@ietf.org] > > > > > > > > > Sent: Thursday, July 2, 2020 11:31 PM > > > > > > > > > To: Lizhenbin <lizhenbin@huawei.com>; Pengshuping (Peng > Shuping) > > > > > > > > > <pengshuping@huawei.com> > > > > > > > > > Subject: New Version Notification for > > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has > been > > > > > successfully submitted by Shuping Peng and posted to the IETF > repository. > > > > > > > > > > > > > > > > > > Name: draft-li-6man-hbh-fwd-hdr > > > > > > > > > Revision: 00 > > > > > > > > > Title: Hop-by-Hop Forwarding Options Header > > > > > > > > > Document date: 2020-07-03 > > > > > > > > > Group: Individual Submission > > > > > > > > > Pages: 10 > > > > > > > > > URL: > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6 > > > > > man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00d > > > > > bzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$ > > > > > > > > > Status: > > > > > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man- > > > > > hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S > > > > > 4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$ > > > > > > > > > Htmlized: > > > > > > > > > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-f > > > > > wd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4C > > > > > G2fZYHGYeOXYwVmtNTFnzgPvsH43l$ > > > > > > > > > Htmlized: > > > > > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li- > > > > > 6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuC > > > > > mO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$ > > > > > > > > > > > > > > > > > > > > > > > > > > > Abstract: > > > > > > > > > RFC8200 specifies the HBH header that is assumed to be > > > > > processed by > > > > > > > > > each hop in the delivery path of the packet. However, > RFC8200 > > > > > also > > > > > > > > > expects that nodes processing the HBH header have been > > > > > explicitly > > > > > > > > > configured to do so. Therefore, it cannot be assumed > that a > > > > > HBH > > > > > > > > > header present in the packet is processed. It all > depends on > > > > the > > > > > > > > > configuration of each node across the path. Moreover, > in most > > > > > of > > > > > > > > > networks today, the processing of the HBH header is > done in > > > > the > > > > > > > > > control plane (slow processing path) which incurs > several > > > > > limitations > > > > > > > > > among which resources consumption and security risk. > > > > > > > > > > > > > > > > > > For these reasons, over time, the Hop-by-Hop Options > header > > > > > has been > > > > > > > > > sparsely used without any form of large scale > deployment. > > > > Also, > > > > > most > > > > > > > > > of already defined HBH options are forwarding options > which > > > > > contain > > > > > > > > > forwarding plane information that needs not to be sent > to the > > > > > control > > > > > > > > > plane. > > > > > > > > > > > > > > > > > > This document proposes a new Hop-by-Hop Forwarding > Options > > > > > Header in > > > > > > > > > order to carry Hop-by-Hop options that are solely > intended to > > > > > and > > > > > > > > > processed by the forwarding plane. This new HBH header > is > > > > > confined > > > > > > > > > in and dedicated to the forwarding plane while the > current HBH > > > > > header > > > > > > > > > can still be used for control plane options. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the > time of > > > > > submission until the htmlized version and diff are available at > > > > tools.ietf.org. > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > ---- IETF IPv6 working group mailing list ipv6@ietf.org > > > > > > > > > Administrative > > > > > > > > > Requests: > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf > > > > > > > > > o/ip > > > > > > > > > v6 > > > > > > > > > > > > > > __;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYe > > > > > OXY > > > > > > > > > wVmt > > > > > > > > > NT > > > > > > > > > FnzgEBbFhyl$ > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > ---- > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > ---- IETF IPv6 working group mailing list ipv6@ietf.org > > > > > > > > > Administrative > > > > > > > > > Requests: > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf > > > > > > > > > o/ip > > > > > > > > > v6 > > > > > > > > > > > > > > __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41H > > > > > tk > > > > > > > > > dIYu > > > > > > > > > Ds > > > > > > > > > XM8uyxPWt9N$ > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > ---- > > > > > > > > -------------------------------------------------------------------- > > > > > > > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative > > > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > -- > > > > > > --- > > > > > > tte@cs.fau.de > > > > > > > > > > > -------------------------------------------------------------------- > > > > > 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 > > > > -------------------------------------------------------------------- > > > > > > > -- > > > > > > <http://www.verizon.com/> > > > > > > *Gyan Mishra* > > > > > > *Network Solutions A**rchitect * > > > > > > > > > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > > > -- > > --- > > tte@cs.fau.de > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- Death by extension header (was:RE: New Version No… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Warren Kumari
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header Tom Herbert
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Pengshuping (Peng Shuping)
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Jakob Heitz (jheitz)
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header Joel M. Halpern
- Re: Death by extension header (was:RE: New Versio… Robert Raszuk
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header (was:RE: New Versio… Jeff Tantsura
- Re: Death by extension header Brian E Carpenter
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Philip Homburg
- Re: Death by extension header Nick Hilliard
- Re: Death by extension header (was:RE: New Versio… Robert Raszuk
- Re: Death by extension header Toerless Eckert
- Re: Death by extension header Toerless Eckert