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

From: Fred Baker <[email-masked]>
Date: Sun, 1 Dec 2019 15:27:22 -0800

> On Nov 27, 2019, at 7:41 PM, Andrew Alston <[email-masked]> wrote:
> 
> 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.

The obvious persons to do so are the authors of RFC 7872.

Part of this might be the particulars of the equipment traversed. The paths that were mentioned crossed some ancient gear that had clipped a few corners in implementation. In the discussion, that was mentioned and considered relevant.

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Dec 2019 12:49:35 +1100

> Part of this might be the particulars of the equipment traversed. The paths that were mentioned crossed some ancient gear that had clipped a few corners in implementation. In the discussion, that w…

I think RFC 7872 is and has been useful, however I don't think the
general conclusion from it can be that EHs aren't carried over the
Internet. It only tested the Dest Options, HbH and Fragment Header
EHs.

AH and ESP EHs would be interesting to test. According to this
presentation from IETF 88, Xbox uses IPsec over IPv6 for direct
peer-to-peer connections between Xbox Ones. Microsoft are probably
measuring how successful that is so that could be some useful data if
they're willing to supply it.

"Xbox One: P2P IPv6, Teredo, and IPsec'
https://datatracker.ietf.org/meeting/88/materials/slides-88-v6ops-0

One way I think of IPsec is that it is enforcing the end-to-end
Internet transparency that should exist without the need to resort to
IPsec. A mitigation to send Dest Options through a transit network
that is blocking DO should be to wrap the DO in IPsec. If a "transit
AS" is dropping AH and/or ESP, then it actively isn't actually
providing transit.

I think transport layer headers are technically EHs too as they come
from the same number space. I think another useful test would be to
see how successful sending DCCP and SCTP over the IPv6 Internet is.

Regards,
Mark.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Dec 2019 02:57:53 -0300

On 23/11/19 20:59, Brian E Carpenter wrote:
[....]
> 
>> - 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. 
I believe that for what's one way or another a protocol spec, there has
to be a limit with respect to what the IETF publishes. Otherwise,
particularly when it comes to outsiders, it will become much harder to
"consume" RFCs.

Particularly when it comes to vendors (and even more when it comes to
big ones), which tend to be well-represented, one would expect that they
play more by the rules, bring ideas, and benefit from wg discussions, as
opposed to implement something, push its deployment, and then bring the
idea to the IETF to rubber-stamp it.

OTOH, when it comes to publishing facts, quite often I've seen folks
arguing that publishing documents would be a way to encourage things.
e.g., I was rather trashed when I presented the measurements that
eventually made into RFC7872, and we only got to publish them on the
condition that any rationale was removed from the original document.
The rationale eventually moved into a separate document
draft-gont-v6ops-ipv6-ehs-packet-drops, which some folks argued that
should not be published since it might be interpreted as encouraging the
existing behavior -- when it simple documented while folks do what they
do. When it comes to this particular topic (to which I have devoted a
fair share of time), there's a big and accepted mistmatch between what
the operational community considers facts, and what the IETF is willing
to publish -- and in this particular case it's really operational
experience, rather than anybody circumventing the std process.

Just my two cents.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Dec 2019 03:01:41 -0300

On 1/12/19 22:49, Mark Smith wrote:
>>> 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.
>> 
>> Part of this might be the particulars of the equipment traversed.
>> The paths that were mentioned crossed some ancient gear that had
>> clipped a few corners in implementation. In the discussion, that
>> was mentioned and considered relevant.
> 
> AH and ESP EHs would be interesting to test. 

FWIW, I did some AH and ESP testing, with similar results. I don't
recall why such measurements didn't make it into RFC7872, though.

[...]
> Internet transparency that should exist without the need to resort
> to IPsec. A mitigation to send Dest Options through a transit
> network that is blocking DO should be to wrap the DO in IPsec. If a
> "transit AS" is dropping AH and/or ESP, then it actively isn't
> actually providing transit.

I guess that, at the end of the day, it boils down to:
draft-gont-v6ops-ipv6-ehs-packet-drops

> see how successful sending DCCP and SCTP over the IPv6 Internet is.

I could try to produce such measurements, if deemed of interest.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Dec 2019 16:03:48 -0300

Fred,

> The obvious persons to do so are the authors of RFC 7872.

I've dropped an email to Andrew about this. Thanks!

> Part of this might be the particulars of the equipment traversed. The paths that were mentioned crossed some ancient gear that had clipped a few corners in implementation. In the discussion, that w…

Not sure if you're referring to the paths exercised in the RFC7872
measurements, or something else.

When it comes to the RFC7872 measurements, drops reportedly had a lot to
do with this:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03

Thanks,