Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 21 Nov 2019 03:32:25 +0000

Hello 6man Working Group.

This update has the following major changes:
1 - Revision 7 provided a normative definition of SRH insertion and removal.
2 - This rewrite shifts from the normative definition of SRH insertion within an SR Domain to a description of deployments of the same.
3 - Intended status has changed from proposed standard to informational.

Thanks,
  Darren, on behalf of the authors.

> On Nov 20, 2019, at 1:22 PM, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-voyer-6man-extension-header-insertion-08.txt
> has been successfully submitted by Darren Dukes and posted to the
> IETF repository.
> 
> Name:		draft-voyer-6man-extension-header-insertion
> Revision:	08
> Title:		Deployments With Insertion of IPv6 Segment
>    Routing Headers
> Document date:	2019-11-19
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-08.txt
> Status:         https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> Htmlized:       https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-08
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-08
> 
> Abstract:
>   SRv6 is deployed in multiple provider networks.
> 
>   This document describes the usage of SRH insertion and deletion
>   within the SR domain and how security and end-to-end integrity is
>   guaranteed.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2019 17:05:15 +1300

Darren,

Thanks for that, but it's unfortunate that there is effectively no time for us to read the draft before the discussion at the end of this afternoon. It clearly needs a complete re-read, not just a quick glance at the diffs.

Regards
   Brian Carpenter

On 21-Nov-19 16:32, Darren Dukes (ddukes) wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 21 Nov 2019 04:20:05 +0000

Hi Brian.  I acknowledge that the update is late for discussion on this version and it’s details.

Due to some WiFi issues my original email yesterday did not make it to the list. Apologies for that.

I do believe we can still have a valuable discussion on the topic, including the normative content of revision 7, and the now deployment focus of this revision.

Of coarse the most valuable and lasting input comes from your email comments to the list, which can come at any time, and are greatly appreciated.

Thanks
  Darren
________________________________
From: Brian E Carpenter <[email-masked]>
Sent: Thursday, November 21, 2019 12:05:15 PM
To: Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

Darren,

Regards
   Brian Carpenter

---

From: li zhenqiang <[email-masked]>
Date: Fri, 22 Nov 2019 01:23:57 +0000

Hello Darren,

Thank you for your presentation on this meeting.
Yesterday my clarification question from the jabber was as follow, I'm afraid I did't catch your response.
I want to make sure that the operators you mentioned in your sildes deployed SRH insertion not IPv6 header encapsulation. If so, please add the specific deployment scenarios in the companion deployment state report document.

Best Regards,
Zhenqiang Li
[email-masked]

From: Darren Dukes (ddukes)<mailto:[email-masked]>
Date: 2019-11-21 11:32
To: 6man<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt
Hello 6man Working Group.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Nov 2019 00:30:18 -0300

Hello, Darren,

> 3 - Intended status has changed from proposed standard to informational.

What's the rationale for this document being "Informational"?

Documenting how folks are breaking the spec?

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

---

From: Sander Steffann <[email-masked]>
Date: Fri, 22 Nov 2019 19:58:37 +0100

Hi,

> Documenting how folks are breaking the spec?

For that I think an Independent Submission is the only appropriate one. Anything in any IETF stream should either stick to existing specs or explicitly update them.

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Sat, 23 Nov 2019 11:23:49 +0100

> For that I think an Independent Submission is the only appropriate one. Anything in any IETF stream should either stick to existing specs or explicitly update them.

A whole session at the IETF meeting in Singapore was spent on the topic of header insertion in general and in the context of SR.
Progress was made.
I would encourage you to review that session.
Video recording is here: https://www.youtube.com/watch?v=ZJU0m1EhjaI

My reading of the working group session was to proceed work on both drafts. With neither draft updating RFC8200.

Let's focus on communicating and understanding the positions of each "camp" and proceed with the technical arguments.
I would discouarge "process arguments".
If you believe those are necessary, please take those with the chairs and AD and we can summarize to the group.

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Sat, 23 Nov 2019 12:01:34 -0800

Hi, a few comments:

>From the introduction:

"In each deployment, traffic traversing an SR domain is encapsulated
in an outer IPv6 header for its journey through the SR domain."

Is encapsulation a requirement of SR then?

"To implement transport services within the SR domain, insertion or
removal of an SRH after the outer IPv6 header is performed."

I'm missing something fundamental here. If a packet is already being
encapsulated on ingress into the SR domain then why is SRH insertion
necessary at all? The encapsulation could just be IPv6 header plus the
segment routing header. The outer header plus SRH is then
automatically removed at the destination endpoint (presumably the
egress node for the SR domain). That would be exactly the
"encapsulation" alternative to EH insertion and fully compliant with
RFC8200.

Section 2 seems irrelevant to the discussion. The implication of this
and some of the other wording in the document seem to be more about
accommodating how the protocol has been implemented, as opposed to
setting the requirements those implementations need to follow. IMO,
this section can be removed without loss of content.

I am very surprised that the draft doesn't at least reference RFC8200
given that it is always raised as the standard prohibiting EH
insertion. I would expect at least an acknowledgement of the
requirements and hopefully an explanation if this is to be an
exception to RFC8200 requirements.

Tom

---

From: Sander Steffann <[email-masked]>
Date: Sat, 23 Nov 2019 22:19:07 +0100

Hi Ole,

> My reading of the working group session was to proceed work on both drafts. With neither draft updating RFC8200.

Then let me state clearly on the list:
- I still object to EH insertion and do not consider the risks to be mitigated enough to drop my objection.
- I object to not updating RFC8200 in any RFC that contradicts its content. If EH insertion should be accepted by this WG despite the objections then implementers reading RFC8200 need to know that a conscious exception has been made. This will influence their understanding of the IPv6 protocol and its expected behaviour.

RFC8200 is very clear:

"""
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.
"""

There is no "except when defined otherwise" in that text.

> I would discouarge "process arguments".

I agree to this on the discussion about how harmful EH insertion can be. Let's start with draft-smith-6man-in-flight-eh-insertion-harmful and evaluate how draft-voyer-6man-extension-header-insertion deals with all the possible failure scenarios.

Regarding updating RFC8200, I definitely want to raise a "process argument".

> If you believe those are necessary, please take those with the chairs and AD and we can summarize to the group.

I hope the above is a good summary :)

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Nov 2019 12:59:25 +1300

Hi Sander,

> - I object to not updating RFC8200 in any RFC that contradicts its content. If EH insertion should be accepted by this WG despite the objections then implementers reading RFC8200 need to know that a conscious exception has been made.

So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for the Internet. I wouldn't object to adding an explicit statement of this to the draft, because that's also a true fact. But I would be very sad if the IETF is now against publishing factual information about actual practice that we are not willing to standardise, in line with https://tools.ietf.org/html/rfc2026#section-4.2.2 paragraph 2.

If we had standardised mechanisms for establishing limited domains, we could do better than that, but we aren't there yet.

Regards
   Brian Carpenter

---

From: Sander Steffann <[email-masked]>
Date: Sun, 24 Nov 2019 01:39:05 +0100

Hi,

> So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for…

My apologies, I was under the impression that this was intended for standards track. I won't object to publishing this as informational with the addition of that explicit statement.

Cheers,
Sander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Nov 2019 14:16:41 -0500

There is no reason I know of for the IETF to publish an RFC on the IETF 
stream that describes interesting ways that deployers have violated 
RFCs.  If the deployers want an RFC, the Independent Stream can be used 
to publish such things.  Particularly if the document actually describes 
meaningful values for there violation.

Yours,
Joel

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Nov 2019 21:01:31 +0000

I have to second this - because if this starts to happen on the standards track, what standard holds true?  I've seen much debate about not having multiple solutions to the same problem - and WG chairs trying to avoid that, however I would argue that it is far worse if we start publishing standards that contradict other standards - effectively creating standards that directly contradict each other.

I also agree that the independent stream would make a lot of sense in this case - but then again - maybe I'm missing something because I forgot to read an rfc somewhere

Andrew

From: ipv6 <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Sunday, 24 November 2019 22:17
To: Brian E Carpenter <[email-masked]>; Sander Steffann <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

Yours,
Joel

On 11/23/2019 6:59 PM, Brian E Carpenter wrote:
> So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for the Internet. I wouldn't object to adding an explicit statement of this to the draft, because that's also a true fact. But I would be very sad if the IETF is now against publishing factual information about actual practice that we are not willing to standardise, in line with https://tools.ietf.org/html/rfc2026#section-4.2.2<https://tools.ietf.org/html/rfc2026#section-4.2.2> paragraph 2.
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 25 Nov 2019 13:37:43 -0800

On Mon, Nov 25, 2019 at 1:01 PM Andrew Alston
<[email-masked]> wrote:
>
> I have to second this – because if this starts to happen on the standards track, what standard holds true?  I’ve seen much debate about not having multiple solutions to the same problem – and WG chairs trying to avoid that, however I would argue that it is far worse if we start publishing standards that contradict other standards – effectively creating standards that directly contradict each other.

Andrew, for an independent submission this contingency is covered by RFC4846:

"Any submission that constitutes an alternative to, or is in conflict
with, an IETF Standard or proposal for Standards-Track adoption must
clearly indicate that relationship."

I believe we've established that the draft is in conflict with
RFC8200, but I do not believe the relationship has been clearly
indicated.

Tom

>
>
>
> I also agree that the independent stream would make a lot of sense in this case – but then again – maybe I’m missing something because I forgot to read an rfc somewhere
>
>
>
> Andrew
>
>
>
>
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Nov 2019 21:41:52 +0000

Tom,

Agreed that its covered for independent submission – and if they do indicate that relationship, I’ve got no issues with an independent submission, and if I am reading the list correctly, that is what some of the others are saying as well – my issue here is on the standards track where you have something that conflicts directly – and is a publication of how someone is violating another rfc – that’s not a standard – and I don’t believe it belongs on the standards track.

Andrew

From: Tom Herbert <[email-masked]>
Sent: Tuesday, 26 November 2019 00:38
To: Andrew Alston <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; Brian E Carpenter <[email-masked]>; Sander Steffann <[email-masked]>; 6man <[email-masked]>
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

Tom

> From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
> To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
> Cc: 6man <[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 Nov 2019 22:56:30 +0100

Hi,

> Agreed that its covered for independent submission – and if they do indicate that relationship, I’ve got no issues with an independent submission, and if I am reading the list correctly, that is wh…

Agreed.
Sander

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Nov 2019 18:46:24 -0300

> Video recording is here: https://www.youtube.com/watch?v=ZJU0m1EhjaI

I will review the session. That said, in the context that "decisions are
made on the mailing-list", and in the hope of fairness, shouldn't the
list be polled in that respect?

> If you believe those are necessary, please take those with the chairs and AD and we can summarize to the group.

My basic question/comment about process is, particularly given the
amount of discussion that the topic has received on the list: why take
action on the topic on the meeting, without polling the list?

I'm also curious about the rationale of working on a document that
violates a core spec. It looks to me as "we didn't get consensus to
update the spec, so now we just document how we're ignoring the spec".
Given the history we have had on this topic, I don't see the process
(making a decision at the session without polling the list) nor the
outcome (essentially publishing a doc that violates the spec as
informational) as a sensible outcome.

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Tue, 26 Nov 2019 22:14:48 +0000

+1

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Andrew Alston
Sent: Monday, November 25, 2019 4:02 PM
To: Joel M. Halpern <[email-masked]>; Brian E Carpenter <[email-masked]>; Sander Steffann <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

Andrew

Yours,
Joel

On 11/23/2019 6:59 PM, Brian E Carpenter wrote:
> So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for the Internet. I wouldn't object to adding an explicit statement of this to the draft, because that's also a true fact. But I would be very sad if the IETF is now against publishing factual information about actual practice that we are not willing to standardise, in line with https://tools.ietf.org/html/rfc2026#section-4.2.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc2026*section-4.2.2__;Iw!8WoA6RjC81c!Xu1FIsYNuAh3YuMKP3Xjk_ge391rB0OcfEJYPJ7pHzyXE6nb69azbi6iYLdAMcui$> paragraph 2.
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!Xu1FIsYNuAh3YuMKP3Xjk_ge391rB0OcfEJYPJ7pHzyXE6nb69azbi6iYKKKYp26$>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!Xu1FIsYNuAh3YuMKP3Xjk_ge391rB0OcfEJYPJ7pHzyXE6nb69azbi6iYKKKYp26$>
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Nov 2019 19:35:46 -0300

> For that I think an Independent Submission is the only appropriate one. Anything in any IETF stream should either stick to existing specs or explicitly update them.

I'd be quite curious with 6man publishing a doc describing how folks are
violating a core spec (published by 6man with IETF-wide consensus) that
received such a strong push-back.

I'd assume such a document should either gain wg consensus, or it should
be published as "please don't do this".

In fact, I'm kind of surprised that we're even having this discussion.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 26 Nov 2019 20:00:59 -0500

> On Nov 26, 2019, at 5:35 PM, Fernando Gont <[email-masked]> wrote:
> 

I am in agreement with individual submission. 

Gyan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2019 14:19:18 +1300

On 27-Nov-19 14:00, Gyan Mishra wrote:
...
> I am in agreement with individual submission. 

Nobody has suggested an "individual submission" RFC, which means direct submission to the IESG for the IETF stream, sponsored by an AD.

The alternatives that have been suggested are 
1) WG Informational submission to the IETF stream.
2) Independent Submission (https://www.rfc-editor.org/about/independent/). Also see RFC 4846 and RFC 5744 if you are not familiar with the Independent Submission process.

Personally, I'm in favour of documenting reality, as this draft does, and as long as it's Informational I really don't care which RFC Stream is used.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 26 Nov 2019 18:01:07 -0800

On Tue, Nov 26, 2019 at 5:19 PM Brian E Carpenter
<[email-masked]> wrote:
> ....

Brian,

To me, this "reality" would be akin to acknowledging a serious bug but
simply marking it "will not fix" instead of actually fixing it. Both
the detrimental consequences of EH insertion and conformant
alternatives to it have been articulated several times on this list,
but we've seen little effort from the extension header insertion
proponents to take those into account or to work with WG to resolve
the issues.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2019 15:53:34 +1300

Hi Tom,
> proponents to take those into account or to work with WG to resolve

I don't think that's fair. The current version of the draft is utterly
different from the original, and the tone of the discussion at IETF 106
was constructive (http://ietf106.conf.meetecho.com/index.php/Recordings#6MAN_II).

The proposal by the WG chairs seems very balanced to me. Work on documenting
why header insertion that escapes a limited domain is harmful (Mark's draft)
and work on documenting existing practice in real products and real
networks. We often document existing practice, on the grounds that it's
better than ignoring it. That's what draft-voyer--08 does.

   Brian

---

From: Andrew Alston <[email-masked]>
Date: Wed, 27 Nov 2019 06:00:10 +0000

Hi Brian,

So - firstly - 
> was constructive 

Let's start here - before I get into the rest of it - if the replies to clarification questions that were made at the microphone during the presentation of this draft are classified as constructive, quite frankly, I need a new definition of the word constructive.  

But - now let me actually address that - specifically - I asked for clarification on the definition of an SR Domain - not because I had not read the rfc's - but because I now want to look very closely at what that definition says, what this draft says.

The definition that was later handed to me - which I had read before, and which was the basis for my question, came out of RFC8402 section 2, to writ:

Segment Routing domain (SR domain): the set of nodes participating in
   the source-based routing model.  These nodes may be connected to the
   same physical infrastructure (e.g., a Service Provider's network).
   They may as well be remotely connected to each other (e.g., an
   enterprise VPN or an overlay).  If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a network.  However, some deployments may wish to
   subdivide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR domain are managed by the same administrative entity.

What this does NOT say is that these networks HAVE to be connected in any way other than via the open internet.  It does not say that they have to be in the same autonomous system.  It gives no clarity about IGP areas and IGP boundaries.  And when considering header insertion - and the fact that under this definition, if a single entity (single administrative entity) owns disparate networks - this draft allows inflight header insertion that affects packets that flow over entities *NOT* within the SR domain - which - as clearly indicated by multiple individuals can cause significant headaches. (Irrespective of if the EH's are being processed by those third party systems)

I say this because there is absolutely nothing in the above that says that an SR domain has to be compromised of networks that are connected to each other - it says they may be.  It also says people may wish to sub-divide - again - not a requirement. 

Effectively - without a tighter definition of an sr-domain - this draft allows inflight header insertion for packets that will transverse things outside of the sr-domain so long as they are sourced from and destined within the same sr-domain where the domain is defined as network segments under the same administrative entity.

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Wed, 27 Nov 2019 06:56:21 +0000

I also have concerns about the fact that we are referring to consensus gained in the face to face meeting.

Does this not fly in the face of section 3.2 of RFC2418 - which states explicitly that that decisions reached during the face to to face meeting which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed by the mailing list?

As such, would it not be mandatory before advancing this document to poll this list for consensus as per 2418?

Thanks

Andrew

From: ipv6 <[email-masked]> On Behalf Of Fernando Gont
Sent: Wednesday, 27 November 2019 01:36
To: Sander Steffann <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 27 Nov 2019 09:47:56 -0500

Thanks for clarification on submission types.

I agree with any stream as well to be used since it’s informational and not standards track.

However WG informational still requires WG consensus on the verbiage in the document and agree to the contents of the document.

Gyan

Sent from my iPhone

> On Nov 26, 2019, at 8:19 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Nov 2019 10:11:05 -0800

Brian,

That's fine that it was a productive meeting and yes the draft has
improved, but as others have already pointed out real work and
decisions only happens on the list. We really need productive
discussion here.

> why header insertion that escapes a limited domain is harmful (Mark's draft)

I believe that mischaracterizes Mark's draft (I am also an author of
the draft). The message of that draft is that IPv6 extension header
insertion is harmful without qualification. Neither does RFC8200 have
any provisions or exceptions that would change the behavior or
requirements on the basis of the environment the protocol is run. For
instance, the loss of attribution of packet contents to the source,
which is fundamental to IP protocols, is not resolved by restricting
use to a limited domain.

> networks.

Okay, but if the WG is going to work on this, doesn't that mean it
needs to be Working Group item? Will there be a call working group
adoption on the list?

> We often document existing practice, on the grounds that it's

We definitely have not been ignoring this! There has been substantial
feedback already on various versions of the draft.

Tom

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 Nov 2019 13:35:24 -0500

Hi Andrew and Fernando,

> On Nov 27, 2019, at 1:56 AM, Andrew Alston <[email-masked]> wrote:
> 
> Does this not fly in the face of section 3.2 of RFC2418 – which states explicitly that that decisions reached during the face to to face meeting which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed by the mailing list?
>  

Absolutely. Your understanding is correct. Before adopting a document, the decision has to be confirmed on the mailing list. But, as of now, there has not been a formal adoption call started for either draft-voyer or draft-smith. 

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2019 08:40:01 +1300

On 28-Nov-19 07:11, Tom Herbert wrote:
> the draft). 

Ah, sorry, yes!

> The message of that draft is that IPv6 extension header
> insertion is harmful without qualification.

But... what happens in a limited domain stays in the limited domain.
Basically neither the IETF nor anybody else can even know about
strange things that occur entirely within a domain. The message I
get from your draft is that there can only be harm to third parties
if a munged packet escapes.

> Neither does RFC8200 have

Correct. But maybe the operator doesn't care if an ICMP error is
reported to the originator of the packet without any ability to
identify the header-inserting node. (That's an issue I'd expect
draft-voyer to discuss, which it doesn't at the moment.)

> needs to be Working Group item? Will there be a call working group

Suresh answered that.
 
> feedback already on various versions of the draft.

Indeed, and I didn't conceal my dislike of the early versions. I'm also
strongly in favour of draft-smith. My concern is more that we shouldn't
repeat the IETF's mistake over NAT44 (pretending it wasn't there for years,
and finally producing RFCs in catch-up mode).

On a broader note, extension headers should be one of IPv6's main selling
points. We need to figure out how to make them more usable than they
currently are.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2019 10:58:44 +1300

Hi Andrew,

On 27-Nov-19 19:00, Andrew Alston wrote:
> What this does NOT say is that these networks HAVE to be connected in any way other than via the open internet.

That's so strongly implied that it never occurred to me that it needs to be stated explicitly, but it would certainly do no harm. (More below.)

> It does not say that they have to be in the same autonomous system.

Why is that relevant? If an operator has two ASes that happen to be connected by SR-aware routers, what is the problem?

> It gives no clarity about IGP areas and IGP boundaries.

Again, I don't see the relevance. It's the SR-aware to non-SR-aware boundary that matters.

> And when considering header insertion - and the fact that under this definition, if a single entity (single administrative entity) owns disparate networks - this draft allows inflight header insertion that affects packets that flow over entities *NOT* within the SR domain - which - as clearly indicated by multiple individuals can cause significant headaches. (Irrespective of if the EH's are being processed by those third party systems)
> 

My understanding is that this could only happen if the SR domain was itself a VPN, so the SR packets would be payload as far as the non-SR routers were concerned, and hence not problematic. Certainly the "open Internet" scenario needs to be excluded. (Apart from anything else, the Internet is partially opaque to extension headers [RFC7872], so it won't work anyway in the general case.)

I agree that the definition of "SR domain" could be clarified further; in fact Darren Dukes and I spent some time discussing the domain boundary last Friday after the IETF ended.

Regards
    Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Nov 2019 17:46:23 -0800

On Wed, Nov 27, 2019, 11:40 AM Brian E Carpenter <
[email-masked]> wrote:

> >>>> Nobody has suggested an "individual submission" RFC, which means
> direct submission to the IESG for the IETF stream, sponsored by an AD.
> >>>>
> >>>> 2) Independent Submission (
> https://www.rfc-editor.org/about/independent/). Also see RFC 4846 and RFC
> 5744 if you are not familiar with the Independent Submission process.
> >>>>
> >>>> Personally, I'm in favour of documenting reality, as this draft does,
> and as long as it's Informational I really don't care which RFC Stream is
> used.
> >>>
> >>> Brian,
> >>>
> >> was constructive (
> http://ietf106.conf.meetecho.com/index.php/Recordings#6MAN_II).
> >>
> >
> > Brian,
> >

That implies that they're not usable as defined. Do you have an idea on
what might be done to change that?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2019 15:41:38 +1300

Tom,

On 28-Nov-19 14:46, Tom Herbert wrote:
> 
> 
> On Wed, Nov 27, 2019, 11:40 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
...
> That implies that they're not usable as defined. Do you have an idea on what might be done to change that?

As I experienced years ago when my Ph.D. student was making real-world experiments with SHIM6, and as RFC7872 reported too, it's an observed fact that the Internet isn't transparent to packets with extension headers, not even to currently standardised ones. The same appears to have been true for IPv4 Options for at least 25 years. So, to be honest, I have no idea how to change that for the open Internet. We seem to be stuck with a lowest common denominator network layer.

My other thoughts on this topic are in https://tools.ietf.org/html/draft-carpenter-limited-domains-11.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 28 Nov 2019 03:34:02 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

> As I experienced years ago when my Ph.D. student was making real-world experiments with SHIM6, and as RFC7872 reported too, it's an observed fact that the Internet isn't transparent to packets with…

Isn't the problem that routers must mostly not mess with these extension headers? Even hop-by-hop headers can be ignored by routers (unless specifically configured not to ignore)?

So, you have a layer 3 extension option, but the boxes which do the heavy lifting at layer 3 must never mess with. On the other hand, end systems, which can play with IP extension headers, have virtually no knowledge of the network topology details.

Router manufacturers seem to prefer the simplest possible routing mechanization. Hosts don't typically have a clue how best to use the knob. My impression has always been that people are as discouraged to use layer 3 extension headers, as they are to use packet fragmentation. One of those things you want to avoid, unless you're a glutton for punishment? Not so?

Happy Thanksgiving, for those to whom this applies.

Bert

---

From: Andrew Alston <[email-masked]>
Date: Thu, 28 Nov 2019 03:41:02 +0000

Hi Brian,

> My understanding is that this could only happen if the SR domain was itself a
> VPN, so the SR packets would be payload as far as the non-SR routers were
> concerned, and hence not problematic. Certainly the "open Internet"
> scenario needs to be excluded. (Apart from anything else, the Internet is
> partially opaque to extension headers [RFC7872], so it won't work anyway in
> the general case.)

The observations in RFC7872 are interesting - though I must note that in tests we did recently - and I've since conducted subsequent tests with other networks, we found a surprising lack of drops of packets with extension headers.  As a stated on the spring list, in a test of CRH [draft-bonica-6man-comp-rtg-hdr-09] we were able to steer across multiple nodes in our own network, out across the open internet, into another network, and then fairly deeply into the other network.   The packets were sourced from Kenya and destined for the netherlands and we were passing through multiple asn's that had no knowledge CRH or anything to do with the test we were running.  I've since completed similar tests to other networks, again, not connected, in various parts of the world - and maybe I've just been lucky, but to my surprise every test run so far has been 100% successful.  Now, I am NOT disputing that there are networks out there that may be dropping packets with extension headers - I just need to clarify that in the tests we've done so far - its not a behavior that I have seen, hence, I have to wonder how common this is.  It may be well worth re-conducting the research done in RFC7872 and see just how much the situation described in that document still holds true 3 and a half years later when the v6 adoption on the internet has advanced and become slightly more mature (not nearly as much advancement as I'd like, but things have changed)

Btw - if anyone on this list is interested in conducting some research and potentially publishing an update to RFC7872 in some form - please contact me - I'd be happy to put some resource into this - its useful data.

> 
> I agree that the definition of "SR domain" could be clarified further; in fact
> Darren Dukes and I spent some time discussing the domain boundary last
> Friday after the IETF ended.
> 

And this Brian is my entire point - I to spoke to various people about the definition of an SR domain following the incident that occurred in 6man and being told to read an rfc I had read, in an effort to understand if perhaps I was just being dense, or if that current definition was fairly open to interpretation, since as you say, there are implications, but what is implied and what is stated explicitly are far from the same thing.    The understandings and interpretations of what an SR domain were - came back surprisingly varied - or in the words of one individual - "I asked that two  years ago, I still have no idea as to the real answer".
Basically what I am saying is - when we are facing an issue where a draft document wishes to openly and without apology announce violations of a published RFC arrived at by community consensus, and furthermore, advocate for further violations of said RFC, while I have very strong problems with this - in the absence of updating the original document - at the very minimum, it is prudent to ensure there is no ambiguity about the conditions under which such blatant violations occur.  Right now - with that definition as it stands - there is a LOT of ambiguity and a lot is open to interpretation.  Lack of clarity and leaving things open to interpretation - leads to breakage - leads to incompatibility - and leads to operational headaches.

Thanks

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2019 17:27:45 +1300

Hi Bert,
On 28-Nov-19 16:34, Manfredi (US), Albert E wrote:
> Isn't the problem that routers must mostly not mess with these extension headers?

"Mostly" isn't good enough. It needs to be 100%. It only takes one router or middlebox on the path to be allergic to extension headers, and that's what we see in practice.

   Brian

> Even hop-by-hop headers can be ignored by routers (unless specifically configured not to ignore)?
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Nov 2019 07:46:44 +0000

> "Mostly" isn't good enough. It needs to be 100%. It only takes one router or middlebox on the path to be allergic to extension headers, and that's what we see in practice.

In RFC 7872 we tried to determine where the drops were happening, on a “best case” / “worst case” basis, whether it was in the destination AS or a transit AS.

We also tested against Alexa Top N targets for www, dns and mx, where perhaps Andrew’s tests were between end systems that were more “cooperative” across intermediate open / transit networks, so his values would be more akin to the “best case” numbers.

Certainly not a bad time to re-run tests, and maybe run tests between co-operative end points/domains.  Nearly 4 years have passed since the RFC7872 tests were run.  How much have things changed?

Tim

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Nov 2019 12:03:01 +0100

> Certainly not a bad time to re-run tests, and maybe run tests between co-operative end points/domains.  Nearly 4 years have passed since the RFC7872 tests were run.  How much have things changed?

RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.
The document offers little with regards to the deployment of extension headers within a limited _network_ domain.

I'm all in support for continuing monitoring and testing. Testing the "right thing"(tm) and understanding the results is a discipline on its own. If there is any learning that I can take from 7872, is that the RFC format isn't the right channel for measurement results.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Nov 2019 11:13:03 +0000

> On 28 Nov 2019, at 11:03, Ole Troan <[email-masked]> wrote:
> 

No, but it makes it clear the tests are run across the Internet and transit ASes, and has some methodology to try to detect where the drops are happening.   Readers can draw their own conclusions.  The measurements showed clear issues in transit networks.  Specific / limited domains can of course to some extent do as they please; the issue is if such behaviour leaks.

> I'm all in support for continuing monitoring and testing. Testing the "right thing"(tm) and understanding the results is a discipline on its own. If there is any learning that I can take from 7872,…

Well, there was WG consensus both to adopt and publish it.  If someone conducts new tests, and perhaps takes your comments more on board, then I’d still support them being published via v6ops - it’s v6 operations after all.

Tim

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Nov 2019 12:25:48 +0100

> No, but it makes it clear the tests are run across the Internet and transit ASes, and has some methodology to try to detect where the drops are happening.   Readers can draw their own conclusions.…

The way the numbers are represented in that document, makes it way too easy for a casual reader to draw the wrong conclusions.
Which also affects how we in the IETF perceive what we can do with EHs.

> Well, there was WG consensus both to adopt and publish it.  If someone conducts new tests, and perhaps takes your comments more on board, then I’d still support them being published via v6ops - it’…

Indeed, somewhat flippantly; there's very little there isn't WG consensus for in v6ops.

Cheers,
Ole

---

From: Enno Rey <[email-masked]>
Date: Thu, 28 Nov 2019 14:37:39 +0100

Hi,

> The way the numbers are represented in that document, makes it way too easy for a casual reader to draw the wrong conclusions.

The document documents real-world results from real-world measurements. This shouldn't leave much room for conclusions, as in "it it what it is" (measured by experiment and documented here). Packets with extension headers get dropped in real-life and at least I for one assume this happens for a reason. I generally assume operators and sysadmins have a clue, and reasons for their actions. I for one also don't assume clueless readers who easily take wrong conclusions.

> Which also affects how we in the IETF perceive what we can do with EHs.

I sincerely hope it does. Afai remember that was one of the reasons why the authors of that document spent significant effort on documenting real-world behavior.
(I leave adding "as opposed to wishful thinking" to the potentially clueless reader...)

> > Well, there was WG consensus both to adopt and publish it.  If someone conducts new tests, and perhaps takes your comments more on board, then I???d still support them being published via v6ops - it???s v6 operations after all.
> 

In all respect that is a very funny statement of a chair of a WG that right now seems to have a fervent discussion about 'manifesting consensus'.

cheers

Enno

-- 
Enno Rey

Twitter: @Enno_Insinuator

---

From: Enno Rey <[email-masked]>
Date: Thu, 28 Nov 2019 14:49:45 +0100

Hi,

> RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.

isn't IPv6 supposed to be an end-to-end protocol?
Based on that assumption pretty much all IPv6 stacks of operating systems implement full processing capabilities for the full set of extension headers as of RFC 8200.

Fully serious question: which guidance re: the implementation of an IPv6 stack, plus its capabilities, would you suggest to read & follow for a party working on an IPv6 stack used on a billion devices? I know a few people who would be very interested in a response here. I could imagine they might even be happy to get rid of all the code taking care of EHs right now.

Maybe there should be an IPv6 variant for routers, and one for end-points in the future? 
This could also allow for a 6man sub-WG for routers. Oh wait, in reality it already is. 
That fictional router-oriented 6man sub-WG could then be populated mainly by folks from router vendors. Oh wait...

cheers

Enno

-- 
Enno Rey

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Nov 2019 15:04:45 +0100

> The document documents real-world results from real-world measurements. This shouldn't leave much room for conclusions, as in "it it what it is" (measured by experiment and documented here). Packet…

Which I think only proves that one should be very careful about using the incarnation the "real-world". Or pretend that one has the true interpretation of what actully does happen in the "real world", as if there is ever a single answer to that.

Testing methodology and interpretation of the results is hard. If we are not careful this doesn't amount to more than anecdotal data.
If Andrew had read that document before running his SR/CRH experiment, he would have probably not bothered trying.

There is a chicken and egg issue with regards to EHs. And there is a difference in how they are handled, and should be handled by the network versus the end-host/service.
We'd expect the transit network, with the exception of HBH to pass the EHs through unharmed. The network edge might be assumed to know more about what services is available on the inside, and might filter.
E.g. a TCP based service clamped to MSS 1240. Why would you think that should accept packets with the FH?
Or in general, if you send a set of DH options to a host, why do you think it should blindly process those packets?
Until there are actual deployed services using those, and they are explicitly enabled on the hosts, then you will get a lot of false negatives with the sort of testing that was done in this document.

Ole

---

From: Enno Rey <[email-masked]>
Date: Thu, 28 Nov 2019 15:24:31 +0100

Hi,

> Or in general, if you send a set of DH options to a host, why do you think it should blindly process those packets?

iirc the DestOptions packets sent as part of the experiments being the basis for RFC 7872 were sent with PadN options. As for those RFC 8200 states:
"These padding options must be recognized by
   all IPv6 implementations"

There's a somewhat ironic element here. 
Pretty much all IPv6 implementations I know (and the people actually coding them, at least as far as I know that group) take RFC 8200 (or 2460, in those days) as a basis for specific implementation decisions.
RFC 8200 - from my reading - somewhat invokes an 'universal notion of IPv6 extension headers'. So far the theory.
Now actual experiments (from, as a look at the list of authors of RFC 7872 implies, people with a lot of knowledge re: IPv6 and, more importantly, operating experience from some very large networks) show that said 'universal notion' seems flawed (for whatever reasons). So far the practice.
And to question the results of those experiments the question is asked: "why was there an expectation that real-life systems process those packets"?

cheers

Enno

-- 
Enno Rey

Cell: +49 173 6745902

---

From: Enno Rey <[email-masked]>
Date: Thu, 28 Nov 2019 15:42:53 +0100

Hi,

On Thu, Nov 28, 2019 at 03:04:45PM +0100, Ole Troan wrote:

> then you will get a lot of false negatives with the sort of testing that was done in this document.

Geoff Huston performed measurements on fragmentation (hence packets using at least one EH), as documented here:
https://ripe78.ripe.net/presentations/41-2019-05-23-ipv6-fail.pdf (see the last slides).

So at least one other set of experiments seems to indicate issues which might be related.

Also my understanding of the IETF is that it is a very open forum for everybody (even those without budget for f2f meetings), so I'd think that any person with more clue re: testing methodologies or how-to-interpret results could come up with better data, as a basis for a successor of 7872.
I personally know of at least one large vendor with a lab for such experiments in Paris. I'm fairly confident said vendor might even have budget to send people to f2f meetings.

>From an IPv6 practitioners' perspective I'd be very happy to see more up-to-date numbers as for IPv6  EH handling in 'the Internet'. I could use those to re-think the advice I give in my own sphere of influence as for the handling of EHs.

cheers

Enno

-- 
Enno Rey

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Nov 2019 15:49:03 +0100

In your letter dated Thu, 28 Nov 2019 15:24:31 +0100 you wrote:
>iirc the DestOptions packets sent as part of the experiments being the basis f
>or RFC 7872 were sent with PadN options. As for those RFC 8200 states:

There is a long standing practice in firewall design of throwing out
everything you don't need.

Obviously, that has significant negative effects on how internet protocols
can evolve. But I can also understand the need to have a secure system and
not wait for hardly used options to be used as an attack vector.

And, if a single firewall has to protect a collection of hosts, then parsing
all possible combinations of extension headers at wire speed may also be
an issue. Is it worth investing in such capabilities if all packets you
actually expect have no extension headers at all?

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Nov 2019 15:02:02 +0000

Hi,

> On 28 Nov 2019, at 14:42, Enno Rey <[email-masked]> wrote:
> 
> Hi,
> 

Indeed. And there are others.

> I personally know of at least one large vendor with a lab for such experiments in Paris. I'm fairly confident said vendor might even have budget to send people to f2f meetings.

As an author of 7872, I’d welcome renewed tests, which may also use a renewed methodology.  

I don’t agree with Ole’s comments about the way the results were presented.  At the time there was a good majority of people in favour of documenting the issue, and a small number rather more strongly opposed to doing so.  That opposition iirc led to a separate draft documenting *why* drops happened, which may have originally been within the 7872 draft (I don’t remember)  being dropped.   That’s a separate interesting topic :)

>> From an IPv6 practitioners' perspective I'd be very happy to see more up-to-date numbers as for IPv6  EH handling in 'the Internet'. I could use those to re-think the advice I give in my own spher…

Best wishes,
Tim

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Nov 2019 08:41:08 -0800

Brian,

That is the crux of the problem: if deployment of some protocol
requires 100% compatibility with every node the network, then it's
impossible to ever deploy any new protocols. There is no such thing as
100% support for pretty much anything other then maybe TCP/IPv4
without IP options. This is true on the Internet, but also true in
even moderately large closed networks. For instance, a sprawling
closed network like Google or Facebook doesn't have "flag days" to
push new support for new protocols to all nodes. IPv6 had to be rolled
out incrementally for example.

So the problem is how do we deploy protocols that aren't necessarily
supported across all possible paths. I think the answer is already
known: if we have a priori knowledge that some path supports a
protocol then use the protocol, if the particular path doesn't support
a protocol then don't use it and fall back to a degenerative protocol
more likely to be palatable. There are several examples of this
technique: Happy Eyeballs for IPv6, QUIC fallback to TCP, UDP DNS
fallback to TCP DNS, etc.

So then the question becomes how does a source node determine the
protocols supported for the destination it wants to reach? This can be
done with probing, configuration, or maybe a mashup map (if you want
to say that the set of ad hoc destinations that support a particular
protocol form a "limited domain" then sure). The map idea is
compelling, for instance if the data from RFC7872 was published as the
list destinations that are known to properly handle EH instead of just
rolled up statistics, then a node wishing to us EH could query the
database to see if a desired destination is usable for EH. Of course,
for that model to be practical we'd want the map to be updated in real
time based user experience hence the mashup attribute. The map of the
Internet would have the added benefit of providing a public report of
what difference service providers are supporting and hence users can
make informed decisions when choosing a provider (i.e. incentive for
providers to keep up with conformant protocol support).

Tom

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 28 Nov 2019 20:47:39 +0100 (CET)

> fallback to TCP DNS, etc.

Those are all mechanisms deployed by hosts, where the probing of
failure or success can be done with some reliability.  If I've
understood correctly, what we're talking about instead is routers
along the path messing with the IPv6 packet in non-standard ways,
and the router which did the messing doesn't under normal
circumstances get the same signal hosts do when a host connection
carried over this path either fails or succeeds.

Regards,

- Håvard

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Nov 2019 12:10:24 -0800

I’m using my phone for email, so fancy selection of text isn’t very practical. However, it seems to me that a lot of the confusion in the thread (and the document?) relates to assumptions made by various speakers - “an SR domain is [or is not] bounded by AS boundaries” and so on.

I would suggest that it be clearly stated, not in terms of the operator of the equipment, but the configurations of the routers in question. Something like “a packet containing an SR header may only traverse routers that are consistently configured for segment routing.” Wordsmith to taste. The point is that if it ever finds itself in a router that is implemented or configured differently (whether or not it’s in the same AS or etc), it has left that SR domain. Note that it may be in a different SR domain...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Nov 2019 11:06:27 +1300

On 29-Nov-19 00:03, Ole Troan wrote:
...> RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.

I don't think so. The extension header mechanism was designed on a "consenting adults" model where all that matters is that both end points support a particular header type. (With two exceptions: the fragment header and the hop-by-hop options header, which are both significant en route. The routing header is *not* an exception to that model.) RFC7872 might be construed as testing whether that model is viable, but it doesn't imply any particular belief about end systems afaik.

> The document offers little with regards to the deployment of extension headers within a limited _network_ domain.

Indeed not; why should it, since it was measuring the open Internet?
> 
> I'm all in support for continuing monitoring and testing. 

Yes.

> Testing the "right thing"(tm) and understanding the results is a discipline on its own. If there is any learning that I can take from 7872, is that the RFC format isn't the right channel for measurement results.

There are specialised conferences or conference streams for measurement stuff, where there is also specialised peer review. Personally I don't care where the results are published, as long as we can all see them.

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 29 Nov 2019 09:06:17 +0100

Brian,

> On 28 Nov 2019, at 23:06, Brian E Carpenter <[email-masked]> wrote:
> 

The belief in the document is that what you get from Alexa's list of web sites will give you an address of a fully compliant IPv6 system. And that it will support:

   o IPv6 packets with a Destination Options header of 8 bytes;

   o  IPv6 packets resulting in two IPv6 fragments of 512 bytes each
      (approximately); and

   o  IPv6 packets with a Hop-by-Hop Options header of 8 bytes.

The IP address you get back from an AAAA query of the Alexa list is rarely an IPv6 host. The IP address represents an abstract service point.
There is a fairly complicated set of infrastructure behind that IP addresss. Load balancers, NATs, NAT64s etc.
But the point is that the service profile is known in the infrastructure.

And if there are no valid use case for any packet with a DH, FH or HBH. Why would you think that an operator of such a service should not drop those packets on the floor?
That's the flawed assumption in this document.

HBH is different, as a router punt flag. RFC7872 essentially asks "if we ever came up with a useful HBH option, how would it fare in the Internet?". One would expect numbers to be skewed since no Internet deployable HBH option existed at the point of measurement.
There are improvements in RFC8200 and I'd believe most old boxes that had serious problems with HBH are largely phased out. And we for the first time have an Internet wide HBH option defined (PMTUD). Gorry et al is running measurements of that now. And I believe he has already found some ASs that block HBH.

Cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Fri, 29 Nov 2019 08:20:37 +0000

> On 29 Nov 2019, at 08:06, Ole Troan <[email-masked]> wrote:
> 
> Brian,
> 

Well, no, that’s why the document notes that point and makes an attempt to determine if the drop is in a transit network or the end site network.  

> There are improvements in RFC8200 and I'd believe most old boxes that had serious problems with HBH are largely phased out. And we for the first time have an Internet wide HBH option defined (PMTUD…

Which again is why new measurements would be welcome.  Some are already happening.  I have been speaking to Gorry and we (the network I work for) are hosting one of the systems doing those measurements.

Tim