Subject: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

From: Bob Hinden <[email-masked]>
Date: Wed, 2 Jun 2021 11:31:23 -0700

Hi,

We posted a new version of draft-hinden-6man-hbh-processing.    The changes include:

   *  Expanded terminology section to include Forwarding Plane and
      Control Plane.
   *  Changed draft that only one HBH Option MUST be processed and
      additional HBH Options MAY be processed based on local
      configuration.
   *  Clarified that all HBH options (with one exception) must be
      processed on the Fast Path.
   *  Kept the Router Alert options as the single exception for Slow
      Path processing.
   *  Rewrote and expanded section on New Hop-by-Hop Options.
   *  Removed requirement for HBH Option size and alignment.
   *  Removed sections evaluating currently defined HBH Options.
   *  Added content to the Security Considerations section.
   *  Added people to the acknowledgements section.
   *  Numerous editorial changes

We think this resolves most of the issues raised on the list and at the pervious IETF meeting.

Please review and comment on the list.

Bob & Gorry

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
> Date: June 2, 2021 at 11:27:07 AM PDT
> To: "Robert M. Hinden" <[email-masked]>, "Godred Fairhurst" <[email-masked]>, "Gorry Fairhurst" <[email-masked]>, "Robert Hinden" <[email-masked]>
> 
> 
> A new version of I-D, draft-hinden-6man-hbh-processing-01.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-6man-hbh-processing
> Revision:	01
> Title:		IPv6 Hop-by-Hop Options Processing Procedures
> Document date:	2021-06-02
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> Html:           https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01
> 
> 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 of IPv6 Hop-by-
>   Hop options practical with the goal of making IPv6 Hop-by-Hop options
>   useful to deploy and use in the Internet.  When published, this
>   document updates RFC8200.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 3 Jun 2021 08:25:36 +0000

Bob and Gorry,

Happy to read the new section 5.1 allowing for more than 1 HbH options :-)

Still need to review in depth the -01 though

-éric

From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Wednesday, 2 June 2021 at 20:32
To: IPv6 List <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>, Bob Hinden <[email-masked]>
Subject: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Hi,

Bob & Gorry

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Date: June 2, 2021 at 11:27:07 AM PDT
To: "Robert M. Hinden" <[email-masked]<mailto:[email-masked]>>, "Godred Fairhurst" <[email-masked]<mailto:[email-masked]>>, "Gorry Fairhurst" <[email-masked]<mailto:[email-masked]>>, "Robert Hinden" <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 3 Jun 2021 14:14:16 +0100

Hi Bob, Gorry,

Couple of things on this.

- draft-hinden-6man-hbh-processing is not the document to have 
terminology statements about control / forwarding plane / fast path / 
slow path / etc.  The topic is more subtle and nuanced than can be dealt 
with in a summary of a draft which addresses a different topic.  The 
ietf really needs a proper document to discuss the issue because the 
terms are used in quite a lot of discussions relating to packet 
forwarding, and several subtleties are germane to this draft.

- Is it correct to conclude that this doc changes the semantics of HBH 
from only being processed when "explicitly configured to do so" to "MUST 
process"?  The text in the draft is ambiguous in the sense that it could 
mean:

1. nodes MUST examine at least one HBH EH and MUST process the first 
Option in the fast path, or
2. if a node is configured to process HBH EHs, it MUST process the first 
Option in the fast path.

- signaling slow path HBH processing via the Router Alert option should 
be interpreted in the context that if a HBH packet reaches the slow 
path, this should be treated as something of a curiosity, i.e. the 
exception rather than the rule.

- consequently + for other reasons, it might be an idea to update the 
text in the security considerations from "Due to this it's common for 
transit routers" to "Due to this, it is routine for transit routers"

- given the many and increasing orders of magnitude of difference 
between fast path and slow path processing speed, I really question the 
wisdom of making any declarations at all about slow path processing. 
This is writing cheques on an empty account.  We need to deprecate this 
idea completely - it's been entirely non-viable for many years.

- nit: all instances of "it's" except for the last one in section 8 
should be changed to "its"

Nick

Bob Hinden wrote on 02/06/2021 19:31:
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-hinden-6man-hbh-processing-01.txt*
>> *Date: *June 2, 2021 at 11:27:07 AM PDT
>> *To: *"Robert M. Hinden" <[email-masked] 
>> <mailto:[email-masked]>>, "Godred Fairhurst" 
>> <[email-masked] <mailto:[email-masked]>>, "Gorry 
>> Fairhurst" <[email-masked] <mailto:[email-masked]>>, 
>> "Robert Hinden" <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-hinden-6man-hbh-processing
>> Revision:01
>> Title:IPv6 Hop-by-Hop Options Processing Procedures
>> Document date:2021-06-02
>> Group:Individual Submission
>> Pages:13
>> URL: 
>> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt
>> Html: 
>> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01
>>
>> Abstract:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Jun 2021 07:18:36 -0700

> idea completely - it's been entirely non-viable for many years.
Completely agree with that, the concept of "slow path" in the datapath
needs to go away! IMO, if a router can't process something in the fast
path then it shouldn't process it all-- preferably the router would
ignore things it can't process quickly, but if it can't, from a host
perspective I'd rather routers drop packets (packet loss would at
least be an explicit signal that a host is sending something routers
don't like). Even if the slow path is only taken intermittently, that
is still problematic as it creates variances in RTT that can wreak
havoc on transport congestion control algorithms that are measuring
delay. Not to mention that attacking the slow path is an obvious DoS
vector.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Jun 2021 08:17:41 -0700

Hello, a few comments on the draft:

>From the draft: "Unfortunately, this did not improve the processing of
Hop-by-Hop options and did not significantly improve deployment and
use in the Internet."

Is there data that supports this statement? Since RFC8200 was
published, have router implementations been changed to ignore HBH
options instead of dropping packets containing them? The primary
problem with supporting HBH Options in the Internet isn't that we need
all nodes in the path to process them, it's that we need all nodes in
the Internet to at least forward packets containing them and not
blindly drop the packets.

"This document updates [RFC8200] that a node MUST process the first
Option in the Hop-by-Hop Header in the Fast Path"

It think this should be "This document updates [RFC8200] that a node
MUST process the first Option in the Hop-by-Hop Header in the Fast
Path if a node is configured to process Hop-by-Hop Options"

"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 suspect that the share of traffic containing any EH is very small
:-). There's an obvious tradeoff here in limiting an extensibility
mechanism to elicit feasible implementation versus not restricting the
mechanism so much that it inhibits innovation. So we need to define
and recommend some number of options N that satisfies both these
objectives. Emerging programmable devices, such as those based on P4
or PANDA, are more capable and flexible than ASIC based
implementations, so N=1 might not be the best choice looking forward
since it is overly restrictive. Note also that section 5.3 of RFC8504
sets N=8 for end host processing of HBH and Dest Options (I suggest
RFC8504 should be referenced by the draft).

"A node configured not to process HBH options, MUST drop the packet if
the top two bits of the Option Type field of the first HBH option is
non-zero."

This is a change to RFC8200 that would make a lot of implementations
retroactively non-conformant. I don't think it's practical. I would
suggest updating to RFC8200 with these requirements instead.

- If an intermediate node processes an option it does not recognize
and the top two bits of the Option Type field of the option are
non-zero, then the node MUST stop option processing and SHOULD NOT
drop the packet and SHOULD NOT send an ICMP Parameter Problem.
- A final destination node MUST process all the Hop-by-Hop Options, or
drop the packet if the number of options exceeds the configured limit
per RFC8504. This includes processing per the top two bits of Option
Type when an option is unrecognized as specified in RFC8200.
- New Hop-by-Hop Options SHOULD be defined with 00 as the top two bits
of the Option Type (that is new option should be defined to be ignored
if they are unrecognized by a node).

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Jun 2021 08:47:45 +1200

Nick,
> 2. if a node is configured to process HBH EHs, it MUST process the first 

I've certainly been assuming #2. If it's #1, I think we'd simply be
recreating the inconsistency between the real world and the satndard
that RFC7045 & RFC8200 removed. IMNSHO there will always be routers
that ignore HbH options.

This suggests that a change to the draft is needed:

OLD:
This document updates [RFC8200] that a node MUST process the first Option 
in the Hop-by-Hop Header in the Fast Path and MAY process additional Hop-by-Hop Options if configured to do so.

NEW:
This document updates [RFC8200] such that if a node is configured to process Hop-by-Hop options, it MUST process the first Option in the Hop-by-Hop Header in the Fast Path and MAY also be configured to process additional Hop-by-Hop Options.

   Brian

>> We posted a new version of draft-hinden-6man-hbh-processing.   
 The 
>> changes include:
> .

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Jun 2021 17:00:36 +0800

Hi authors,

Could you please explain the relationship between this doc and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers, in which the processing policy for the packets with HBH EH is DROP or IGNORE? If the processing policy is really needed to be revised, can we update the WG draft https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering accordingly?

Best Regards,
Zhenqiang Li 

[email-masked]
 
From: Tom Herbert
Date: 2021-06-03 23:17
To: Bob Hinden
CC: Gorry Fairhurst; IPv6 List
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

 

 

 
 
Tom

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 7 Jun 2021 10:46:47 +0000

Hi Bob, Gorry,

Thank you for the updates!

First, I have some questions on the "Hdr Ext Len" described in RFC8200 as below.
What is the intention to have the sentence "not including the first 8 octets"?
Does "the first 8 octets" include the "Next Header" 1 octet, "Hdr Ext Len" 1 octet, "Option Type" 1 octet, and "Opt Data Len" 1 octet, in total 4 octets?

      Hdr Ext Len         8-bit unsigned integer.  Length of the
                          Hop-by-Hop Options header in 8-octet units,
                          not including the first 8 octets.

As described in RFC8200 as below, the length of the options is to make the complete Hop-by-Hop Options header an integer multiple of 8 octets long.
So considering the description above, if the first option is 4 octets long, does that mean the "Hdr Ext Len" is zero?
If the first option is 8 octets long, does that mean it has to have a 6-octet padding?

      Options             Variable-length field, of length such that the
                          complete Hop-by-Hop Options header is an
                          integer multiple of 8 octets long.  Contains
                          one or more TLV-encoded options, as described
                          in Section 4.2<https://datatracker.ietf.org/doc/html/rfc8200#section-4.2>.

In this new draft, I have some questions on the length of the new HBH options in this draft.

   *  Fixed size in 8-octet units.  Specifically any new Hop-by-Hop

      options should not be variable size that could extend beyond what

      can be executed in the Fast Path.

"Fixed size in 8-octet units": does that mean it has a fixed size that is 8 octets? Or an integer multiple of 8 octets long? Because in RFC8200, it is also written as "Length of the Hop-by-Hop Options header in 8-octet units".

Is what you meant to say that the first option should have a fixed size that is 8 octets?

You do have this specification in Section 5.1 of the new draft "This field specifies the length of the Option Header in 8-octet units." which means that it is not changed compared to RFC8200.

So if the first option has a fixed size in 8 octets, considering the above specification in RFC8200, does that mean it has to always have a 6-octet padding when there is only one option?

In Section 10, there is "Removed requirement for HBH Option size and alignment". Do you mean that in RFC8200 the length of options needs to make the HBH header an integer multiple of 8 octets long, but now you only define the length of the option itself as a fixed size value, 8 octets? But again you keep the "the length of the Option Header in 8-octet units"...

Nit:
page 5 - would have be processed -> would have been processed
page 7 - at least one node on the patch -> at least one node on the path
page 8 - it's function -> its function; it's usage -> its usage; it's use -> its usage; it's processing -> its processing
page 9 - it can be proceed -> it can be proceeded

Best regards,
Shuping

From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, June 3, 2021 2:31 AM
To: IPv6 List <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Hi,

Bob & Gorry

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 06:58:27 +0000

On Thu, 2021-06-03 at 14:14 +0100, Nick Hilliard wrote:
[....]
> idea completely - it's been entirely non-viable for many years.

+1

Thanks,
Fernando

-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 07:40:57 +0000

Hi, Bob & Gorry,

Some comments:

* Section 4, page 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.

The way I interpret RFC8200 is that a router is configured whether it
needs to process the HbH header in the first place, rather than whether
to process specific options. 

* Section 4, page 5:
> 
>    There has been research that discussed the general problem with
>    dropping packets containing IPv6 extension headers, including the
>    Hop-by-Hop Options header.  For example [Hendriks] states that
>    "dropping all packets with Extension Headers, is a bad practice"

Given the number of vulnerabilities associated with the processing of
IPv6 EHs, and that it's a feature that is largely unused, the converse
is probably true.

* Section 4, page 5:

This discussion misses an important point/aspect: the lgnth of the IPv6
header chain. e.g., asking nodes to support a single HbH option if such
option is, say, 256 bytes, will still be unfeasible.

* Section 5.1, page 6:
> [RFC8200] also requires
>    that a Hop-by-Hop Options header can only appear once in a packet.
> 

This doesn't seem accurate. RFC8200 states:

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

i.e., there's a recommendation to send only one HbH, but still required
to process all received. (cursed by the robustness principle, if you
wish :-) )

* Section 5.2, page 6:
> 
>    If the node can not process an option in the Fast Path, it MUST
>    behave as if it does not recognize the Option Type (as described
> in
>    the next paragraph).

My take is that a router that wouldn't be able to process options in
the fast-path wouldn't even bother to parse the contents of the HbH in
the first place....

* Section 5.3, page 8:

>       The Router Alert Option is a problem since it's function is to
> do
>       what this specification is proposing to eliminate, that is,
>       process the packet in the Slow Path.  One approach would be to
>       deprecate it as it's usage appears to be limited and packets
>       containing Hop-by-Hop options are frequently dropped. 

Nore: This option is employed for MLD packets, which result from ND
using multicast. In such scenarios (MLD is link-local) packets survive
- -- cause they don't need to be forwarded in the first place.  Whether
using RAO for MLD (or whether MLD itself) is a good idea, is a
different question... ;-)

* Section 5.3, page 8:

> 
>    A Fast Path implementation SHOULD verify that a Router Alert
> contains
>    a protocol, as indicated by the Value field in the Router Alert
>    option, that is configured as a protocol of interest to that
> router.
>    A verified packet SHOULD be sent on the Slow Path for processing
>    [RFC6398]. 

If the device knows it's not using a protocol that may need to rely on
RAOs, why should the device parse, say, RAOs in the first place?

* Section 6, page 9:
>    Any new IPv6 Hop-by-Hop option designed in the future should be
>    designed to be processed in the Fast Path.  New options MUST NOT
> be
>    defined that require Slow Path processing.  New Hop-by-Hop options
>    SHOULD have the following characteristics:
> 
>    *  Straight forward to process.  That is, they should be designed
> to
>       keep the time to process low.
> 

This is missing the overall option length. 

* Section 8, page 10:

>    Security issues with IPv6 Hop-by-Hop options are well known and
> have
>    been documented in several places, including [RFC6398], [RFC6192],
>    and [I-D.ietf-v6ops-ipv6-ehs-packet-drops].  The main issue, as
> noted
>    in Section 4, is that any mechanism that can be used to force
> packets
>    into the router's Slow Path can be exploited as a denial of
> service
>    attack on a transit router by saturating the resources need for
>    router management protocols (e.g., routing protocols, network
>    management protocols, etc.) that may cause the router to
> fail.  Due
>    to this it's common for transit routers to drop packets with Hop-
> by-
>    Hop options headers.

This discussion missess to note and acknowledge that there is a general
issue associated with IPv6 extension headers.

HbH has extra problems. But there are other general issues that apply
to all EHs, and not just HbH.

* Section 8, page 10:
> 
>    *  Limited the default number of Hop-by-Hop options that that can
> be
>       in a packet to a single Hop-by-Hop option.

If you are pursuing that path, you should also limite the overall IPv6
header chain length. That;s probably even more important than limiting
the number of EHs or number of HbH options.

Thanks!

Regards,
- -- 
Fernando Gont

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Jun 2021 09:04:58 +0100

Hi Fernando,

> to process specific options.
I see, I don't see RFC8200 as saying whether this has to be a global 
"switch"

to disable processing, or whether it allows configuration that can result

in disabling. This ID intends to update and clarify that aspect.

> IPv6 EHs, and that it's a feature that is largely unused, the converse
I thought you'd say so. However, this is a proposal to simplify the method

and to enable them to be used. I don't agree that this is generally 
unsupported

and I suggest yoy

> option is, say, 256 bytes, will still be unfeasible.
Are you saying the first option (HBH has to be first), is not within the

first 256 bytes? I don't understand.

> to process all received. (cursed by the robustness principle, if you
The proposed ID targets PS to change this.

> the fast-path wouldn't even bother to parse the contents of the HbH in
I think we can trip-up easily on slow path and fast path terms, as we have

seen on this list.

> -- cause they don't need to be forwarded in the first place. Whether
Sure, isn't a Router Alert also used hop-by-hop with MPLS, RSVP for QoS, 
and other methods?

> RAOs, why should the device parse, say, RAOs in the first place?
I'm OK with what you say.
> the number of EHs or number of HbH options.
Why does that impact the ability to process a HBH-O in a router?
> Regards,

Best wishes,

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 09:18:21 +0000

Hi, Gorry,

> in disabling. This ID intends to update and clarify that aspect.

Fair enough. From my pov, I might live with simply skupping the HbH,
but wouldn't have my boxes parse its contents. -- i.e., either ignore
the whole thing, or drop. :-)

> and to enable them to be used. I don't agree that this is generally 

FWIW, my point is that a claim such as "dropping all packets with EHs
is abad practice" is kind of flawed/bogus statement.  -- it kind of
implicitly assumed that it's the result of an arbitrary decision. ..
when in many cases it's actually the other wat around.

> first 256 bytes? I don't understand.

What I mean is: one of the problematic aspects is the overall IPv6
header chain length. No matter the restriction on the number of HbH
instances or number of HbH options, if the overall IPv6 header chain
length is too long, you;ll be in trouble.

THe definition of too long depends on the implementation, and can be
anything from 8 to, say, 512, in powers of 2.  -- see RFC7872 for hint
of the impact of the IPv6 header chain length on the drop rate.

> The proposed ID targets PS to change this.

What I mean is that the I-D argues that RFC8200 states that there can
only be one instance of HbH. However, it actually simply *recommends*
to have a single instance, but requires that any number of HbH
instances are accepted and processed (hence my reference to the
robustness principle)

> Sure, isn't a Router Alert also used hop-by-hop with MPLS, RSVP for

Yep. What I'm saying is that it is actually used. So.. how/why would
you deprecate it?

> Why does that impact the ability to process a HBH-O in a router?

It doesn't. It affects the ability of the router to obtain layer-4
information from the packet. And when that happens, as per draft-ietf-
v6ops-ipv6-ehs-packet-drops, packets get dropped. That leads to
unreliability of HbHs, which affects their possible usage.

Thanks!

Regards,

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Jun 2021 10:52:41 +0100

A few comments...

> the whole thing, or drop. :-)
Understood.
> when in many cases it's actually the other wat around.
That's a point the WG will need to agree upon:-) ... It also depends on 
how the WG sees (future) use of HBH options.
>> Are you saying the first option (HBH has to be first), is not within
>> the first 256 bytes? I don't understand.
>>
>>
So, the core thing from my side is that the ID is motivating that ONE 
HBH option can be useful.

The message was intended to be that more HBH options might also be 
useful, but deisgns need to be careful ... because, in the near future,  
routers might not process later HBH options in the same packet.

> Yep. What I'm saying is that it is actually used. So.. how/why would
I see, and I think I agree. - I'm aware there is as BCP (168), aka RFC 
6398, which makes recommendations in this space, and that might be a 
good basis for whatever is decided.
> unreliability of HbHs, which affects their possible usage.

I see. That might be something that impacts some types of usage for sure 
when the HBH option causes inspection of the transport header.

I also agree: This also impacts traversal (i.e. can lead to drop) in 
devices that generally check EHs.

We should note these.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Jun 2021 08:07:44 -0700

On Thu, Jun 10, 2021 at 12:41 AM Fernando Gont
<fernando.gont=[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi, Bob & Gorry,
>
> Some comments:
>
> * Section 4, page 4:
>
Fernando,

That limit and other pertinent ones are defined in RFC8504 section 5.3
and RFC8883. The limits in RFC8504 are specified for hosts, but it
would be straightforward to apply them to routers  where the behavior
when a limit is exceeded would be different-- end hosts should drop
packets that exceed the limit, intermediate nodes should stop parsing
and forward the packet. If a node decides to drop the packet then it
can send an RFC8883 ICMP error to inform the sender what the exceeded
limit was. Recommended defaults can be provided for limits; e.g. in
RFC8504 the limit of HBH or DestOpts is eight meaning that receivers
should support up to eight options and senders should be able to send
up to eight options with reasonable confidence their packets won't be
dropped. A similar default could be established for length of IP
header chain (for hosts this isn't immediately necessary since hosts,
unlike routers, usually don't have a concept of fixed sized parsing
buffer holding headers, although with hardware acceleration that limit
might be more applicable to set in the host).

Tom

> -----BEGIN PGP SIGNATURE-----
>
> iQFOBAEBCgA4FiEE371j47JIrnnFmK8j667aAwZEFTEFAmDBwgcaHGZlcm5hbmRv
> LmdvbnRAZWRnZXVuby5jb20ACgkQ667aAwZEFTH/qAf/Su1CoIjSBl6GeEIl0jn5
> JoW+H8uqAS49aP0pjFDsOXT2La5vGlT4DNDicextT5ca9xpI7BBBxxf8VDP1pdS6
> jgh/k2mp5qwGFG0UyJSIm46+hxW1+N6VbQ1RV19oKUFPk2iIcsPtimQuHIE/fa8I
> 1BD49ljp6WbZTR4DrqZFuKpbV8Zx5AxaOTGUuxzWEDzfOrylnmacPrT9IspbgU+R
> VIW6wMtHNK75LHs9ILSUjTGlv4056KrMkk9b/1Ot01wO7dgzFG6MXEQznVO1FUHX
> 8K9Y3+dB9yOg6cUenzDsCEqRgcnLPIXkbQhwySHQW9dAs0VkLwE8c+aKt9O5283W
> cQ==
> =u+vn
> -----END PGP SIGNATURE-----

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2021 10:20:25 +1200

> <fernando.gont=[email-masked]> wrote:
...
<big snip>
...
>> might be more applicable to set in the host).

Which all, IMHO, shows that the Internet cannot ever be assumed to be
transparent to extension headers of any kind; either we accept that
extensions are confined to limited domains or we need a probing process
before using them, to determine whether they can survive the trip.

Not much has changed (and it's exactly the same for IPv4 options): unusable
across the Internet.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Jun 2021 15:47:42 -0700

> Not much has changed (and it's exactly the same for IPv4 options): unusable

Brian,

By that same logic, IPv6 itself is unusable across the Internet since
not all Internet paths support IPv6 :-). For that matter, probably any
protocol, with the possible exception of plain TCP/IPv4 without
options, is "unusable" if the definition of usable is that there is a
100% probability that packets of a protocol will reach their
destination.

It seems like this is an exercise of making protocols ever more
usable-- either by fallbacks (e.g. Happy Eyeballs) as you mentioned,
but also by clarifications to the protocol requirements to elicit
practical implementation. For instance, RFC8200 allowing nodes to
completely ignore HBH options instead of requiring every single node
in the path to process was a big step in the right direction.
Specifying a reasonable default limit for the number of options that
should be processed or length of the IPv6 header chain that is
supported would be another step. Note these things won't get us to
100% support, but they could increase reachability and hence increase
utility of the protocols.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2021 11:01:15 +1200

Tom,
On 11-Jun-21 10:47, Tom Herbert wrote:
> not all Internet paths support IPv6 :-). 

Yes, I overstated my case a bit, but I do find that it is necessary
to be realistic in our designs, so I agree with what you say below.

   Brian
 
> For that matter, probably any

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 23:02:42 +0000

> Not much has changed (and it's exactly the same for IPv4 options):

Thanks for your summarizing this quiete well. :-) FWIW, I fully agree
with your analysis.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 23:06:56 +0000

On Thu, 2021-06-10 at 15:47 -0700, Tom Herbert wrote:
[....]
> utility of the protocols.

If the feature cannot be relied upon, a fallback mechnism needs to be
implemented. Now, as a protocol designer, why would I even bother
implementing functionality with an unreliable mechanism, particularly
when I could simply rely on something else?

OTOH, if I know that you have a fallback mechanism to take care of
situations where packets with EHs are dropped, why should I allow you
EH packets in my network in the first place?

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Jun 2021 16:15:57 -0700

> EH packets in my network in the first place?
Because fallbacks offer degraded service not equivalent service. For
instance your question could be restated as: given that IPv4 is the
fallback for IPv6, why should you allow IPv6 packets in your network
in the first place?

Tom

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 01:47:32 +0000

Hi,

> fallback for IPv6, why should you allow IPv6 packets in your network

If IPv6 had brokenness associated with it's deseign that couldn't be
worked around, then yes, people wouldn't bother trying IPv6 before
IPv4.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2021 05:00:51 +0000

This might need a solution be similar to the MTU problem; e.g., during PMTUD a node might add the HbH Options that it needs to check that the options make it through…

Regards,

Pascal

> Le 11 juin 2021 à 01:03, Fernando Gont <fernando.gont=[email-masked]> a écrit :
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 05:21:03 +0000

Hi, Pascal,

On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> This might need a solution be similar to the MTU problem; e.g.,
> during PMTUD a node might add the HbH Options that it needs to check
> that the options make it through…

Aside from a bunch of other evil details:

WHat if, say, you employ this solution at, say, connection-
establishment time, find that EHs actually "work" towards your
destination, but them, sometime later, the path to your
destinationchanges, and you find out that EHs no longer work?

     Abort the transaction/connections? 
     "Migrate" from EH-based mechansim to the fall back mechanism?
     Anything else?

What about the impact on e.g. RTT for connection-establishment? What
about the complexity of the mechanism? How many bugs/vulns before every
implementation gets it right?

Truth #3 of https://datatracker.ietf.org/doc/html/rfc1925 comes to
mind...

Thanks!

Regards,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Jun 2021 22:48:38 -0700

> destinationchanges, and you find out that EHs no longer work?

That scenario isn't all that much different than rerouting causing a
flow to not hit the same stateful middlebox, or a NAT state times out,
or any other instances of something in the network rendering a
connection too no longer viable. In all these cases, the application
just restarts the failed connection.

> implementation gets it right?
All the more reason we need to establish some guidelines as to what
the host can send in terms of extension headers and correspondingly
what intermediate nodes should support. Since RFC8200 allows
intermediate nodes to skip over HBH options, then the pertinent limit
would seem to be how long the IPv6 header chain is (solely for the
benefit of those routers that require parsing of the transport
header). I believe at least 128 byte parsing buffers are well
supported by vendors, and assuming 16 bytes for L2, and first 8 bytes
of transport header might need to be accessed by intermediate nodes,
then that implies a minimum default of 104 bytes and subtracting forty
bytes for IPv6 header gives nice round number of sixty four bytes for
extension headers. Hence, I suggest the requirements should be:
routers MUST forward IPv6 packets with sixty-four bytes or less of
extension headers, and correspondingly hosts MUST NOT send packets
with more than sixty-four bytes of extension headers unless they have
knowledge that the path supports a greater number.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 06:14:32 +0000

Hello, Tom,

> just restarts the failed connection.

There are multiple differences here:

* Packet drops can happen all over the place, whreas e.g. transit ASes
won't usually do the kind of stateful operations you're referring to.

* Issues arising from EHs can be avoided, while the other ones cannot.

> what intermediate nodes should support.

The problem is not establishing guidelines, but rather establishing
guidelines that folks find that there's a compelling reason to follow.

>  Since RFC8200 allows

Note: the "64 bytes" should accommodate the upper layer header. -- at
the very least, that part with the port numbers.

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2021 06:59:11 +0000

Hello Fernando

How that that so different from the PMTUD problem? When the route changes, the end-to-end MTU may change too.

Similarities:

- there are places were you won't even try to guess; 6LoWPAN decided to use an MTU of 1280 and will not try PMTUD; for HbH, as Brian suggests, it might be that the Internet at large is the wrong place to try it.

- there are flows and use cases that can really benefit from it, so keeping the lowest common denominator in all circumstances seems utterly wasteful.

- the concept of domain that Brian mentioned is intuitively the thing we're after. But the domain scope is not always very clear. So exploration can help.

Note that adding a HbH OH in an existing PMTUD / MSS exploration does not require a change in the intermediate routers and middle boxes. We do not need an RFC for that, anyone can try it already. 

draft-ietf-6man-mtu-option seems to serve the purpose as a side effect, though clarifying that other options can be placed in the HbH OH to experiment whether those options are also supported along the path seems like a good idea, e.g., for options with the leftmost bit set to 1 (act = 0b1O or act = 0b11).    

Keep safe;

Pascal

> -----Original Message-----
> From: Fernando Gont <fernando.gont=[email-masked]>
> Sent: vendredi 11 juin 2021 7:21
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > This might need a solution be similar to the MTU problem; e.g., during
> > PMTUD a node might add the HbH Options that it needs to check that the
> > options make it through…
> 
> WHat if, say, you employ this solution at, say, connection- establishment
> time, find that EHs actually "work" towards your destination, but them,
> sometime later, the path to your destinationchanges, and you find out that
> EHs no longer work?
> 
> What about the impact on e.g. RTT for connection-establishment? What about
> the complexity of the mechanism? How many bugs/vulns before every
> Truth #3 of https://datatracker.ietf.org/doc/html/rfc1925 comes to mind...
> 
> Thanks!
> 
> Regards,
> --
> Fernando Gont

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 11 Jun 2021 11:13:17 +0000

Hi all,
I was silent reading this discussion because it is pretty much a useless exercise.
95% of Telco traffic is the Best Effort (nobody pays a penny for additional services).
Additional headers processing has the cost:
- develop a new feature
- test a new feature
- implement a new feature
- support a new feature
And accept the responsibility for additional different risks (security, performance, interoperability).

Never-ever EH would work on the Internet till the Telco business model would change. Dump pipe does not need it.
It is true for half of the latest development in the IETF (especially for anything QoS-related).

Hence, fancy IPv6 functionality should be convenient only for closed domains.
It is primarily Enterprises where business case calculation for everything activated is not so strict.
Enterprises have much more traffic that is considered important for many reasons.

IMHO:
HbH in its current specification is perfectly fine for a closed domain.
If you would change it in any way that was discussed here - it would be still fine for a closed domain.
Of course, I could be wrong here because IPv6 popularity in the Enterprise is still close to 0%.
Hence, we do not know what Enterprise would need when they move to IPv6.
Unfortunately, such discussion is not popular here. It is primarily here about how to fix what is not possible to fix.

PS: it makes sense to drop testing "best effort pipe" for fancy services for not to disappoint ourselves.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, June 11, 2021 9:59 AM
To: Fernando Gont <fernando.gont=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Hello Fernando

Similarities:

Keep safe;

Pascal

> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: New Version Notification for 
> draft-hinden-6man-hbh-processing- 01.txt
> 
> Hi, Pascal,
> 
> about the complexity of the mechanism? How many bugs/vulns before 
> every implementation gets it right?
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 11 Jun 2021 07:50:23 -0700

> Unfortunately, such discussion is not popular here. It is primarily here about how to fix what is not possible to fix.
Eduard,

The only thing we can possibly fix in this forum are the protocol
specifications for IPv6. To that end, there's only one specification
for IPv6 which applies to all use cases of the protocol in that the
protocol does not distinguish between teco network, home networks,
enterprise networks, the Internet as a whole, or closed networks
(bifurcating the standard specifications between limited domains and
the open Internet has thus far been rejected). Given this context of
the WG, it is reasonable to try to update the protocols to address the
apparent gap wrt to extension headers between the protocol standards
and what is widely deployed. This is precisely what this draft and
this discussion is attempting to do.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Jun 2021 17:16:18 +0100

Tom Herbert wrote on 11/06/2021 15:50:
> the open Internet has thus far been rejected)

the standard has already bifurcated - srv6 is not compliant with vanilla 
rfc8200.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Fri, 11 Jun 2021 09:59:12 -0700

Nick,

So RFC8200 was deemed insufficient for limited domains so SRv6 made
new requirements specific to its limited domains, but for extensions
headers it's the opposite problem in that RFC8200 is sufficient for
limited domains but we need a different specification for how they
work over the open Internet. Am I the only one who's confused? :-)

Tom

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 11 Jun 2021 18:28:29 +0000

Hi Tom,
I was probably not clear.
I do not propose to develop something special for "closed domains". The spec should be unified.
I am just doubtful that it makes sense to look at what is going on the public Internet. It does not matter.
It makes sense to look for advanced functionality to closed domains only.
One Carrier could be a valid use case too.
PS: I do not see any trouble now for 1 carrier to activate anything from EHs (including HbH). After Carrier would pay the price.
Eduard
-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Friday, June 11, 2021 5:50 PM
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Eduard,

The only thing we can possibly fix in this forum are the protocol specifications for IPv6. To that end, there's only one specification for IPv6 which applies to all use cases of the protocol in that the protocol does not distinguish between teco network, home networks, enterprise networks, the Internet as a whole, or closed networks (bifurcating the standard specifications between limited domains and the open Internet has thus far been rejected). Given this context of the WG, it is reasonable to try to update the protocols to address the apparent gap wrt to extension headers between the protocol standards and what is widely deployed. This is precisely what this draft and this discussion is attempting to do.

Tom

> > > during PMTUD a node might add the HbH Options that it needs to 
> > > check that the options make it through…
> >

---

From: Tom Herbert <[email-masked]>
Date: Fri, 11 Jun 2021 11:55:03 -0700

> PS: I do not see any trouble now for 1 carrier to activate anything from EHs (including HbH). After Carrier would pay the price.

Eduard.

It really depends on what you mean by "activate anything from EHs".
There are at least two possible interpretations: 1) Process the EHs
like HBH 2) Forward packets containing EHs without doing anything with
them. For the viability of EHs, including future use cases, we mostly
care about interpretation #2. This really just means we want nodes to
ignore packets with extension headers instead of dropping them.
According to the data in RFC7872 that mostly is already happening
(e.g. 90% of packets with Destination Options we're being successfully
delivered at least five years ago). RFC8200 has already relaxed the
requirement that all nodes in the path need to process HBH, so so
aside from an explicit policy, the biggest impediment is in
implementation for those intermediate nodes that need to access the
transport layer and if the necessary headers don't fit in the parsing
buffer they may drop the packet. The solution to that, I believe, is
to set a requirement specifying the maximum length IP header chain
(e.g. 104 bytes including IPv6 header) that nodes must support if they
are accessing the transport layer.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 19:30:49 +0000

Tom,

On Fri, 2021-06-11 at 11:55 -0700, Tom Herbert wrote:
> delivered at least five years ago). 

RFC7872 doesn't convey everything that we measured: the number get
uglier as you increase the size of EHs (DO8 vs DO16 vs DO32 vs DO64,
etc.).

> RFC8200 has already relaxed the
> (e.g. 104 bytes including IPv6 header) that nodes must support if
> they are accessing the transport layer.

This is indeed as much as we (6man( can probably do.

For the amusement of participants, almost ten years ago I proposed to
limit the IPv6 header chain to 1280 bytes, and the idea didn't fly (
https://datatracker.ietf.org/doc/html/draft-gont-6man-oversized-header-chain-00
). :-)

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 11 Jun 2021 19:34:52 +0000

Tom, "anything" means anything.
1) or 2) from your list and all other choices too.
What is the problem to test everything properly and activate it now for one domain where the business case exists?
Such admin would probably filter everything out at borders. Exactly as it is recommended by SRH spec (and many others).
Ed/
-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Friday, June 11, 2021 9:55 PM
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Eduard.

It really depends on what you mean by "activate anything from EHs".
There are at least two possible interpretations: 1) Process the EHs like HBH 2) Forward packets containing EHs without doing anything with them. For the viability of EHs, including future use cases, we mostly care about interpretation #2. This really just means we want nodes to ignore packets with extension headers instead of dropping them.
According to the data in RFC7872 that mostly is already happening (e.g. 90% of packets with Destination Options we're being successfully delivered at least five years ago). RFC8200 has already relaxed the requirement that all nodes in the path need to process HBH, so so aside from an explicit policy, the biggest impediment is in implementation for those intermediate nodes that need to access the transport layer and if the necessary headers don't fit in the parsing buffer they may drop the packet. The solution to that, I believe, is to set a requirement specifying the maximum length IP header chain (e.g. 104 bytes including IPv6 header) that nodes must support if they are accessing the transport layer.

Tom

> draft-hinden-6man-hbh-processing-01.txt
>
> > From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal 
> > Thubert
> > (pthubert)
> > > What about the impact on e.g. RTT for connection-establishment? 
> > > What about the complexity of the mechanism? How many bugs/vulns 
> > > before every implementation gets it right?
> > >
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6