Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

From: tom petch <[email-masked]>
Date: Mon, 14 Sep 2020 10:46:09 +0000

The problem that I have with this I-D is that I do not think that it will achieve its objectives.  It wants to raise awareness about the problems caused by Extension Headers so the target audience should be the world at large, especially those involved in setting up and operating IPv6 networks, but the style is, to me, rather academic, as if the audience was the sort of people who would be expected to be familiar with the literature and need little or no explanation.  I see this strongly in s.1, about Extension Headers, yet devoid of any reference, any explanation.  The first reference is RFC2460, which is Normative, so are readers expected to be familiar with the details therein?  One reaction might be 'So Extension Headers create problems so don't ever use them!'

The I-D lacks any explicit explanation of what an Extension Header is, what they were intended for, which bits have worked and which have failed so eg deprecating RHT0 is not very meaningful without some comment about RH something else.  Size matters as can be inferred from s.4 but there is no mention of the sizes involved of the IPv6 packet, with or without headers.  As I say, it seems that the reader is expected to know the literature.  There needs to be a page or two at the start giving the context within which the detail makes sense.

And then there is the future; should more Extension Headers be allocated, should they be constrained to avoid the difficulties raised here?  The I-D, for me, lacks an ending, lacks a look forward.

Tom Petch

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 14 Sep 2020 11:55:48 +0000

Hi all,
> And then there is the future; should more Extension Headers be allocated, should they be constrained to avoid the difficulties raised here?  The I-D, for me, lacks an ending, lacks a look forward.
I was discussing off-line with Fernando for long time about last Tom's comment. No success yet - no agreement to make any predictions or recommendations, Just "raise awareness".
I personally strongly suspect that a flood of new EH functionality that is in development now would greatly increase drop rate, because not all nodes would support everything needed at proper time.
Business is very restricted to something 7-10 years (depends on network layer) to refresh equipment, even if there is an EOS pressure.
Current EH innovation is much faster.
And additionally it overlays on slowdown of traffic growth (it was +50% just 2 years ago, 30% last year, 25% is probable this year) - would be more and more difficult to justify rip-and-replace.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of tom petch
Sent: 14 сентября 2020 г. 13:46
To: Fernando Gont <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

Tom Petch
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Sep 2020 14:39:47 -0300

On 14/9/20 07:46, tom petch wrote:
> The problem that I have with this I-D is that I do not think that it
> will achieve its objectives.  It wants to raise awareness about the
> problems caused by Extension Headers so the target audience should be
> the world at large, especially those involved in setting up and
> operating IPv6 networks, but the style is, to me, rather academic, as
> if the audience was the sort of people who would be expected to be
> familiar with the literature and need little or no explanation. 

That wasn't the intent (at least half of the authors are operators).

But we do indeed assume that the reader knows what IPv6 extension 
headers are, what they are for, etc.

I wouldn't mind writing a Section that sits between the current Sections 
2 and 3 with more background on extension headers, if you think that 
would be of value.

> I
> see this strongly in s.1, about Extension Headers, yet devoid of any
> reference, any explanation.  The first reference is RFC2460, which is
> Normative, so are readers expected to be familiar with the details
> therein? 

Yes. As noted above, I don't personally mind including a section that 
introduces the topic, if you think that'd be of value.

> One reaction might be 'So Extension Headers create problems
> so don't ever use them!'

Our goal is, for the most part, for folks to make an informed decision.
My *personal* take is that you probably may use EHs somewhat freely and 
safely in a limited domain, but not on the public Internet.

> The I-D lacks any explicit explanation of what an Extension Header
> is, what they were intended for, which bits have worked and which
> have failed so eg deprecating RHT0 is not very meaningful without
> some comment about RH something else.

Well, this is somewhat implied by having RFC8200 as a normative reference.

>  Size matters as can be
> inferred from s.4 but there is no mention of the sizes involved of
> the IPv6 packet, with or without headers.  As I say, it seems that
> the reader is expected to know the literature.  There needs to be a
> page or two at the start giving the context within which the detail
> makes sense.

Fair enough. We'll work on one.

> And then there is the future; should more Extension Headers be
> allocated, should they be constrained to avoid the difficulties
> raised here?  The I-D, for me, lacks an ending, lacks a look
> forward.

This is, in a way, intentional.

My *personal* thoughts are:
+ we should *not* constrain the allocation of EHs (see below)

+ developers should be aware that usage of IPv6 EHs on the public 
Internet increases the chances of packets being dropped (* NOTE)

+ In limited domains, "your network, your rules", so it should be 
generally fine to do things like SRv6. OTOH, if you expect that to work 
reliably on the *public* Internet, it may not.

(*) e.g., I recently changed the transport of my tunnels from v4 to v6. 
When doing so, Linux implicitly added a tunnel encap limit option to 
then, which resulting in the addition of a DO header, which led to the 
corresponding packets being dropped. SO the above advice would have 
suggested that, by default, one would have refrained from adding the DO 
header.

Other than the above, other speculations and advice will most likely be 
unrealistic. "don't drop the packets" -> "I have a network to run". 
"Have your platform be able to look into the packet without performance 
penalties" -> "I will if you pay for it", etc.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Sep 2020 14:46:01 -0300

Hello, Eduard,

On 14/9/20 08:55, Vasilenko Eduard wrote:
> I was discussing off-line with Fernando for long time about last
> Tom's comment. No success yet - no agreement to make any predictions
> or recommendations, 

Explaining the present is enough work as to get into trying to predict 
the future :-) . As for recommendations, other that the general thoughts 
I offered to Tom, I'm not sure we'd be able to make any other 
*realistic* recommendations.

> Just "raise awareness". I personally strongly
> suspect that a flood of new EH functionality that is in development
> now would greatly increase drop rate, because not all nodes would
> support everything needed at proper time.

If such functionality is to be employed in the public Internet, then... 
definitely!

But my understanding is that it is not. In such case, "your networks, 
your rules, your problem", I guess.

> Business is very restricted
> to something 7-10 years (depends on network layer) to refresh
> equipment, even if there is an EOS pressure. Current EH innovation is
> much faster. And additionally it overlays on slowdown of traffic
> growth (it was +50% just 2 years ago, 30% last year, 25% is probable
> this year) - would be more and more difficult to justify
> rip-and-replace.

I'd probably agree.

Now, what do you expect us to do or say about it?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Sep 2020 13:41:04 +1200

On 15-Sep-20 05:46, Fernando Gont wrote:
...
> your rules, your problem", I guess.

Well yes. This is exactly why I initiated RFC8799, but that is not an IETF
document. If the IETF doesn't recognise limited domains as part of the architecture,
we will never get past this problem.

    Brian

---

From: tom petch <[email-masked]>
Date: Tue, 15 Sep 2020 09:05:18 +0000

From: Fernando Gont <[email-masked]>
Sent: 14 September 2020 18:39

<tp>
Yes please.  One page or two pages max, summarising why they were thought a good idea, the different types and their uses, how widely used they are  and with references;  RFC8200 may be Normative but it takes a while to appear and that after RFC2460!  Section 3 makes reference to security, fragmentation and such like with no apparent connection to EH; I think that such a connection should be explicit earlier.

And below ....
</tp>

<tp> 
but it leaves the I-D without an ending, it just peters out.  With an introduction saying what EH are used for then you could have a summary harking back to that and saying which, or which kind of, work and which do not implying, without being explicit, what future developments might or might not be a problem.

Tom Petch
.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Sep 2020 08:24:22 -0300

Hi, Tom,

On 15/9/20 06:05, tom petch wrote:
[...]
> Yes please.  One page or two pages max, summarising why they were thought a good idea, the different types and their uses, how widely used they are  and with references;  RFC8200 may be Normative but it takes a while to appear and that after RFC2460! 

An intro to EHs -- and e.g., how the structure compares to the IPv4 
packet structure is simply and doable. OTOH, what you suggest might now. :-)

e.g.,Not sure one can tell how widely used they are. Also, getting into 
enumerating EHs will result in the relevant section becoming stale soon, 
since there seems to be quite a bit of development in this area.

> Section 3 makes reference to security, fragmentation and such like with no apparent connection to EH; I think that such a connection should be explicit earlier.

I'll craft some text and post to the list for review before 
incorporating into the I-D...

[...]
> but it leaves the I-D without an ending, it just peters out.  With an introduction saying what EH are used for then you could have a summary harking back to that and saying which, or which kind of,…

The think is that, on the public Internet, all that I have checked are 
unreliable. -- That's a sad fact... but a fact. :-)

If you control the network, well.. you control whether they are dropped.

And the obvious corollary is that use cases that are targetted at 
limited domains will likely work, where any targetted at the public 
Internet will fail, at least for some time.

That's as much as we can say so far -- based on data... since otherwise, 
guesswork is just guesswork.

Thoughts?

Thanks,

---

From: tom petch <[email-masked]>
Date: Tue, 15 Sep 2020 16:08:36 +0000

From: Fernando Gont <[email-masked]>
Sent: 15 September 2020 12:24

Hi, Tom,

<tp>
My sense is of the middle part of the I-D, the technical detail, is floating in mid-air, lacking an introduction, lacking a conclusion. and as such will only convince those who are already convinced.  I have to read between the lines to divine that there is a connection between fragmentation and EH, between length of packet header and EH, between security and EH and so on.  By not making the connection explicit, I think that you will lose your target audience.

Tom Petch

[...]

Thoughts?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2020 05:40:41 -0300

Hi, Tom,

On 15/9/20 13:08, tom petch wrote:
> From: Fernando Gont <[email-masked]> Sent: 15 September 2020
> 12:24
> 
> Hi, Tom,
> 
> On 15/9/20 06:05, tom petch wrote: [...]
>> 
>> I wouldn't mind writing a Section that sits between the current
>> Sections 2 and 3 with more background on extension headers, if you
>> think that would be of value.
>> 
>> <tp> Yes please.  One page or two pages max, summarising why they
>> were thought a good idea, the different types and their uses, how
>> widely used they are  and with references;  RFC8200 may be
>> Normative but it takes a while to appear and that after RFC2460!

Ok.  I will craft text and send it to the list for review before
incorporating it.

> e.g.,Not sure one can tell how widely used they are. Also, getting
> into enumerating EHs will result in the relevant section becoming
> stale soon, since there seems to be quite a bit of development in
> this area.
> 
> <tp> My sense is of the middle part of the I-D, the technical detail,
> is floating in mid-air, lacking an introduction, lacking a
> conclusion. and as such will only convince those who are already
> convinced.

FWIW, at lesast from my pov, we don't really want to convince people (of
doing this or that), but rather want to document the reasons for which
people may drop packets with EHs. i.e. documenting that such packets may
be dropped for very valid rational reasons.

> I have to read between the lines to divine that there is a connection
> between fragmentation and EH, between length of packet header and EH,
> between security and EH and so on.  By not making the connection
> explicit, I think that you will lose your target audience.

Fair enough. I'm always keen to improving the document, so thanks for 
the suggestion!

Regards,

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 19 Sep 2020 00:06:23 -0400

Hi Fernando

In this draft can we talk add point about the catch 22 situation described
in RFC 7045 excerpt below bottom of introduction:

I think this issue is critical to the overall issue with processing of EHs
and operators filtering EHs in some cases unnecessarily.

https://tools.ietf.org/html/rfc7045

   A contributory factor to this problem is that because extension
   headers are numbered out of the existing IP Protocol Number space,
   there is no collected list of them.  For this reason, it is hard for
   an implementor to quickly identify the full set of standard extension
   headers.  An implementor who consults only RFC 2460
<https://tools.ietf.org/html/rfc2460> will miss all
   extension headers defined subsequently.

   This combination of circumstances creates a "Catch-22" situation
   [Heller <https://tools.ietf.org/html/rfc7045#ref-Heller>] for the
deployment of any newly standardised extension
   header except for local use.  It cannot be widely deployed because
   existing middleboxes will drop it on many paths through the Internet.
   However, most middleboxes will not be updated to allow the new header
   to pass until it has been proved safe and useful on the open
   Internet, which is impossible until the middleboxes have been
   updated.

The uniform TLV format now defined for extension headers [RFC6564
<https://tools.ietf.org/html/rfc6564>]
   will improve the situation, but only for future extensions.  Some
   tricky and potentially malicious cases will be avoided by forbidding
   very long chains of extension headers that need to be fragmented
   [HEADER-CHAIN
<https://tools.ietf.org/html/rfc7045#ref-HEADER-CHAIN>].  This will
alleviate concerns that stateless
   firewalls cannot locate a complete header chain as required by the
   present document.

   However, these changes are insufficient to correct the underlying
   problem.  The present document clarifies that the above requirement
   from RFC 2460 <https://tools.ietf.org/html/rfc2460> applies to all
types of nodes that forward IPv6 packets
   and to all extension headers standardised now and in the future.  It
   also requests that IANA create a subsidiary registry that clearly
   identifies extension header types and updates RFC 2780
<https://tools.ietf.org/html/rfc2780> accordingly.
   Fundamental changes to the IPv6 extension header architecture are out
   of scope for this document.

On Wed, Sep 16, 2020 at 5:44 AM Fernando Gont <[email-masked]> wrote:

> > packet structure is simply and doable. OTOH, what you suggest might
>
> > now. :-)
>
> >
>

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 04:18:14 -0300

Hello, Gyan,

On 19/9/20 01:06, Gyan Mishra wrote:
> 
> Hi Fernando
> 
> In this draft can we talk add point about the catch 22 situation 
> described in RFC 7045 excerpt below bottom of introduction:
> 
> I think this issue is critical to the overall issue with processing of 
> EHs and operators filtering EHs in some cases unnecessarily.

What, specifically, would you like us to say about it?

Note: RFC6564 has not (and will not) improve the situation in this 
respect. Since EHs share the same namespece as "upper layer protocols", 
then, in order for a middlebox to know it can parse a header as in the 
RFC6564 format, it has to now that the corresponding "protocol number" 
identifies an EH (as opposed to an upper layer protocol).

RFC6564 would have been useful only if we had closed the door to the 
definition of new EHs with a new "protocol number", and had specified 
that any new EHs would share the same protocol number ("XX", to have 
been assigned by IANA at the time RFC6564 was published).

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Sat, 19 Sep 2020 11:48:55 +0200

> On 19 Sep 2020, at 09:19, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Gyan,
> 
>> In this draft can we talk add point about the catch 22 situation described in RFC 7045 excerpt below bottom of introduction:
>> I think this issue is critical to the overall issue with processing of EHs and operators filtering EHs in some cases unnecessarily.
> 
> Note: RFC6564 has not (and will not) improve the situation in this respect. Since EHs share the same namespece as "upper layer protocols", then, in order for a middlebox to know it can parse a header as in the RFC6564 format, it has to now that the corresponding "protocol number" identifies an EH (as opposed to an upper layer protocol).
> 
> RFC6564 would have been useful only if we had closed the door to the definition of new EHs with a new "protocol number", and had specified that any new EHs would share the same protocol number ("XX", to have been assigned by IANA at the time RFC6564 was published).
> 

Right, but only if the assumption that middleboxes would allow arbitrary headers in between network and transport is true.  That seems unlikely to me. 

Ole

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 07:18:38 -0300

Hi, Ole,

> Right, but only if the assumption that middleboxes would allow arbitrary headers in between network and transport is true.  That seems unlikely to me.

I agree. I don't think they would allow arbitrary headers in between 
network and transport. That said, *if* they were meaning to, they 
wouldn't be able to handle "unknown EHs", anyway. i.e., RFC6564 does not 
really deliver what's probably implied by the document: parsing unknown EHs.

In that sense, RFC6564 is unable to make any difference. Whether 
providing such feature (common EH format for all EHs, from now on) would 
have made a difference, is hard to tell... But I'd argue it wouldn't.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 19 Sep 2020 15:52:29 -0400

On Sat, Sep 19, 2020 at 6:37 AM Fernando Gont <[email-masked]> wrote:

> definition of new EHs with a new "protocol number", and had specified that
> any new EHs would share the same protocol number ("XX", to have been
> assigned by IANA at the time RFC6564 was published).
>
> >>
>
> >
>
> > Right, but only if the assumption that middleboxes would allow arbitrary
> headers in between network and transport is true.  That seems unlikely to
> me.
>
>
>

    So bottom line we don’t think there is any operational impact related
to eh drops due to operators filtering based on the catch-22 issue
regarding hardware not being able to support the new EH TLV based standard
RFC 6584 to support “new extension headers” supporting new TLV as we
believe that new are maybe few and far between that bucket that can impact
fast path eh processing. Based on the above we believe that we are in that
same boat as with eh headers use the same protocol number name space thus
impossible to have a complete list so not being able to be processed.

So net-net in theory does not really make a difference that the new RFC
6584 TLV style has made a difference in solving the problem and also maybe
be contributing to problem if old hardware does not support the new tlv
standard catch 22 issue.  Since tlv style is for new headers it helps new
headers being developed but you still have the gap with old headers using
protocol number name space and not documented or tracked anywhere for
support ability.

Here is an idea to help operators and overall eh processing issues from in
infrastructure ACL standpoint.

Also from that perspective as well is not a reason for operators to drop
ant eh and an idea is to maybe just explicitly permit all the original RFC
8200 standard eh and new RFC 6584 eh headers as a recommendation to not
just drop hbh and other headers that could end up being processed in the
slow path.  So instead of doing a drop xyz header followed by a permit any
you explicitly permit all RFC 8200 and RFC 6584 headers If your platform
supports.

*Gyan Mishra*

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Sep 2020 12:18:53 -0300

Gyan,

On 19/9/20 16:52, Gyan Mishra wrote:
[....]
>      So bottom line we don’t think there is any operational impact 
> related to eh drops due to operators filtering based on the catch-22 
> issue regarding hardware not being able to support the new EH TLV based 
> standard RFC 6584 to support “new extension headers” supporting new TLV 
> as we believe that new are maybe few and far between that bucket that 
> can impact fast path eh processing. 

I'm just saying that I don't think RFC6564 will have any sort of impact, 
for worse or better.

> Based on the above we believe that 
> we are in that same boat as with eh headers use the same protocol number 
> name space thus impossible to have a complete list so not being able to 
> be processed.

No.

I'm saying that you cannot parse something that you don't know what it 
is. RFC6564 does not change that in any way.

[...]
> ant eh and an idea is to maybe just explicitly permit all the original 
> RFC 8200 standard eh and new RFC 6584 eh headers as a recommendation to 
> not just drop hbh and other headers that could end up being processed in 
> the slow path.  So instead of doing a drop xyz header followed by a 
> permit any you explicitly permit all RFC 8200 and RFC 6584 headers If 
> your platform supports.

Please see draft-ietf-v6ops-ipv6-ehs-packet-drops. :-)

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Sep 2020 09:30:52 -0400

On Mon, Sep 21, 2020 at 6:53 PM Fernando Gont <[email-masked]> wrote:

> >     providing such feature (common EH format for all EHs, from now on)
>
> >     would
>
> >
>
> Gyan>. I think we are saying the same thing related to unknown eh headers
> using either protocol number name space and RFC 6564 does not improve or
> make it worse.  Can we add a normative reference to RFC 7045 related to eh
> processing issues with unknown headers types in protocol number name space
> and that RFC 6564 does not improve the situation.
>
>
>
>
>
> [...]
>
> >
>

   Gyan> ok

*Gyan Mishra*