Send Iepg mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/iepg
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Iepg digest..."
Today's Topics:
1. Re: Comments on Nalini et al's IPv6 EHs presentation
([email protected])
2. Re: Comments on Nalini et al's IPv6 EHs presentation
(Fernando Gont)
3. Re: Comments on Nalini et al's IPv6 EHs presentation
(Fernando Gont)
4. Re: Comments on Nalini et al's IPv6 EHs presentation
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 Jul 2022 12:41:36 +0000 (UTC)
From: "[email protected]"
<[email protected]>
To: Fernando Gont <[email protected]>, "[email protected]"
<[email protected]>, "Ana C. Custura" <[email protected]>
Cc: Michael Ackermann <[email protected]>, Tommaso Pecorella
<[email protected]>
Subject: Re: Comments on Nalini et al's IPv6 EHs presentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Ana,
Happy to work with you!? ?I will contact you unicast.
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Tuesday, July 26, 2022 at 05:23:56 AM PDT, Ana C. Custura
<[email protected]> wrote:
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
------------------------------
Message: 2
Date: Tue, 26 Jul 2022 09:53:07 -0300
From: Fernando Gont <[email protected]>
To: "[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
Cc: Michael Ackermann <[email protected]>, Tommaso Pecorella
<[email protected]>
Subject: Re: Comments on Nalini et al's IPv6 EHs presentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi, Nalini,
On 26/7/22 09:11, [email protected] wrote:
> Fernando,
>
>>For the numbers to be meaningful to assess whether IPv6 EHs are usable
>>on the public Internet, you definitely need to measure against a large
>>number of destinations (and also vantage points).
>
> Our original test was from:
>
> Warsaw
> Toronto
> Melbourne
> Mumbai
> Frankfurt
> Seattle
>
That's certainly not statistically significative.
> So, multiple continents, multiple transit providers.? ?How many cities /
> continents would you like?
As many as possible? ;-)
For instance, compare that vs. all v6-enabled destinations from Alexa's
top 1-Million sites.
> We can certainly talk to the RIPE Atlas people.
Jen had done that at the time, with similar results to those in RFC7872,
IIRC.
> When you redo your testing, I suggest you also test to see where exactly
> the packet is dropped.
That's in RFC7872, already :-)
> For example, is it dropped at the source, in a
> transit network or a destination network.? ?Merely redoing testing
> against sites which we know are likely blocking extension headers is
> unlikely to produce different results.
Not sure what you mean.
The goal of measurements is to measure with as many destinations and
vantage points as possible, since *that* is what can shed light on the
usability of EHs on the public Internet.
The first important result is whether the packets get to the intended
destination or not. If they don't, whether they are dropped by the
destination AS or a transit AS. And if dropped at the destination AS,
it's also interesting whether they are dropped by the final box, or
elsewhere.
Note: Geoff also did measurements in this area, with similar results to
those in RFC7872.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
------------------------------
Message: 3
Date: Tue, 26 Jul 2022 10:10:57 -0300
From: Fernando Gont <[email protected]>
To: "Ana C. Custura" <[email protected]>, [email protected]
Subject: Re: Comments on Nalini et al's IPv6 EHs presentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
On 26/7/22 09:22, Ana C. Custura wrote:
> 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.
But, IIRC, Nalini's results were way more optimistic than that!
OTOH, the numbers you refer to seem to be in line with those in RFC7872....
>> * 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.
Same for longer headers --- i.e., the longer the IPv6 header chain, the
higher the drop probability.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
------------------------------
Message: 4
Date: Tue, 26 Jul 2022 13:16:05 +0000 (UTC)
From: "[email protected]"
<[email protected]>
To: "[email protected]" <[email protected]>, Fernando Gont
<[email protected]>
Cc: Michael Ackermann <[email protected]>, Tommaso Pecorella
<[email protected]>
Subject: Re: Comments on Nalini et al's IPv6 EHs presentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Fernando,
> For instance, compare that vs. all v6-enabled destinations from Alexa's top
> 1-Million sites.
For what it is worth, you do know that many of these end up going to the same
handful of CDNs, right??
That is why we intentionally did NOT do this.
We will be back next time with more results.? ?
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Tuesday, July 26, 2022 at 05:53:16 AM PDT, Fernando Gont
<[email protected]> wrote:
Hi, Nalini,
On 26/7/22 09:11, [email protected] wrote:
> Fernando,
>
>>For the numbers to be meaningful to assess whether IPv6 EHs are usable
>>on the public Internet, you definitely need to measure against a large
>>number of destinations (and also vantage points).
>
> Our original test was from:
>
> Warsaw
> Toronto
> Melbourne
> Mumbai
> Frankfurt
> Seattle
>
That's certainly not statistically significative.
> So, multiple continents, multiple transit providers.? ?How many cities /
> continents would you like?
As many as possible? ;-)
For instance, compare that vs. all v6-enabled destinations from Alexa's
top 1-Million sites.
> We can certainly talk to the RIPE Atlas people.
Jen had done that at the time, with similar results to those in RFC7872,
IIRC.
> When you redo your testing, I suggest you also test to see where exactly
> the packet is dropped.
That's in RFC7872, already :-)
> For example, is it dropped at the source, in a
> transit network or a destination network.? ?Merely redoing testing
> against sites which we know are likely blocking extension headers is
> unlikely to produce different results.
Not sure what you mean.
The goal of measurements is to measure with as many destinations and
vantage points as possible, since *that* is what can shed light on the
usability of EHs on the public Internet.
The first important result is whether the packets get to the intended
destination or not. If they don't, whether they are dropped by the
destination AS or a transit AS. And if dropped at the destination AS,
it's also interesting whether they are dropped by the final box, or
elsewhere.
Note: Geoff also did measurements in this area, with similar results to
those in RFC7872.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
------------------------------
Subject: Digest Footer
_______________________________________________
Iepg mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/iepg
------------------------------
End of Iepg Digest, Vol 57, Issue 11
************************************
