Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2020 10:14:01 +1200

Hi,

IMHO this is useful work.

> A number of recent RFCs have discussed issues related to IPv6 extension headers,

I suggest to add RFC7045 to the bullet list, and delete the reference to it
in the previous paragraph. In fact, the structure of the "Previous Work"
section is a bit strange, with a prose paragraph followed by a bullet list.
Maybe restructure that (e.g. transform it into a single longer bullet list)?

Regards
   Brian

On 26-Jul-20 17:28, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Operational Implications of IPv6 Packets with Extension Headers
>         Authors         : Fernando Gont
>                           Nick Hilliard
>                           Gert Doering
>                           Warren Kumari
>                           Geoff Huston
> 	Filename        : draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> 	Pages           : 15
> 	Date            : 2020-07-25
> 
> Abstract:
>    This document summarizes the security and operational implications of
>    IPv6 extension headers, and attempts to analyze reasons why packets
>    with IPv6 extension headers may be dropped in the public Internet.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 27 Jul 2020 06:47:02 +0000

Hi,
I read this draft and think it is a useful work.
I have two suggestions below:

1. Section 4 describes the challenge of "packet filtering mechanisms that require upper-layer information".
Some similar need for "packet filtering mechanisms that require EH information" has also been seen recently in IETF.
That may face the same challenge, and may need to be taken into consideration in this document.

2. Section 5.1.3 gives two examples to illustrate the requirement of "Deep ACL" on the "infrastructure address". 
Very good observation IMO, and I think some of the latest IETF practice may be useful for citing in this document.
RFC8754 section 5.1 separates a "programmable infrastructure address block" from the normal "infrastructure address", and thus makes a good solution to this "differentiation" requirements --
Deny the ICMP/BGP/etc traffic toward the "programmable infrastructure address block ", but no impact on existing rules to permit the ICMP/BGP/etc traffic toward to the normal "infrastructure address".

Thanks
Jingrong Xie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, July 27, 2020 6:14 AM
To: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt

Hi,

> A number of recent RFCs have discussed issues related to IPv6 

I suggest to add RFC7045 to the bullet list, and delete the reference to it in the previous paragraph. In fact, the structure of the "Previous Work"
section is a bit strange, with a prose paragraph followed by a bullet list.
Maybe restructure that (e.g. transform it into a single longer bullet list)?

Regards
   Brian

On 26-Jul-20 17:28, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jul 2020 03:49:49 -0300

> Maybe restructure that (e.g. transform it into a single longer bullet list)?

That's a good point.

I wonder if we could somehow separate:
* Std work that has become incorporated into the core spec.

* Other Std work that affects EHs but hasn't been incorporated into the 
core spec (e.g., RFC6980)

BTW... it seems that RFC7045 has not really been incorporated into 
RFC8200?   I mean, other work (e.g. RFC6946 has been incorporated into 
RFC8200, and currently their raison d'etre is mostly for the reader to 
find additional information -- but from the pov of RFC8200 is not really 
necessary to read RFC6946). OTOH, it would seem that RFC7045 still 
applies to RFC8200 in the very same way it applies/applied to RFC2460?
So in a way it should be in the bulleted list, but otoh it doesn't seem 
to have been incorporated into RFC8200 -- while it still applies to it?

Modulo RFC6980 (and RFC7045), it would seem that the first para (prose) 
could also be arranged as a set of bullets, noting something along the 
lines of "documents that discuss operational implications of EHs"?

And I guess we could also arrange the measurements stuff (last para) in 
their own set of bullets?

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jul 2020 08:51:51 +1200

> core spec (e.g., RFC6980)

Sure, if binary separation is really possible.

> RFC8200?   

Well, yes and no. Firstly the point about HbH header processing
being essentially optional was adopted.  Similarly, RFC7045 says
"This document updates RFC 2460 to
clarify how intermediate nodes should deal with such extension
headers and with any that are defined in the future."
and that, I believe, is reflected in RFC8200.

The other new thing in RFC7045 was the IANA restructuring of
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
That was not moved into RFC8200, and IANA still uses RFC7045 as the
primary reference. So I think it's appropriate that RFC8200 doesn't
obsolete RFC7045. You are correct that it is still relevant, but I'm
not sure there is any need for RFC7045bis.

We could have a long discussion about refactoring the IPv6 document
set in some way, but I'm not sure there's any value in that either.
Frequent updates of "Node Requirements" is another thing we could
discuss...

> I mean, other work (e.g. RFC6946 has been incorporated into 

Yes.

> their own set of bullets?

A uniform structure would certainly be easier to read.

Regards
     Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Jul 2020 15:32:15 +0100

Hi,

> On 27 Jul 2020, at 21:51, Brian E Carpenter <[email-masked]> wrote:
> 

It may be worth pointing out that RFC 7045 was included in the IPv6 Node Requirements - bis work and thus into RFC 8504, with the “nodes SHOULD forward packets regardless of EHs present” text repeated there.

EH-related requirements in RFC 8504 are explicitly covered in https://tools.ietf.org/html/rfc8504#section-5.2.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Jul 2020 04:58:59 -0300

Hi, Tim,

On 28/7/20 11:32, Tim Chown wrote:
> It may be worth pointing out that RFC 7045 was included in the IPv6 Node Requirements

Maybe we can tweak the text to say something along the lines of:
"  A number of recent RFCs have discussed issues related to IPv6
    extension headers, specifying updates to a previous revision of the
    IPv6 standard ([RFC2460]), most of which have now been incorporated
    into the current IPv6 core standard ([RFC8200]) or the IPv6 Node
    Requirements [RFC8504]).  Namely,"
.
.

?

> - bis work and thus into RFC 8504, with the “nodes SHOULD forward packets regardless of EHs present” text repeated there.
> 

By the way, our working copy says:

"[RFC8504] specifies processing rules for packets with extension 
headers, and also allows hosts to enforce limits on the number of 
options included in IPv6 EHs."

Maybe we should say s/specifies/clarifies/ ?

FWIW, I don't mind noting “nodes SHOULD forward packets regardless of 
EHs present”, but in a way wouldn't that misrepresent both RFC8504 and 
RFC7045 a bit, which essentially elaborate on the caveats for the SHOULD 
(and hence are way more than to eartg that RFC8200).

Thoughts?

Thanks!

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Jul 2020 09:37:07 +0100

Inline...

> On 29 Jul 2020, at 08:58, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Tim,
> 

Maybe.  RFC8504 largely assembles text from elsewhere, e.g., from RFC8200, but there are some examples where it adds more that isn’t said in another RFC.

> "[RFC8504] specifies processing rules for packets with extension headers, and also allows hosts to enforce limits on the number of options included in IPv6 EHs."
> 

And this is one example of adding more.  I believe the text about such limits was put forward for section 5.3 of RFC8504 by Tom Herbert, and there was good agreement to include this text.  Ideally it might be in a separate document, to which RFC8504-bis refers one day. 

> FWIW, I don't mind noting “nodes SHOULD forward packets regardless of EHs present”, but in a way wouldn't that misrepresent both RFC8504 and RFC7045 a bit, which essentially elaborate on the caveats for the SHOULD (and hence are way more than to eartg that RFC8200).

What is included in Section 5.2 of RFC8504 on this subject is simply:

"  Further, [RFC7045] adds specific requirements for the processing of
   extension headers, in particular that any forwarding node along an
   IPv6 packet's path, which forwards the packet for any reason, SHOULD
   do so regardless of any extension headers that are present.”

The more specific notes on this are in Section 2.1 of RFC7045, so I’d point to that as the authoritative source of the "SHOULD forward regardless” guidance.   The subsequent words there about what firewalls SHOULD do perhaps flies in the face of what vendors include by default and operational practice though?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jul 2020 11:58:54 +1200

Comment right at the end...

> The more specific notes on this are in Section 2.1 of RFC7045, so I’d point to that as the authoritative source of the "SHOULD forward regardless” guidance.   The subsequent words there about what…

Well yes, and that's the problem. Whether it's a problem in the real world or in the RFC dream world is a separate question. The fact is that real-world firewalls have not been dseigned to do their job properly at line speed when a variety of extension headers is present.

    Brian