Subject: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 1 Dec 2020 16:30:43 +0000

I promised a  careful read of this ID at the last v6OPS meeting, and 
this is it.

* First, I think this is a useful document to help understand what is 
happening in operational networks and reasons for this. It's also a 
ueseful input for planning standards actions in 6man, etc. Thanks for 
doing this.

* I have some concerns that some of the choices of words could 
(unintentionally) be taken as endorsing a best practice, which I don't 
think the IETF would generally promote. This is more about ensuring 
specific parts can not be quoted out of context. I did a careful read 
and hope I identified most of these and propose something that might be 
helpful (please see attached PDF - RTF is identical). I think it would 
be good to clarify in a few places this is the RFC8200 spec, since I 
have heard there could be new work to update that.

* On the measurement evidence: I have  a slight concern that the results 
might not cover the wide variety of use cases and you may like to be 
more careful in the words you use to generalise these for the 
"internet".  I think we should be aware that in some scenarios an EH 
might still be effectively used, where path can safely support this. In 
some other uses, the fact that packets with these options might be 
expected to be dropped by many paths - for good reasons, does not mean 
that the option is useless to set in general - it might merely be that 
for these paths it is not possible to use the option and then care is 
needed in deciding which packets set the EH and how this is used.

Hope this helps, Fernando. If you need any clarification or other help, 
just let me know,

Gorry

---

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Dec 2020 14:52:33 -0300

Hello, Gorry,

Thanks a lot for your feedback! -- We really appreciate it!

In-line...

On 1/12/20 13:30, Gorry Fairhurst wrote:
[...]
> have heard there could be new work to update that.

I don't mind doing that. However, isn't it implicit in all RFCs that 
they are referring to the current specifications (unless otherwise noted)?

i.e., regardless of whether there is ongoing work, and whether one is 
aware about it, a spec refers to the IETF status at the time the spec is 
published (*).

(*) Well, modulo RFC Ed processing times.

In any case, IIRC, RFC8200 is the current state of affairs when it comes 
to EH processing, so I guess explicitly referencing RFC8200 wouldn't 
hurt.  -- I'm CC'ing Brian, who may correct me if my "of the top o my 
head" assessment is not correct :-)

> might still be effectively used, where path can safely support this.

We're targeting the general case here. As they say, "with sufficient 
thrust, pigs fly just fine". You can, of course, build a network where 
EHs can be used just fine. -- but what we're discussing is the general case.

> In 

We certainly don't mean that. We mean "if you EHs, the chances of your 
packets being dropped increase, for the general case". As noted, you may 
employ them within environments where everything is under your control 
("your network, your rules"), or, I guess, might try to use them and 
have a fall-back mechanism (ala TCP ECN during 3WHS).

Some additional comments/questions based on the PDF you've attached:

> However, common implementation limitations suggest
> that EHs present a challenge for IPv6 packet routing equipment and
> middle-boxes, and evidence exists that IPv6 packets with EHs have been

Doesn't this imply that this is no longer the case? (i.e. your proposed 
change is "have been")

> If an IPv6 header chain is sufficiently long that its header exceeds
> the packet look-up capacity of the router, then it would be dropped by
> hardware that is unable to determine how it should be handled.

This seems rather confusing. It's the router that drops the packet.

> 5.1.
> Recirculation
> Although TLV chains are amenable to iterative processing on
> architectures that have packet look-up engines with deep inspection
>>>> is this /that/ ?

Not sure what you mean....

> As layer-4 port
> information increases the entropy of the hash, it is normally highly
> desirable to use it where possible.
>>>> I don’t agree with that actually, - but maybe others think so, please check
>>>> RFCs relating to ECMP or perhaps rephrase, something like: /Layer-4 port
> information can increase the entropy of the hash, and is often
> thought desirable to use it where it is available.
> /?

Your suggested change seems fine to me. That said, what would you employ 
for the hash if not the ports?

> We note that in the IPv6 world, flows are expected to be identified
> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based
> Load-Sharing is possible without the need to process the entire
>>>> why /would be possible/ ... some networks do this, and many RFCs encourage this?

Support for the FL is not widely deployed and implemented (see [Cunha-2020])

>>>>
> /also did not employ/
> do you really need to claim that? I suggest we could write this
> in more neutral language, since some implementations recently
> changed this practice?
> Perhaps;
> /When many IPv6
> implementations failed to set the Flow Label, many ECMP and Hash-based
> Load-Sharing devices also did not include the Flow Label [Cunha-2020],
> possibly as a result of issues that have been found
> in host implementations and middle-boxes [Jaeggli-2018]./
> although it seems like

The suggested change seems to imply that the situation has changed, but 
I believe it hasn't. [Cunha-2020] provides evidence in this respect. SO 
assuming that this is something from the past would be inaccurate.

>>>> I suggest the section includes mention of the IETF recommendation,
>>>> and there the path with “clearly...” should be at the end!

Ok with moving the para "Clearly.." to the end. That said, could you 
elaborate on what IETF recommendation you're referring to?

> Use of extension headers can result problematic for NIDS/IPS, since:
>>>/may/can/ ... not necessary, but might as well use /can/ in this case?

Doesn't "may" imply possibility here?

> As a result, in order to increase the efficiency or effectiveness of
> these systems, packets employing IPv6 extension headers can be
>>>> /can/ or /have been/are being/ ... to follow the previous argument?
> dropped at the network ingress point(s) of networks that deploy these
> systems.

(Must admit that since you're a native English speaker, I have a high 
probability of being wrong :-), but, anyway):

Packets can be drop, whether with EHs or anything else (i.e., the 
contents of a packet does not affect the ability of a device dropping 
them -- at the end of the day, a device can drop *all* packets if it 
feels like).

What we are meaning here is that dropping packets with EHs is indeed one 
option to increase the efficiency and effectiveness of these systems.
We don't mean to "give permission" to operators, because, at the end of 
the day, they don't need to ask :-)  (they don't, and they shouldn't, 
IMO!).  That's why we use "may" -- it's an actual possible operational 
policy to deal with the problem at hand.

> o Use of unknown extension headers can prevent an NIDS/IPS to
> process layer-4 information

I this case, I think both are fine: -- "can" as in ability, and "may" as 
in possibility

> As a result, whether because of the challenges represented by
> extension headers or because the use of IPv6 extension headers has
> not been explicitly allowed, packets employing IPv6 extension headers
> can be dropped by network firewalls.
>>>> /can/ or /have been/are being/ ... to follow the previous argument?

Same as before: I don't think you need reasons for an "ability". What we 
mean is that firewalls may (as in "possibility of intended behaviour") 
drop such packets.

> When such devices are unable to obtain the
> required information, they might simply resort to dropping the
>>>> /may/might/ ?

"might" reads as a possibly imaginary situation. What we are meaning is 
that some devices *do* this.

> Some router implementations lack fine-grained filtering of IPv6
> extension headers. For example, an operator may want to drop packets
> containing Routing Header Type 0 (RHT0) but may only be able to
> filter on the extension header type (Routing Header). As a result,
> the operator would end up enforcing a more coarse filtering policy
> (e.g. "drop all packets containing a Routing Header" vs. "only drop
> packets that contain a Routing Header Type 0").

The proposed change seems to change the meaning of the paragraph. i.e., 
these things *do* happen.

>  Additionally, implementation
>    inconsistencies in packet forwarding engines can result in evasion of
>    security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014]
>    [BH-EU-2014].

The original text said "...may result in evasion". It would seem to me 
that both are correct ("can" = ability, "may" = possibility)?  Actually, 
the later implies the former?

Same for this one:

> Packets with attached IPv6 Extension Headers can impact performance
> on routers that forward them.

> [Gont-Chown-IEPG89]
> Gont, F. and T. Chown, "A Small Update on the Use of IPv6
> Extension Headers", IEPG 89. London, UK. March 2, 2014,
> <http://www.iepg.org/2014-03-02-ietf89/fgont-iepg-ietf89-
> eh-update.pdf>.
> [Gont-IEPG88]
> Gont, F., "Fragmentation and Extension header Support in
> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada.
> November 13, 2013, <http://www.iepg.org/2013-11-ietf88/
> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.
>>>> These don’t seem great presentations, and seem like they were
>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0?
>>>> I don’t know why these are useful as references? RC7872 also covers this?

They are listed as they were part of the work that eventually resulted 
in RFC7872, and as an indication of for how long the problem has been 
looked into. At the time, we didn't even have tools to do the 
measurements. For example, the path6 tool I implemented, and the support 
in RIPE Atlas were triggered by these efforts.

>>>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf
>>>> contains useful insight instead of these two?

I will read it. Thanks for the pointer! -- I wasn't aware about this paper.

Thanks!

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 2 Dec 2020 19:33:05 +0000

> Hello, Gorry,
Hi!

>> (unintentionally) be taken as endorsing a best practice, which I 
>> don't think the IETF would generally promote. This is more about 
>> ensuring specific parts can not be quoted out of context. I did a 
>> careful read and hope I identified most of these and propose 
>> something that might be helpful (please see attached PDF - RTF is 
>> identical). I think it would be good to clarify in a few places this 
>> is the RFC8200 spec, since I have heard there could be new work to 
>> update that.
>
> aware about it, a spec refers to the IETF status at the time the spec 
> is published (*).
>
> In any case, IIRC, RFC8200 is the current state of affairs when it 
> comes to EH processing, so I guess explicitly referencing RFC8200 
> wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of the 
> top o my head" assessment is not correct :-)
>
The above is all true - and I think it is simple to add the REF!
>
>> * On the measurement evidence: I have  a slight concern that the 
>> results might not cover the wide variety of use cases and you may 
>> like to be more careful in the words you use to generalise these for 
>> the "internet".  I think we should be aware that in some scenarios an 
>> EH might still be effectively used, where path can safely support this.
>
Why? - as a transport guy, the only thing that matters is whether a 
specific path supports them, the average case just tells me whether I 
need a fallback mechanism to cope with a particular path not supporting;-)
>
>> In some other uses, the fact that packets with these options might be 
>> expected to be dropped by many paths - for good reasons, does not 
>> mean that the option is useless to set in general - it might merely 
>> be that for these paths it is not possible to use the option and then 
>> care is needed in deciding which packets set the EH and how this is 
>> used.
>
> packets being dropped increase, for the general case". 
Yes, the chance that you encounter a path the drops packets with EHs.
> As noted, you may employ them within environments where everything is 
> under your control ("your network, your rules"), or, I guess, might 
> try to use them and have a fall-back mechanism (ala TCP ECN during 3WHS).
>
>
>
> Doesn't this imply that this is no longer the case? (i.e. your 
> proposed change is "have been")
>
>
/have been/are/ ... if that makes better sense to you, they're 
equivalent to me - you observe what has happens and you can predict what 
is happening, you might now know the future.
> This seems rather confusing. It's the router that drops the packet.
/hardware/router hardware/

> Not sure what you mean....
I was suggesting using that in place of /which/... minor nit.
> Your suggested change seems fine to me. That said, what would you 
> employ for the hash if not the ports?
>
flow label?
> Support for the FL is not widely deployed and implemented (see 
Yes I looked at Cunha - it's just a slide deck - is there a paper that 
can be read to check the measurement methodology and results?

I hear others saying that it is now more often being set, ... so I'm 
just urging caution here, because I am not sure v6OPS need to comment on 
the results of this on-going work at this stage. For instance... what is 
the chance that a router now observes a flow label set to non-zero? ...

> The suggested change seems to imply that the situation has changed, 
> but I believe it hasn't. [Cunha-2020] provides evidence in this 
> respect. SO assuming that this is something from the past would be 
> inaccurate.
>
Well.... we can debate this, if we need to, however:  - i.e., I think 
the existence of techniques that utilise ports is sufficient to justify 
why the router wishes to traverse the header chain, and why extension 
headers are problematic - that does not need to present anything about 
what is good practice for ECMP without predjudice to deployment of 
FL-based methods.
> Doesn't "may" imply possibility here?
No. In many reader's eyes this is permissive ... do it would read are 
permitted to.
> them -- at the end of the day, a device can drop *all* packets if it 
:-)
> What we are meaning here is that dropping packets with EHs is indeed 
> one option to increase the efficiency and effectiveness of these systems.
That sounds correct.
> We don't mean to "give permission" to operators, because, at the end 
> of the day, they don't need to ask :-)  (they don't, and they 
> shouldn't, IMO!).  That's why we use "may" -- it's an actual possible 
> operational policy to deal with the problem at hand.
>
>
> I this case, I think both are fine: -- "can" as in ability, and "may" 
> as in possibility
>
- but not may as in "are permitted to"...
> Same as before: I don't think you need reasons for an "ability". What 
> we mean is that firewalls may (as in "possibility of intended 
> behaviour") drop such packets.
>
>
> "might" reads as a possibly imaginary situation. What we are meaning 
> is that some devices *do* this.
>
OK : then say that devices do this,... rather than they are permitted to.
> The proposed change seems to change the meaning of the paragraph. 
> i.e., these things *do* happen.
>
How about something like:

Some router implementations do not have fine-grained filtering of IPv6
extension headers. For example, an operator that wishes to drop packets
containing Routing Header Type 0 (RHT0), may only be able to
filter on the extension header type (Routing Header). This would

result in an operator  enforcing a more coarse filtering policy
(e.g. "drop all packets containing a Routing Header" vs. "only drop
packets that contain a Routing Header Type 0").

???

> that both are correct ("can" = ability, "may" = possibility)?  
> Actually, the later implies the former?
>
>
/can/will/ or whatever or just /result in/ ?
>> on routers that forward them.
Except in this case, I think the performance of some designs of router 
are impacted when forwarding packets with IPv6 EH.

> measurements. For example, the path6 tool I implemented, and the 
> support in RIPE Atlas were triggered by these efforts.
I don't agree with that. They are actually cited in RFC7872 if taht is 
your reason, so that is already clear!

>>>>> Is it worth also seeing whether Hendriks et al, 
>>>>> http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf

-- 
G. Fairhurst, School of Engineering

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Dec 2020 13:06:42 -0700

> packets being dropped increase, for the general case".

Fernando,

That's true of a lot protocols. If you use fragmentation, any protocol
other than TCP or UDP, encryption, encapsulation, or even IPv6  your
chances of packets being dropped increase in the general case. In fact
many of the reason noted in this draft for drops are the same those
other cases. So it's generally true that any deviation from a narrow
set of protocols and options that are known to be commonly supported
by routers risks increased chance of packet drop.

I view this draft is another case of trying to document and explain
the status quo for how routers and middleboxes implement the protocol
(we saw the similar discussion in RFC8900 and
draft-ietf-tsvwg-transport-encrypt-18). Documenting current real world
behavior is good, however it needs to been in context (similar to
concerns raised for other like drafts):
1) Some of the behaviors being documented are either contrary with the
Internet architecture or downright non-conformant with the standards.
IMO this needs to be clarified and called when discussing some
particualar mechanism a vendor has chosen to implement. This may be
describing current practice, but as Gorry this in no way should be
construed as IETF best practice
2) We need to realize there are potentially conflicting rrequirements.
For instance, in this draft there is a statement "contemporary routers
and middle-boxes that need to find the layer-4 header must process the
entire IPv6 extension header chain.". I do not believe there is any
core IETF standard that requires routers to access the transport
layer, that's more a design choice vendors have made. In fact, from a
host perspective, we are trying to obsolete that by encrypting
transport headers like in QUIC for instance (there are both security
and protocol evolution motivations for doing that).
3) We need to very careful about making conclusions or even those that
are inferred by the reader. It should be very clear that this
documenting is not advocating obsoleting extension headers nor that
arbitrary dropping of packets with extension headers is acceptable.
4) It would be nice to have some guidance on a way forward. Assuming
that the consensus is that extension headers are still useful, what
can we do to increase their viablitiy? We already have a couple of
examples of this: RFC8200 relaxed the requirements that all nodes must
process HBH EH, RFC8883 describes ICMP errors to send when an
intermeidate does drop a packet with EH.
5) Specific to this draft, almost all the references are at least five
years old. For instance, RFC7872 which is considered the reference for
measurement of EH drops on the Internet dates back to 2016. So these
aren't really fresh and  in the case of RFC7872 that was publsihed
before RFC8200 so it doesn't reflect the impact of the updated EH
related requirements in RFC8200. More recent data and analysis would
strengthen the discussion.

Tom

> As noted, you may
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Dec 2020 12:04:34 +1300

> head" assessment is not correct :-)

Yes, although 8200 does give a polite nod to 7045 and does *not*
obsolete it.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Dec 2020 21:17:24 -0300

Hi, Gorry,

Thanks for your timely response! In-line....

On 2/12/20 16:33, Gorry Fairhurst wrote:
[....|]
> The above is all true - and I think it is simple to add the REF!

I will apply the proposed ref. I just want to double-check that we're 
not leaving outside e.g. things like RFC7045, which I should 
double-check whether it's fully incorporated into RFC8200. Otherwise, 
just mentioning RFC8200 would be imprecise.

> need a fallback mechanism to cope with a particular path not supporting;-)

The evil comment would be that, as a transport guy, you don't control 
the path. Or, furthermore, there's no concept of "path" for a transport 
guy ;-)

> is happening, you might now know the future.

WHat I mean is that we're not referring to the occurence of some event 
in the past, but rather about something that is still the case.

> /hardware/router hardware/

Would the meaning be  hanged if we just say "router"?

> I was suggesting using that in place of /which/... minor nit.

Oops -- my bad! (And thanks for it, btw!  For English-as-second language 
I remember studying "that vs. which"... and it seems I should recheck, 
as the RFC-Ed frequently corrects these for me :-(  )

>> employ for the hash if not the ports?

The thing is that you cannot rely on it. So, if you want entropy, your 
safe bet is to use the port numbers....

> can be read to check the measurement methodology and results?

There's also a paper -- my apologies for not referencing it. I will 
check if it's online, and otherwise ask the author for permission to 
share it.

> the chance that a router now observes a flow label set to non-zero? ...

It's not only to have a non-zero FL, but also that the FL is set 
correctly -- e.g., some implementations used to employ one FL value 
during 3WHS, and another during the life of a connection. Thus, if you 
were using the FL for load-sharing, it would actually break things.

FWIW, I wish the FL was widely and correctly implemented and deployed -- 
I'm just the messenger here.

> what is good practice for ECMP without predjudice to deployment of 

What we mean here is: the reader might wonder "why don't you just use 
the FL?  -- Because we can't".

More of empirical evidence than prejudice.

> No. In many reader's eyes this is permissive ... do it would read are 

Any alternative wording that would convey "possibility" rather than 
"ability" or "permission"?

>> one option to increase the efficiency and effectiveness of these systems.

Would modifying the text as phrased address your comment?

> - but not may as in "are permitted to"...

Would "could" be better to convey "posibility" rather than ability or 
permission?

> OK : then say that devices do this,... rather than they are permitted to.

I'll tweak to:

"Some of such devices, when unable to obtain the required information, 
simply resort to...". OK?

> packets that contain a Routing Header Type 0").

Looks good to me! Thanks!

> /can/will/ or whatever or just /result in/ ?

"often results in"?

> are impacted when forwarding packets with IPv6 EH.

Other than HbH, the performance impact generally results from looking up 
the L4 header.

That said, upon re-read of your suggestion, it looks good to me.

> I don't agree with that.

Which part, specifically? :-)

Well, I don't think there were tools available at the time. But if you 
know of any, I'd like to know!

> They are actually cited in RFC7872 if taht is your reason, so that is already clear!

That said, I don't mind removing these two references. They were 
including in this document at a time RFC7872 didn't exist -- i.e. we 
don't have any special motivation for including them.

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Dec 2020 21:19:36 -0300

> Yes, although 8200 does give a polite nod to 7045 and does *not*

So, my question is: would it be correct to say "Extension Headers as 
specified in RFC8200"? -- or would that be imprecise because it fails to 
note that EHs are partially specified in RFC7045?

FWIW, I don't mind applying the change Gorry suggested, as long as the 
text is still correct/precise.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Dec 2020 21:37:44 -0300

Hi, Tom,

On 2/12/20 17:06, Tom Herbert wrote:
[....]
> chances of packets being dropped increase in the general case.

I haven't seen measurements in that respect.

> In fact
> by routers risks increased chance of packet drop

I don't think this is necessarily the case.

> construed as IETF best practice

This document doesn't pretend to be a BCP. For instance, we have a 
Disclaimer in that respect: 
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2

> layer, that's more a design choice vendors have made.

That depends a lot whether you're referring to the conceptual role of 
router, or to the concept of "router" as deployed in the real 
operational world.

> In fact, from a
> are inferred by the reader.

I don't think we are driving to a lot of conclusions here. Actually, 
we're elaborating on the empirical results.

> It should be very clear that this

That's why we have: 
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2 
  . At the end of the day, I don't think one can do a lot better than 
that (and tweaking the document as suggested by Gorry, of course).

> 4) It would be nice to have some guidance on a way forward.

It *would* be nice. However, most of the ways forward are unrealistic. 
To name a few:

1) You can't claim you support IPv6 if you can't handle EHs of arbitrary 
length.

2) You can't claim you support IPv6 if long EH chains result in a 
performance impact.

3) You can't claim you support IPv6 if you peek at the EH chain -- 
whether you are a router, NIDS, firewall, or load-balancer

4) Dropping packets with EHs is being a bad Internet neighbor.

Re: #1-3: I guess IETF/6man would be unhappy to realize that, then, IPv6 
is not as widely implemented.

Re: #4: I guess operators will note that they ave a network to run.

> Assuming
> that the consensus is that extension headers are still useful,

FWIW, we're not making statements in that respect. We're elaborating on 
the problem at hand, and the considerations when relying on EHs.
I would assume that, at the very lest, you can leverage EHs in the 
so-called "limited domains" -- and that's what spring et al are doing.

> what can we do to increase their viablitiy?

Improved support in network devices. But that normally implies $ than 
needs to be invested by some, and payed by others.

> strengthen the discussion.

The only EH that was relaxed is HbH. And the numbers for other EHs are 
already bad enough. I'm not sure how that would change the reality and 
assessment.

Thanks!

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Dec 2020 13:50:13 +1300

> note that EHs are partially specified in RFC7045?

Maybe you should ask the authors of 8200 why they didn't obsolete 7045?

It's my belief that 8200 simply codifies in slightly different words
what 7045 says, as far as normative requirements go, but the informative
text in 7045 remains valid, and is therefore not obsoleted.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Dec 2020 18:31:08 -0700

Fernando,

The analogue evil comment would be that, as a network guy, you
shouldn't have any interest in the transport layer. Or furthermore,
there's no concept of a "transport layer" for a network guy ;-)

The fact is that hosts, including the transport layer, do have a
vested interest in the network path to a destination and what its
characteristics are as part of ensuring viable end to end
communications. As Gorry alludes to, if the host can get information
apriori about the capabilities that a particular network path supports
then we're able to apply fallbacks when the path doesn't support the
requested functionality or possibly influence the routing to get a
better path. For instance, if my host has information that EH headers
are supported to some destination on the Internet then why not use
them to that destination if they offer better service for the user?

Tom

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Dec 2020 22:31:52 -0300

> text in 7045 remains valid, and is therefore not obsoleted.

Ok. Then it would be safe to reference RFC8200 as *the* specification 
for EHs. I'm CC'ing Bob since he might correct me in case I'm missing 
something.

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2020 04:50:19 -0300

Hi, Gorry,

[----]
> Hope this helps, Fernando. If you need any clarification or other help, 

I had promised to read "Threats and Surprises behind IPv6 Extension 
Headers" (http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf)

My read of the paper is essentially that EHs are largely unused. And 
when it comes to actual use of EHs, they seem to boil down to fragmented 
UDP (already considered fragile, per RFC8900), local-link traffic (e.g. 
MLD), some IPsec, and what seem to be bogus traffic (e.g., ICMPv6 errors 
being fragmented or employing HbH headers).

No surprises here.

Then, in the "Conclusions" section, the authors note:

"Dropping all packets that contain Extension Headers is a bad practice" 
-- with which I disagree. Not that I think it is great to have to resort 
to dropping packets with EHs, but rather because folks that a network to 
run, and if allowing such packets will prevent them from doing what they 
need to do, or open their network to DoS, then, given the options they 
have on the table, dropping such packets might be the most acceptable one.

They also note:
"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: the exceptional packets containing more EHs
can be handled in the slow-path, i.e. a slower CPU in the
network device, without substantial performance loss, while
still offering flexibility to drop packets with e.g. more than
three EHs to prevent the possible Denial of Service attack"

This doesn't seem to make a lot of sense. A key design choice is the 
EH-chain length to be supported, rather than EH # count.  And no, I 
don't think you want to process packets in the slower path -- unless you 
rate limit them to such a small number, that it wouldn't make sense, anyway.

Thanks,

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 3 Dec 2020 08:32:02 +0000

HI, I think we are converging...

On 03/12/2020 00:17, Fernando Gont wrote:
>>>> identical). I think it would be good to clarify in a few places 
>>>> this is the RFC8200 spec, since I have heard there could be new 
>>>> work to update that.
>>>
>>> i.e., regardless of whether there is ongoing work, and whether one 
>>> is aware about it, a spec refers to the IETF status at the time the 
>>> spec is published (*).
>>>
>>> wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of 
>>> the top o my head" assessment is not correct :-)
>>>
>>>> like to be more careful in the words you use to generalise these 
>>>> for the "internet".  I think we should be aware that in some 
>>>> scenarios an EH might still be effectively used, where path can 
>>>> safely support this.
>>>
>>> thrust, pigs fly just fine". You can, of course, build a network 
>>> where EHs can be used just fine. -- but what we're discussing is the 
>>> general case.
>>>
> the path. Or, furthermore, there's no concept of "path" for a 
> transport guy ;-)
>
We do have the notion of a path... but it may be that is different to 
your notion.
>> equivalent to me - you observe what has happens and you can predict 
>> what is happening, you might now know the future.
>
> What I mean is that we're not referring to the occurence of some event 
Sure, why not write this is still the case?
> Would the meaning be  hanged if we just say "router"?
Router is OK for me.
> Oops -- my bad! (And thanks for it, btw!  For English-as-second 
> language I remember studying "that vs. which"... and it seems I should 
> recheck, as the RFC-Ed frequently corrects these for me :-(  )
>
>
>
>
>>>> As layer-4 port
OK, but I still do not understand why this particular RFC-to-be would 
make a judgment on this issue, it is not related to EH, the desire of 
some devices to look for transport headers is irrefutable. This happens 
for various reasons of which this is one. There are other things that 
happen also - but in the context of this document, the text can be 
entirely neutral as to whether this is good or bad practice.
>> Yes I looked at Cunha - it's just a slide deck - is there a paper 
>> that can be read to check the measurement methodology and results?
>
That would help a lot to read that.
>> just urging caution here, because I am not sure v6OPS need to comment 
>> on the results of this on-going work at this stage. For instance... 
>> what is the chance that a router now observes a flow label set to 
>> non-zero? ...
>
> FWIW, I wish the FL was widely and correctly implemented and deployed 
> -- I'm just the messenger here.
>
So, I'm urging that the message is represented as saying that at the 
time of publication, load-sharing and other techniques utilise the 
transport header information [REF]. To access this information, a router 
need to process the EH chain, and this leads to issues ... as you decribe.
>> the existence of techniques that utilise ports is sufficient to 
>> justify why the router wishes to traverse the header chain, and why 
>> extension headers are problematic - that does not need to present 
>> anything about what is good practice for ECMP without predjudice to 
>> deployment of FL-based methods.
>

Observing this happens is helfpul - with more clarity of recent trends 
in setting and using.

However, I will objec interpretation of this to how to use (or not) the 
FL. This document is not the correct place to offer this advice.

One: because this document is not about ECMP and FL, it is about EH.

Two: because this is an informational document from an OPS WG trying to 
change something that is being used by PS in Transport and Internet areas.

> "ability" or "permission"?
Trying to be close to your original wording:

Problems can arise when EH are used for NIDS/IPS, since:

(The meaning here is clear to me, in that the problems can arise).

>>> (Must admit that since you're a native English speaker, I have a 
>>> high probability of being wrong :-), but, anyway):
>>>
>>> contents of a packet does not affect the ability of a device 
>>> dropping them -- at the end of the day, a device can drop *all* 
>>> packets if it feels like).
>>>
>> :-)
Pehaps, you could try something.

I'd suggest just being neutral and saying:

As a result, IPS systems have been observed to drop packets employing 
IPv6 extension headers at the network ingress point(s).

>>> I this case, I think both are fine: -- "can" as in ability, and 
>>> "may" as in possibility
>>>
Could is fine.
> simply resort to...". OK?
/such/these/ ... seems like a reasonable statement to me:-).
>>> The original text said "...may result in evasion". It would seem to 
>>> me that both are correct ("can" = ability, "may" = possibility)? 
That is also good - since there is a reference to clarify often!
>> Except in this case, I think the performance of some designs of 
>> router are impacted when forwarding packets with IPv6 EH.
>
> Other than HbH, the performance impact generally results from looking 
> up the L4 header.
>
>>> They are listed as they were part of the work that eventually 
>>> resulted in RFC7872, and as an indication of for how long the 
>>> problem has been looked into. At the time, we didn't even have tools 
>>> to do the measurements. For example, the path6 tool I implemented, 
>>> and the support in RIPE Atlas were triggered by these efforts.
>> I don't agree with that.
>
Aha - that now make sense, if RFC7872 hadn't been finalised. So removing 
them would be good for me.

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2020 07:57:23 -0300

Hi, Gorry!

> HI, I think we are converging...

Indeed!

[....]
> We do have the notion of a path... but it may be that is different to 

For curiosity sake: what would be that notion?  It would seem to me 
that, if anything, the transport view of a path is kind of single-hop 
with varying properties.  As opposed to e.g. multiple ways to get to the 
same destination.

i.e., internet-layer could find a working path, where transport cannot.

> Sure, why not write this is still the case?

s/may be/are/?

> entirely neutral as to whether this is good or bad practice.

I'll apply the suggested edit unless I hear otherwise from the 
group/co-authors.

FWIW, the only thing that were meaning was "Yes, we know folks are 
supposed to use the FL for that... but that's not feasible... hence the 
*need* to look up the port numbers"

> That would help a lot to read that.

I've asked for permission to share. Worst-case scenario, I'll send it 
unicast.

> need to process the EH chain, and this leads to issues ... as you decribe.

Would this be addressed by:

OLD:
As layer-4 port

NEW:
    Most forwarding engines employ layer-4 port information to increase
    the entropy of the hash, and this implies the need to process the
    IPv6 header chain, thus leading to the issues discussed in this
    document.

?

> One: because this document is not about ECMP and FL, it is about EH.

Not sure what you mean. THis section is discussing why some boxes may 
need to access the layer-4 information. For load-sharing, the reader 
might wonder "why aren't you using the FL in the first place?" -- that¡s 
the only reason why we're mentioning the FL here...

We're not advising whether to use or not the FL. We're simmply 
explaining why boxes actually need to access the layer-4 info...

> change something that is being used by PS in Transport and Internet areas.

I'm a bit lost here. This document is not trying to provide any sort of 
advice. We essentially elaborate on why boxes need to access layer-4 
information, and what are the options they have on the table (if any) if 
they can't.

> Problems can arise when EH are used for NIDS/IPS, since:

Maybe /used for/processed by/ ?

> IPv6 extension headers at the network ingress point(s).

Looks good to me.

>> Would "could" be better to convey "posibility" rather than ability or 

Done ;-)

> /such/these/ ... seems like a reasonable statement to me:-).

Will do.

[....]
> Aha - that now make sense, if RFC7872 hadn't been finalised. 

Indeed, this text (with these references) had been crafted before 
RFC7872 got published.

> So removing  them would be good for me.

I don't mind, and thus will do unless I hear otherwise from the group.

Thanks!

Regards,

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 3 Dec 2020 11:36:52 +0000

See below

On 03/12/2020 10:57, Fernando Gont wrote:
>>>>> We're targeting the general case here. As they say, "with 
>>>>> sufficient thrust, pigs fly just fine". You can, of course, build 
>>>>> a network where EHs can be used just fine. -- but what we're 
>>>>> discussing is the general case.
>>>>>
>>>> specific path supports them, the average case just tells me whether 
>>>> I need a fallback mechanism to cope with a particular path not 
>>>> supporting;-)
>>>
>>> The evil comment would be that, as a transport guy, you don't 
>>> control the path. Or, furthermore, there's no concept of "path" for 
>>> a transport guy ;-)
>>>
> with varying properties.  As opposed to e.g. multiple ways to get to 
> the same destination.
>
The transport can sometimes choose between paths it sees available.

Most of the concern of the transport is to characterise the current 
actual path(s) - discovering the PMTU - i.e. the largest size of packet 
are not forwarded, discovering if certain headers are not forwarded, 
often trying to determine the current capacity, rtt, jitter, reordering, 
etc. Possibly trying to associate QoS or other information with packets 
in a flow to influence the network path. etc.

>>> What I mean is that we're not referring to the occurence of some 
>>> event in the past, but rather about something that is still the case.
>>>
Fine with me.
>>> The thing is that you cannot rely on it. So, if you want entropy, 
>>> your safe bet is to use the port numbers....
>>>
>> some devices to look for transport headers is irrefutable. This 
>> happens for various reasons of which this is one. There are other 
>> things that happen also - but in the context of this document, the 
>> text can be entirely neutral as to whether this is good or bad practice.
>
> supposed to use the FL for that... but that's not feasible... hence 
> the *need* to look up the port numbers"
>
>
>
>
Look foward to learning more.
>
>
>>>> I hear others saying that it is now more often being set, ... so 
>>>> I'm just urging caution here, because I am not sure v6OPS need to 
>>>> comment on the results of this on-going work at this stage. For 
>>>> instance... what is the chance that a router now observes a flow 
>>>> label set to non-zero? ...
>>>
>>> during 3WHS, and another during the life of a connection. Thus, if 
>>> you were using the FL for load-sharing, it would actually break things.
>>>
>>> FWIW, I wish the FL was widely and correctly implemented and 
>>> deployed -- I'm just the messenger here.
>>>
>> transport header information [REF]. To access this information, a 
>> router need to process the EH chain, and this leads to issues ... as 
>> you decribe.
>
Hmmm... can we more neutral:

"Forwarding engines that employ layer-4 port information to increase
    the entropy of the hash have a need to process the
    IPv6 header chain, thus leading to the issues discussed in this
    document."

>>>>> The suggested change seems to imply that the situation has 
>>>>> changed, but I believe it hasn't. [Cunha-2020] provides evidence 
>>>>> in this respect. SO assuming that this is something from the past 
>>>>> would be inaccurate.
>>>>>
>>>> Well.... we can debate this, if we need to, however:  - i.e., I 
>>>> think the existence of techniques that utilise ports is sufficient 
>>>> to justify why the router wishes to traverse the header chain, and 
>>>> why extension headers are problematic - that does not need to 
>>>> present anything about what is good practice for ECMP without 
>>>> predjudice to deployment of FL-based methods.
>>>
>>> What we mean here is: the reader might wonder "why don't you just 
>>> use the FL?  -- Because we can't".
>>>
>> Observing this happens is helfpul - with more clarity of recent 
>> trends in setting and using.
>>
>> However, I will objec interpretation of this to how to use (or not) 
>> the FL. This document is not the correct place to offer this advice.
>>
> might wonder "why aren't you using the FL in the first place?" -- 
> that¡s the only reason why we're mentioning the FL here...
>
>> Two: because this is an informational document from an OPS WG trying 
>> to change something that is being used by PS in Transport and 
>> Internet areas.
>
> I'm a bit lost here. This document is not trying to provide any sort 
> of advice. We essentially elaborate on why boxes need to access 
> layer-4 information, and what are the options they have on the table 
> (if any) if they can't.
>
See above suggestion about how you might take a more neutral position?
>>>>> Ok with moving the para "Clearly.." to the end. That said, could 
>>>>> you elaborate on what IETF recommendation you're referring to?
>>>>>
>>>> No. In many reader's eyes this is permissive ... do it would read 
>>>> are permitted to.
>>>
Much better.
>>>>> What we are meaning here is that dropping packets with EHs is 
>>>>> indeed one option to increase the efficiency and effectiveness of 
>>>>> these systems.
>>>> That sounds correct.
>>>
>>> Would "could" be better to convey "posibility" rather than ability 
>>> or permission?
>>>
>>>
>> Could is fine.
>
> Done ;-)
>
>
>>>
>>>>> "might" reads as a possibly imaginary situation. What we are 
>>>>> meaning is that some devices *do* this.
>>>>>
>>> "Some of such devices, when unable to obtain the required 
>>> information, simply resort to...". OK?
>>>
>>>

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2020 12:29:36 -0300

Hi, Gorry,

BTW, Italo noted that he has posted the paper on his site, so it's 
available here [CUnha-2020]: 
https://homepages.dcc.ufmg.br/~cunha/papers/almeida20infocom-mca.pdf

In-line...

On 3/12/20 08:36, Gorry Fairhurst wrote:
[....]
> The transport can sometimes choose between paths it sees available.

How would it? -- It'd seem to me that it could at most pick pairs of 
{Src, Dst}  (but actually, probably it wouldn't/shouldn't, if node 
identifiers (as opposed to interface identifiers) were used for the 
connection-id).

[....]
[...]
> Look foward to learning more.

Please see above.

>     IPv6 header chain, thus leading to the issues discussed in this

Fine for me (FWIW, the intent was to be neutral.. although at times it's 
hard to author and "review" from the eyes of a read at the same time.. 
So apologies for the pain caused... :-) )

(Ive omitted the proposed changes that didn't need further discussion)

P.S: I'll rev the document this next weekend as the latest.

Thanks for helping us improve the document, btw!

Regards,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Dec 2020 10:02:33 -0700

Fernando,

There is no protocol requirement that "folks", I assume meaning
intermediate devices, need use the flow label nor transport port
numbers for anything, neither is there any requirement that hosts have
to expose port numbers in plain text or set a non-zero flow label.
These are both optional and best-effort by definition; RFC6437
describes how flow labels are only best effort, and RFC7605 describes
the perils of intermediate devices attempting to interpret port
numbers. As for using flow labels not being feasible I don't see the
basis for that statement. There are deployed devices that have been
using flow labels for various purposes for quite a while, for instance
Linux OS has been setting and consuming non-zero flow labels for years
in both host and router configurations for RSS, ECMP, etc. Yes, like
anything else we occasionally encounter issues and sometimes they hit
interoperable devices, but we do fix issues and haven't declared they
aren't feasible.

Tom

---

From: Fred Baker <[email-masked]>
Date: Thu, 3 Dec 2020 09:11:25 -0800

> On Dec 2, 2020, at 9:52 AM, Fernando Gont <[email-masked]> wrote:
> 
> ("can" = ability, "may" = possibility)

I tend to use "can" in the sense of capability, which may correspond to your word "ability". "May", however, is about permission. "You can get get hot water from the kitchen" indicates that hot water is to be found there, and that you have the capability of trotting off there - whether or not you're interested in hot water or have any desire to go to the kitchen. "You may get hot water from the kitchen" gives you permission to go to the kitchen for that purpose.

Note that this differs from colloquial usage. "Can" is often used in the sense of "may" in common usage ("can I please have some candy?" with the meaning "may I please...?"), which can be very confusing. In written communications, I try to keep theses straight.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2020 16:29:42 -0300

> Note that this differs from colloquial usage. "Can" is often used in the sense of "may" in common usage ("can I please have some candy?" with the meaning "may I please...?"), which can be very conf…

Thanks for the note! I will definitely go back to my grammar book and 
try to save everyone's time -- I do remember that the last year I took 
English lessons there was a unit about "need" vs "must" vs "have to" vs 
"may" vs "can" vs "might". I also remember another on "that" vs "which".
Definitely need to check both of these, since I've been getting both of 
them wrong lately :-(

Thanks for the help!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2020 16:32:36 -0300

[...]
> intermediate devices,

Yes, that's what I meant .- for the case of ECMP.

> need use the flow label nor transport port

Please see [Cunha-2020] ni our doc.

Thanks,

---

From: tom petch <[email-masked]>
Date: Fri, 4 Dec 2020 17:09:10 +0000

From: v6ops <[email-masked]> on behalf of Fernando Gont <[email-masked]>
Sent: 03 December 2020 19:29

<tp>

My pet hate is those who say something cannot be done when it patently can; they just do not want to say they will not do it.
You might want to add to your list 'e.g.' versus 'i.e.' a choice which does change the meaning and which I think is wrong in some I-D.  A statement that an option can be signalled by an IGP e.g. OSPF is very different to saying that an option can be signalled by an IGP i.e OSPF.   I came across one such earlier this week.

Tom Petch

Thanks for the help!

Regards,