Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[Gyan Mishra <[e-mail]>]

Hi Bob & Ron

I can see the benefits of this draft as two fold.

1.  Eliminating hbh ddos vector on the internet that forces operators to
drop hbh.

2. Allows new applications that use hbh functionality - that requires hbh
to be processed in the fast path.  There are networking technologies such
in IPPM WG OAM, BIERv6 etc as well as other applications that can greatly
benefit form hbh processing in the fast path.


The concern I have with existing hbh headers that exist well known or
otherwise that would be broken that use more then one option.

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml


I can see the byte alignment to 8 bits being valuable for processing and
eliminating of all the pad options.

The verbiage below seems pretty tightly focused on trying to minimize
processing to single hbh option to ensure all router platforms can process
in the fast path.  I don’t think that is practical and used a sledge hammer
to solve a problem that could be solved with a tooth pick.

Maybe a one size fits all model could be detrimental as most internet
backbone routers are higher end, and may not require the stringent 1 option
requirement as that is the problem to be solved by with hbh being dropped
on internet backbone routers.

For the backwards compatibility with existing well known and other hbh with
more then one option could result in the same “dropping” of hbh that occurs
today with operators filtering hbh explicitly to avoid ddos vector.  This
is due to the stringent single hbh option requirement.

   Nodes creating packets with a Hop-by-Hop option headers MUST only
   include a single option in the packet.  This also requires that all
   Hop-by-Hop Options MUST be 8-octet aligned.  See Section 6
<https://tools.ietf.org/html/draft-hinden-6man-hbh-processing-00#section-6>
for more
   detail.

   Nodes processing a packet with a Hop-by-Hop options header MUST
   discard the packet if there is more than one Hop-by-Hop option in
   that header.


We have an application use case for hbh in the BIER WG for BIERv6 draft
below:

https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08


In this draft today we encode the BIER header in the DOH options and set
the option flag for en route hop by hop processing.

So with that instead of the DOH being processed last it would be processed
after the hbh.

Per RFC 8200 we would set the 3rd highest order bit in the option type so
the options data would change en route.


   Two of the currently defined extension headers specified in this
   document -- the Hop-by-Hop Options header and the Destination Options
   header -- carry a variable number of "options" that are type-length-
   value (TLV) encoded in the following format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type         8-bit identifier of the type of option.

      Opt Data Len        8-bit unsigned integer.  Length of the Option
                          Data field of this option, in octets.

      Option Data         Variable-length field.  Option-Type-specific
                          data.


   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en route to the
   packet's final destination.  When an Authentication header is present


   in the packet, for any option whose data may change en route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

       0 - Option Data does not change en route

       1 - Option Data may change en route



So with the 3 highest order bits being reserved above their are only 5 bits
remaining or 32 options remaining user configurable for custom options.
There is not a ton of options to begin with but I think 1 is quite small.

I think the DOH Header had similar identical properties of the hbh header
when the 3rd higher octet is set for in route hop by hop processing
specifying the data will change en route.

Could this specification be extended to DOH as you can see the similarities
for applicability in hop by hop en route processing flag use case that can
be processed in the fast path.

When you do the actual accounting or counting of the number of options
being used for BIERv6 draft, if we decided to change to use hbh would we be
using only 1 option I believe being the 3rd higher order bit flag for en
route hop by hop processing.  Would BIERv6 be in conformance with the
single option setting requirement.  We would ensure that when we encode the
BIER header we have it 8 bit aligned boundary so we don’t require any
padding bits.

Kind Regards

Gyan


On Thu, Dec 3, 2020 at 6:16 PM Bob Hinden <[e-mail]> wrote:

> Hi,
>
> Gorry and I put together a draft that proposes to change how IPv6
> Hop-by-Hop Options are processed.  Links to the draft below.
>
> Abstract:
>
>   This document specifies procedures for how IPv6 Hop-by-Hop options
>   are processed.  It modifies the procedures specified in the IPv6
>   Protocol Specification (RFC8200) to make processing in routers more
>   practical with the goal of making IPv6 Hop-by-Hop options useful to
>   deploy in the Internet.  When published, this document updates
>   RFC8200.
>
> A very short summary is that there can only be one Hop-by-Hop option in a
> Hop-by-Hop Option header, and that Hop-by-Hop Options must be process in
> the fast path.
>
> Please read and comment on the draft (that is, not on just this email).
>  We think this might make Hop-by-Hop options practical to use in the
> Internet.
>
> Bob & Gorry
>
>
> > Begin forwarded message:
> >
> > From: [e-mail]
> > Subject: New Version Notification for
> draft-hinden-6man-hbh-processing-00.txt
> > Date: December 3, 2020 at 3:04:46 PM PST
> > To: "Robert M. Hinden" <[e-mail]>, "Godred Fairhurst" <
> [e-mail]>, "Robert Hinden" <[e-mail]>, "Gorry
> Fairhurst" <[e-mail]>
> >
> >
> > A new version of I-D, draft-hinden-6man-hbh-processing-00.txt
> > has been successfully submitted by Robert M. Hinden and posted to the
> > IETF repository.
> >
> > Name:         draft-hinden-6man-hbh-processing
> > Revision:     00
> > Title:                IPv6 Hop-by-Hop Options Processing Procedures
> > Document date:        2020-12-03
> > Group:                Individual Submission
> > Pages:                11
> > URL:
> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> > Html:
> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.html
> > Htmlized:
> https://tools.ietf.org/html/draft-hinden-6man-hbh-processing-00
> >
> >
> > Abstract:
> >   This document specifies procedures for how IPv6 Hop-by-Hop options
> >   are processed.  It modifies the procedures specified in the IPv6
> >   Protocol Specification (RFC8200) to make processing in routers more
> >   practical with the goal of making IPv6 Hop-by-Hop options useful to
> >   deploy in the Internet.  When published, this document updates
> >   RFC8200.
> >
> >
> >
> >
> > 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
> [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