[LAC-TF] IPv6 Exntesion Headers (Fwd: On "usable extension headers" and RFC7872)

[Fernando Gont]

FYI, esto es de un thread actual del grupo de ipv6 (6man) de la IETF.

Si no tienen tiempo ganas de seguir leer el thread, esto se resume a:
los encabezados de extension IPv6 andan bastante mal en la red Internet.

Pueden ver nuestras mediciones en: RFC7872.

Y en el mensaje de abajo hay enlaces a otros trabajos.

Corta la bocha.

Saludos cordiales, y gracias!
Fernando




-------- Forwarded Message --------
Subject: On "usable extension headers" and RFC7872
Date: Mon, 2 Dec 2019 07:19:49 -0300
From: Fernando Gont <fgont at si6networks.com>
To: 6man at ietf.org <6man at ietf.org>
CC: Ole Troan <otroan at employees.org>, Enno Rey <erey at ernw.de>, Tim Chown
<Tim.Chown at jisc.ac.uk>, Brian E Carpenter <brian.e.carpenter at gmail.com>

Folks,

It seems I've experienced some email issues and have missed some of the
emails in this threads. So my apologies for breaking the "thread" with
this one.

Some comments regarding RFC7872, and related discussion on the recent
thread:

* RFC7872 was produced at a time when there were claims that ipv6
fragments were dropped in the network, but when I asked about actual
measurements, folks didn't point to any measurements backing such
claims. We were not pursuing any specific results/claims, but just tried
to find empirical data on the topic.

* In order to e.g. find where in the network packets were being dropped,
I ended up bulding an EH-enabled traceroute (EHs were not supported in
popular implementations of traceroute). Once the tool was finished, I
did some preliminar measurements. The results were way worse than
expected... to an extent that I assumed there was a bug in the tools, so
I ended up reviewing the code for at least a few days.  The fine folks
at RIPE Atlas ended up implementing EH support in their toolkit, which
enabled Jen's measurements (see below).

* While not included in RFC7872, I also did the same sort of
measurements for IPsec-related EHs, with similar results. So empirical
results seem to indicate that there is a general issue with EHs. And the
rationale provided by operators (draft-gont-v6ops-ipv6-ehs-packet-drops,
see bellow) seems to explain those numbers.

* Besides the measurements we did in RFC7872, Jen did independent
measurements with RIPE Atlas, and also got high packet drop rates:
http://iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf

* Geoff did independent measurements wrt fragmentation, and got similar
results:
http://www.potaroo.net/presentations/2017-10-25-xtn-hdrs-dns.pdf  and
https://ripe78.ripe.net/presentations/41-2019-05-23-ipv6-fail.pdf

* Eric did yet other independent measurements:
https://datatracker.ietf.org/meeting/95/materials/slides-95-maprg-6.pdf
and
https://www.ipv6council.be/IMG/pdf/13-vyncke-extension_headers_on_the_Internet.pdf

* RFC7872 was never meant to throw any results regarding limited network
domains. In fact, if we had been able to measure "limited domains", they
wouldn't be "limited domains" in the first place. Would they?  And,
besides, it would be pointless to publishe results on limited domains --
you can always build your own domain in which you can create your own
reality.

* RFC7872 documents in great detail how we obtained the results we
obtained. That means that rather than resorting to wishful thinking or
guesswork, we did our best not only to show results, but also to explain
how we did our measurements, such that if folks believed our methodology
had issues, or there were other things to be measured, they could
improve on what we did. (For instance, Geoff did find that other
measurements were warranted (see above)).

* So... why are packets with EHs dropped? Well, at the time, the draft
that eventually became RFC7872 discussed why operators block them (when
they "intentionally" do so). Folks eventually argued that such
discussion was an invitation for people to drop them (?!), and hence the
discussion ended up in a separate document:
draft-gont-v6ops-ipv6-ehs-packet-drops. As the reader may see, the
document shows reasons other than "we are the dest AS and know better
what EHs (if any) our hosts are expecting".

* I might be wrong, but probably due to the discussion on this topic, is
why we had this invited talk at IEPG
<http://iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf> with
insights on the challenges posed by IPv6 EHs.

* If there's any lessons *I* can take from RFC7872 is that, what was
welcome, seemed to be widely accepted and well understood in operational
forums like IEPG, resulted controversial (to some) in IETF circles. And
while in some forums the measurements were welcome, in others it seemed
like an invitation to shoot the messenger(s) -- as if we were the ones
dropping the packets, or we were happy about the packet drops.

* RFC7872 originated in the v6ops wg, but was also discussed in many
operational forums (iepg, ripe, lacnog, and others). That aside, the
document was not only subject of a WGLC, but also of an IETC LC, and
IESG review. So I personally don't get Ole's note/assumption that
somehow the work/consensus of v6ops is not credible (?) (ref:
https://mailarchive.ietf.org/arch/msg/ipv6/34VvkRv3wV-v1-8EOf_AI1SkdfU).
At the end of the day, if you like and respect the process, you do it
regardless of whether you personally agree with the outcome.

* I bet all co-authors of RFC7872 (including myself) would be happy to
see further measurements and analysis on the topic. In fact, we worked
on the topic to get a better understanding of the topic.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492