Re: Death by extension header

[Toerless Eckert <[e-mail]>]

Latest dedicated firewalls will likely forward by CPU-flexible forwardine
plane elements, so if the packet can be parsed, a dedicated firewall is the likely
best device to do it. Comes with the territory. But given how end-to-end
encryption is making the classical firewall filtering less and less relevant,
firewalls struggle at a different level.

But firewall functionality is in every router these days, and the faster they
are, the worse typically their ability to corectly process christmas tree packets.

Also remember that the one key aspecct you didn't metion in your writeup below
is the state based forwarding, where you e.g.: have five-tuple forwarding
plane lookup and associated policies (block, permit, do-something-with-its-packets),
and you only punt packets for unknown flow so that the "foobar-plane" can
decide if/what new flow entry to create. I am saying foobar, because i am
not sure whether i wanted to call this 'punt-path' control plane. Classically
i think wee would have said so, but you can see how fuzzy these terms become
the closer you look at actual implementations.

Cheers
    Toerless

On Wed, Jul 15, 2020 at 02:59:52AM -0400, Gyan Mishra wrote:
> The slow & fast path concept has been around for decades as has been
> mentioned.  On older software based platforms, all feature processing was
> done in software, so there was a control plane hit for most every feature
> or any packet processing that required header lookup or IP options
> processing had a control plane hit.
> 
> Earlier on,  most routers were software based single processor, but as
> the routers got bigger and  became distributed processors with NPU per LC
> FIB data plane line rate processing in hardware became the new Norm.
> 
> The concept of "punting" to control plane in basic terms originally was
> coined for any flow that was router bound would be processed by the control
> plane thus a "processor hit" such as routing protocols packets.
>  Regardless of hardware or software based platforms distributed or
> centralized processor all router bound packets routing protocol packets
> ospf,bgp,isis etc hits the control plane for processing.
> 
> On most hardware based platforms both single or multi distributed processor
> platforms for many years  processing ACL, QOS, NAT has been done in
> hardware line rate in the data plane "forwarding plane".
> 
> A lot of what use to be done in the "slow path" control plane hit has
> transitioned to the data plane "fast" path at line rate including some EH
> processing.
> 
> There has been a lot of improvement over the years across vendor hardware
> related to EH processing and header chains.
> 
> However since the header chain is not bounded to a max allowed,  I guess
> with massive header chains you can still end up in the slow path even with
> high end routers. I think that's the major worry with operators and dropped
> packets from EH headers DDOS, especially with hbh.
> 
> I think the one big issue with header chains which I believe Fernando had
> written some documents on related to firewalls processing with EH chains as
> the transport layer comes after all the header chains,  that EH processing
> could break firewall filtering policy.
> 
> Does anyone know if that issue still exists today with firewalls vendors
> and EH processing especially with large header chains?
> 
> Gyan
> 
> 
> 
> 
> On Tue, Jul 14, 2020 at 8:48 PM Toerless Eckert <[e-mail]> wrote:
> 
> > Brian,
> >
> > Slowpath/fastpath predate ASIC/FPGA, otherwise you're right.
> >
> > On Wed, Jul 15, 2020 at 12:14:29PM +1200, Brian E Carpenter wrote:
> > > On 15-Jul-20 12:04, Jeff Tantsura wrote:
> > > > slow path usually means - punted to the central CPU (that runs control
> > plane)
> > >
> > > And isn't it true to say that the punting occurs when the packet header
> > is such that it cannot be processed by whatever ASIC or FPGA happens to be
> > present in the particular box? In other words, it is *not* because the
> > header contains an option that is specified to be "slow path" by nature;
> > it's dependent on the exact design of the router model.
> > >
> > >    Brian
> > >
> > > >
> > > > Cheers,
> > > > Jeff
> > > > On Jul 14, 2020, 5:01 PM -0700, Gyan Mishra <[e-mail]>,
> > wrote:
> > > >> Sorry I was thinking ???cisco fast switching???
> > > >>
> > > >> My fault I am good with those fast and slow and agree that is
> > industry standard nomenclature.
> > > >>
> > > >> Fast path = line rate processing in hardware data plane path
> > > >>
> > > >> Slow path = requires extra NPU control plane packet processing and is
> > processed In software and can impact control plane
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Jul 14, 2020 at 3:36 AM Toerless Eckert <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > > >>
> > > >>     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) <
> > > >>     > [e-mail] <mailto:[e-mail]>> wrote:
> > > >>     >
> > > >>     > >
> > > >>     > >
> > > >>     > > > -----Original Message-----
> > > >>     > > > From: ipv6 [mailto:[e-mail] <mailto:
> > [e-mail]>] On Behalf Of Tom Herbert
> > > >>     > > > Sent: Tuesday, July 14, 2020 3:31 AM
> > > >>     > > > To: Toerless Eckert <[e-mail] <mailto:[e-mail]>>
> > > >>     > > > Cc: Ron Bonica <rbonica=[e-mail]
> > <mailto:[e-mail]>>; [e-mail] <mailto:
> > [e-mail]>
> > > >>     > > > 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 <
> > [e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:
> > [e-mail]>>
> > > >>     > > > > > Sent: Friday, July 10, 2020 2:29 PM
> > > >>     > > > > > To: Ron Bonica <[e-mail] <mailto:
> > [e-mail]>>
> > > >>     > > > > > Cc: Pengshuping (Peng Shuping) <[e-mail]
> > <mailto:[e-mail]>>;
> > > >>     > > > > > [e-mail] <mailto:[e-mail]>
> > > >>     > > > > > 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 <
> > [e-mail] <mailto:[e-mail]>>
> > > >>     > > > 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
> > <
> > 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 <[e-mail] <mailto:
> > [e-mail]>>
> > > >>     > > > > > > Sent: Friday, July 10, 2020 1:13 PM
> > > >>     > > > > > > To: Ron Bonica <[e-mail] <mailto:
> > [e-mail]>>
> > > >>     > > > > > > Cc: Pengshuping (Peng Shuping) <
> > [e-mail] <mailto:[e-mail]>>;
> > > >>     > > > > > > [e-mail] <mailto:[e-mail]>
> > > >>     > > > > > > 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=[e-mail] <mailto:
> > [e-mail]>> 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 <[e-mail] <mailto:
> > [e-mail]>> On Behalf Of Pengshuping
> > > >>     > > > > > > > (Peng
> > > >>     > > > > > > > Shuping)
> > > >>     > > > > > > > Sent: Thursday, July 2, 2020 12:07 PM
> > > >>     > > > > > > > To: [e-mail] <mailto:[e-mail]>
> > > >>     > > > > > > > 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: [e-mail] <mailto:
> > [e-mail]> [mailto:[e-mail] <mailto:
> > [e-mail]>]
> > > >>     > > > > > > > Sent: Thursday, July 2, 2020 11:31 PM
> > > >>     > > > > > > > To: Lizhenbin <[e-mail] <mailto:
> > [e-mail]>>; Pengshuping (Peng Shuping)
> > > >>     > > > > > > > <[e-mail] <mailto: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
> > <
> > 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 <http://tools.ietf.org>.
> > > >>     > > > > > > >
> > > >>     > > > > > > > The IETF Secretariat
> > > >>     > > > > > > >
> > > >>     > > > > > > >
> > > >>     > > > > > > >
> > ----------------------------------------------------------------
> > > >>     > > > > > > > ---- IETF IPv6 working group mailing list
> > [e-mail] <mailto:[e-mail]>
> > > >>     > > > > > > > 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
> > [e-mail] <mailto:[e-mail]>
> > > >>     > > > > > > > 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 [e-mail]
> > <mailto:[e-mail]> Administrative
> > > >>     > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > >>     > > > > >
> > --------------------------------------------------------------------
> > > >>     > > > >
> > > >>     > > > > --
> > > >>     > > > > ---
> > > >>     > > > > [e-mail] <mailto:[e-mail]>
> > > >>     > > >
> > > >>     > > >
> > --------------------------------------------------------------------
> > > >>     > > > IETF IPv6 working group mailing list
> > > >>     > > > ipv6@ietf..org <mailto:[e-mail]>
> > > >>     > > > Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > > >>     > > >
> > --------------------------------------------------------------------
> > > >>     > >
> > > >>     > >
> > --------------------------------------------------------------------
> > > >>     > > IETF IPv6 working group mailing list
> > > >>     > > [e-mail] <mailto:[e-mail]>
> > > >>     > > 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
> > > >>
> > > >>     --
> > > >>     ---
> > > >>     [e-mail] <mailto:[e-mail]>
> > > >>
> > > >> --
> > > >>
> > > >> <http://www.verizon.com/>
> > > >>
> > > >> *Gyan Mishra*
> > > >>
> > > >> /Network Solutions A//rchitect /
> > > >>
> > > >> /M 301 502-1347
> > > >> 13101 Columbia Pike
> > > >> /Silver Spring, MD
> > > >>
> > > >>
> > > >> --------------------------------------------------------------------
> > > >> IETF IPv6 working group mailing list
> > > >> [e-mail]
> > > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > >> --------------------------------------------------------------------
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > [e-mail]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >
> >
> > --
> > ---
> > [e-mail]
> >
> 
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> *Network Solutions A**rchitect *
> 
> 
> 
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD

-- 
---
[e-mail]