[mat-wg] IPv6 extension headers support on RIPE Atlas

On 2013/11/06 8:27 , Tim Chown wrote:
> Just to rewind a bit, the concern over support on-path for IPv6 Extension Headers, esp. the Fragmenttation Header, has always been there, it’s just that with the recent measurements by Fernando and an MSc student here, the numbers are rather worse than many people expected, moreso the longer the EH used. Fernando did the test extending his own IPv6 toolset, our student used scapy (which supports the four main EHs) to craft HTTP requests.  We both targeted the top Alexa sites.  The Fragmentation Header success rate across the sites tested was at best under 70%.
> 
> The interest with Atlas is that we could test between participating sites, rather than just to Alexa-ranked web servers, which is more interesting esp. bearing in mind the desire to build IPv6 p2p apps.
> 
> As for HTTP tests - I asked a few weeks ago about using the probes to do general HTTP measurements, and was told they were only possible for a limited set of users. No problem with that, but I simply guessed from that response that expecting the probes to do IPv6 EHs without significant changes was optimistic.  And I certainly understand the security-related concerns.
> 
> I have a different student now working further on the tests, which may include adding extra EH capability to scapy, and possible ‘looking glass’ style tests. I think Fernando is also exending his tests as he was only checking with one EH type.  So we should get more/better information soon regardless, and we may get better clues as to how Atlas could help.  I think this is an important issue for IPv6, witness the current discussions and I-Ds on EH handling, header lengths, etc.

A couple of remarks:

NLNet Labs used RIPE Atlas to measure fragmentation issues in the
context of DNS. Though the error rate is high (around 10%) it is nowhere
near 30%. It might be worth investigation whether the filtering happens
at the end site or not. I can imagine that adding fragmentation support
to http load balancers is something you do when you have really nothing
else to do. In that case measuring fragmentation of tcp packets might
give a rather pessimistic result.

There are various reasons why RIPE Atlas cannot provide an interface
that allows the user to specify arbitrary packets going out and
reporting everything that is received. The first one is a security issue
and the second leads to storage problems on the older probes. For this
reason it would be nice if feature requests can be both minimal and
specific. I.e. what is the minimal amount of reporting you need to
measure what you want to measure and what is a safe way to generate the
packets you need.

In this context, would it be sufficient to have hop-by-hop or
destination options that just consist of pad options? Hopefully somebody
from the operator community can guess whether unlimited use of
hop-by-hop options filled with padding would be safe.

(By the way, I have no idea how routers are supposed to support
hop-by-hop options for unicast packets. Does that do anything useful
other than trying to DoS the router?)

Finally, RIPE Atlas is not a mesh network. A subset is (the Atlas
Anchors, but that part is very small at the moment). So using Atlas
gives you more sources of traffic, but not more destinations.

Philip Homburg