Comments on Nalini et al's IPv6 EHs presentation

[Ana C. Custura]

Hi,

Adding to Fernando's comments, as I've also done my fair share of IPv6 extension header measurements:

On Tue, Jul 26, 2022, at 4:25 AM, Fernando Gont wrote:

>
> * Nalini et al's measurements seem to be from one specific point in the
>    network topology, to a very small subset of destination endpoints.
>    If anything, the results may indicate that EHs do work on some
>    specific paths (we knew they do), but certainly is not an indication
>    that they are usable on the public Internet -- i.e., think of
>    statistical significance of the measurements, so to speak.

The measurements done in 2020 at the University of Aberdeen agree with Nalini's data.
For Destination options, we found  50% of destinations (authoritative NS servers for the Alexa Top 1M domain) respond to a DNS query sent using an IPv6 Destination option, and where they don't, the drops happen close to the destination network and *not* in the Internet core - this was for 20K targets * 4 vantage points. 
I've re-done the measurements just recently with v. similar results - but I'm yet to add an analysis of where this happens in terms of AS. 

>
> * There doesn't seem to be any practical difference between the probe
>    packets that we (RFC7872) sent, vs the ones in this experiment: at
>    the end of the day, the network doesn't really care whether the
>    packets were crafted by the kernel, or by pcap_inject().
>
> * In RFC7872, we did measure whether EHs are dropped at transit ASes vs.
>    the destination AS -- and there's a bit of both. (the probable reasons
>    are analyzed in RFC9098)
>
> * Not sure why Nalini refers to other measurements employing "fake
>    data"/crafted packets. At the end of the day, From the pov of the
>    network, PDM option looks probably like an unsupported option anyway.
>    Whereas, on the other hand, we (RFC7872) employed PadN, which is way
>    more likely t be supported than PDM.

+1  - in our measurements we use PadN options, which indeed we craft then add to a raw socket expecting the correct type of header -  the resulting packets are valid PadN, recongnised by wireshark etc. In fact, this approach is flexible as it also allows you to send intentionally malformed packets to infer which fields are inspected by routers on the path.
What we found is that an unrecognized option (i.e., using the option defined in https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/) has, for Destination Options, the same traversability as PadN. However, using an invalid length for the header will result in very high drops.

See slides here: https://datatracker.ietf.org/meeting/108/materials/slides-108-6man-sessb-exploring-ipv6-extension-header-deployment-updates-2020-00.pdf

@Nalini - I'd be happy to validate your results using my vantage points!

Thanks, 
Ana