Re: [v6ops] Call for adoption: draft-peng-v6ops-hbh

[Gyan Mishra <[e-mail]>]

Hi Bob

Many thanks for your comments and feedback on this draft.

Responses in-line

Kind Regards

Gyan
On Fri, Sep 10, 2021 at 7:01 PM Bob Hinden <[e-mail]> wrote:

> Hi,
>
> If there is enough interest in v6ops, I generally support the V6OPS w.g.
> taking this on as a w.g. document.   I am a co-author of a few relevant
> documents in 6MAN, these are:
>
> draft-ietf-6man-mtu-option
> draft-hinden-6man-hbh-processing
>
> The second represents a proposed solution to the issues with IPv6
> Hop-by-Hop options.  At the high level, I think there is general agreement
> that the goals of draft-peng-v6ops-hbh and draft-hinden-6man-hbh-processing
> are aligned.   If adopted they could reference each other.   Another
> relevant document presented in 6MAN is draft-herbert-6man-eh-limits.   I
> think this is also aligned.
>

    Gyan> Agreed

>
> While the problems with IPv6 Hop-by-Hop options are generally well known
> and described in IETF documents, for example
> <draft-ietf-v6ops-ipv6-ehs-packet-drops>, RFC9099 and RFC7872, I don’t see
> any harm in doing another, if it helps us to improve the situation with
> IPv6 Hop-by-Hop headers.  If we want to fix this, we need to work together.
>

    Gyan> Yes, we can work together on improving the situation with HBH.

>
> I do see a number of serious issues with draft-peng-v6ops-hbh-06, even
> though it is much better than the earlier versions that should be fixed if
> adopted.  These include:
>
> 1) The current title is "Processing of the Hop-by-Hop Options Header”.
>  This makes it sound a lot like how routers should process IPv6 HBH headers
> and options, not like a description of the operational issues.   I think
> will cause confusion with draft-hinden-6man-hbh-processing that is titled
> "IPv6 Hop-by-Hop Options Processing Procedures”.   I think
> draft-peng-v6ops-hbh should change it’s title avoid this confusion.
> Something like “Operational Issues with Processing Hop-bb-Hop Options
> Headers” (or something similar) would be better.
>

   Gyan> Thank you for the suggestion and we will update,

>
> 2) Section 2. "Modern Router Architecture”
>
> This appears to be a good description of some “modern” router
> architectures, but I suspect there are other architectures that are
> different.   For example, there are still a lot (perhaps the majority of
> routers) of software based routers without hardware assist and
> differentiated control and forwarding planes.  This section needs work if
> it intends to describe all router architecture handling of Hop-by-Hop
> option headers.


    Gyan> As we wanted to cover all hardware architectures we will add
software based platforms. Thanks for mentioning.

>
>
> 3) Section 3.  Specification of RFC 8200
>
> This section summarizes text from RFC8200.   In general it is better to
> quote other RFCs instead of trying to summarize them.   Summarizing tends
> to loose subtle differences.
>

     Gyan>  Understand.  We will clean up the verbiage.

>
> 4) Section 7 Requirements
>
> This section needs a lot of work, or should be removed.   For example,
> looking at the the first requirement:
>
>    *  The HBH options header MUST NOT become a possible DDoS Vector.


> This has several serious issues.   The first is that any protocol
> mechanism can be used a a DDOS attack vector under the right
> circumstances.   With a MUST NOT this requirement is impossible to meet.
>  The use of upper case RFC8174 key words turns this into a protocol
> specification, I don’t think that would be in scope for V6OPS.


Gyan> Good point.  We will reword and remove mention of DDOS vector.


>
> The next requirement:
>
>    *  HBH options SHOULD be designed so that they don't reduce the
>       probability of packet delivery.  For example, an intermediate node
>       may discard a packet because it contains more HBH options than the
>       node can process.
>
> How can you design an HBH option that knows how many options an
> intermediate node (we usually call these routers) can process?   Again,
> it’s a requirement that can’t be met.


    Gyan> Good point as well.

>
>
> I have similar comments on the other requirements, but won’t list them
> here.  As I said, this section either needs a lot of work, or should be
> removed.


    Gyan>  We will work on revamping this section.  Do you have any
requirements that you would like to add to an HBH solution?

>
>
> 5) Section 8.  Migration Strategies
>
> This section also has serious issues.   These include:
>
> It talks about characterizing options into either control options or
> forward options.   We only have HBH Options, not two types.
>
> It says nodes are updated to the proposed behavior introduced in the
> pervious section, but the previous section says requirements.
>
> It says edge nodes (we usually call these hosts in IPv6) should check
> whether the packet contains an HBH header with control or forwarding
> options.   This isn’t a good description of how hosts actually work, nor
> are there control or forward options.
>
> This section may be a remanent of an earlier version of this draft that
> was proposing different types of HBH options, but can’t really tell.
>  Might be best to remove this section.


    Gyan> We have discussed cleaning up this section or removing and now
based on feedback we are leaning towards removing.

>
>
> Bob
>
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*