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

[Fernando Gont <[e-mail]>]

Hello, Bob & Gorry,

I've just read your I-D. -- I see there has been some discussion on the 
mailing-list regarding this document, and I've not yet been able to 
catch up with the discussion. So my apologies if some (or even all!) of 
my comments have been mentioned/raised by others.

Here's my feedback:

1) Section 4:
>  The changes meant that an implementation complied with the IPv6
>  specification even if it did not process hop-by-hop options, and that
>  it was expected that routers would add configuration information to
>  control which hop-by-hop options they would process.
 >
>  Unfortunately, this did not improve the processing of Hop-by-Hop
>  options and they are often not possible to be deployed and used in
>  the Internet.  It merely documented how they were being used in the
>  Internet.


While I'm not I'd say the changes incorporated into RFC8200 *will* make 
a difference, I'm not sure we can say they haven't or won't, either. 
RFC8200 was published mid 2017. I've seen rather trivial (software) 
changes to take a year to test and implement. It would probably take 
longer when the change involves hardware. And then the devices needs to 
be bought and deployed. So in that sense I think it's premature to tell 
whether the corresponding change in RFC8200 has made or will make any 
difference.


2)
>   In hindsight, hop-by-hop options were still not practical to be used
>   widely in the Internet.  Many operational routers are configured to
>   drop all packets containing a hop-by-hop option header. 

At the risk of "soudign our own horn", I think a referecen to RFC7872 is 
missing here.


3)
>    *  Allowing multiple hop-by-hop options in a single packet makes it
>       even more expensive in router resources to process these packets
>       in the fast path.  It adds complexity to the number of
>       permutations that might need to be processed.

As noted in draft-ietf-v6ops-ipv6-ehs-packet-drops, there are other 
implications of EHs, that do not necessarily have to do with the number 
of options. One of them is the option size. Because many (most?) 
implementations have limits when it comes to how deep into a packet they 
can peek. So, allowing a single option in a packet, without contraining 
its size (or at least recommending against long options) has the 
potential of resulting in packets where the IPv6 header chain spans past 
the fast memory that the device employs to do fast processing of the 
packets.  This is a key point, and is discussed at length in 
draft-ietf-v6ops-ipv6-ehs-packet-drops .


4)
> For example [Hendriks]
> states that "dropping all packets with Extension Headers, is a bad
> practice", and that "The share of traffic containing more than one EH
> however, is very small.  For the design of hardware able to handle
> the dynamic nature of EHs, we therefore recommend to support at least
> one EH"

I recently read this paper, after Gorry had pointed to it. When it comes 
to the part you quote, I have two obervations:

   * Dropping all packets with EHs might not be nice. But having your box
     owned or DoS'ed is certainly worse. So, at the end of the day, you
     choose the lesser evil. In that light, the claim that "dropping all
     packets with EHs is bad practice" is unfounded and lacks context.
     One might actually argue the opposite: if *not* dropping packets
     with EHs will open your box to DoS, then, then *not* dropping
     such packets is really bad practice.

   * If anything, what the paper shows is that EHs are scarcely used.
     The measurements in the aforementioned paper show that a neglegible
     amount of traffic employs EHs. And that traffic boils down to:
     fragmented UDP traffic, IPsec, local traffic (mostly MLD), or bogus
     traffic (fragmented TCP, ICMP errors that get fragmented or employ
     HBH options, etc..  Other than IPsec, there's not much of a use case
     for EHs nowadays... so I'm not sure one could venture into "how many
     EHs nodes typically employ", because there's nor really much to be
     measured in the first place.

5)
>    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.

Limiting things, in general, can make the allowed subset feasible -- 
rather than target at way too much flexibility that it's very expensive 
to implement, if at all possible.

That said, my question is: why is the number of options seen as a more 
important item than, say, the overall length of the HbH, or the overall 
length of the IPv6 header chain as a whole?

Is the number of options within a HbH really a thing for hardware platforms?


6)
> If the IPv6 node can not
>    process the Hop-by-Hop Option header in the fast path is MUST skip
>    over this option and continue processing the header normally.

Typo: s/is/it/


7) Section 5.2:

Isn't this the current behavior, anyway?

e.g., generation of error messages is already rate-limited, and there 
are multiple reasons for generating them (including traceroute). Is this 
specific trigger any special?

OTOH, RFC8200 states that HbH should only be processed if the router has 
a reason to -- which seems like good advice to me.

So I'm not sure what is being changed. It seems that the only thing that 
is changed is that even if there's explicit configuration to process 
HbH, the router wouldn't even process it if that can't be done in the 
fast path. -- but, at the end of the day, if the operator has explicitly 
configured the router to process HbH, it's probably because they have no 
option.


8) Section 6.  Hop-by-Hop Option Header Alignment

Some options might have a size that wouldn't make the *end* of the HbH 
fall into a 8-byte boundary, and hence would *require* padding. Router 
Alert seems to be one of those, and is indeed the most common option 
employed with HbH.  The requirement to drop packets that contain more 
than one option in the HbH would thus cause the packets for the only 
current user of HbH to be droopped.

For example, the pcap for MLD at: 
https://www.cloudshark.org/captures/696d02f3316e  (the first one I found 
when googling for one) has a total of three (not even just two1) 
options: one router alert, and two pad1 options for padding (you might 
argue that they could have used a single PadN... but still, a PadN 
option would have been needed).

In that light, I'm not sure you'd be able to implement this document 
(the constrain on the number of options per HbH) in a way that is 
backwards-compatible.


9) Section 6.2:

You catched my previous comment. Apologies -- I was writing comments 
while reading.
That said, in the light of my previous comment, I wonder if, if you 
really wanted to pursue this idea, whether it would be better to define 
a *new* EH.

OTOH, modulo all the comments I made above, you could probably achive 
the same by simply requiring the router to process the first option, and 
ignore the rest. IN that way, it would seem to me that you'd achieve 
what it seems you want to achieve, in a way that it would still work (*) 
  with current users of HbH.

   (*) there could still be cases where implementations include the Pad 
options *first*, and then the router alert. WHile possibly awkward, such 
approach is still valid as per current standards.


Hope the above are of help.

Thanks!

Regards,
Fernando




On 3/12/20 20:15, Bob Hinden 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
> --------------------------------------------------------------------
> 


-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1