RING measurements don't match access-networks (Was: Some very nice broken IPv6 networks...)

[Jeroen Massar]

On 2014-11-10 11:48, Job Snijders wrote:
> On Mon, Nov 10, 2014 at 08:46:50AM +0100, Jeroen Massar wrote:
>>> Some hosts are behind exotic 6to4 NATted tunnels,
>>
>> I am a bit surprised by such a statement, or the need for it
> 
> Because that's what it looks like? I don't know what else i'd call this:
> 
> job at amazon01:~$ ifconfig tun6to4
> tun6to4   Link encap:IPv6-in-IPv4
>           inet6 addr: 2406:da00:ff00::1715:b057/128 Scope:Global
>           inet6 addr: ::10.28.34.28/128 Scope:Compat

6in4 with a wrong name. Lots of people make that mistake ;)

It still does not make it 6to4 though. And I try as much as possible to
point out these wrong labels as well, they confuse the heck out of
everybody. (indeed, 6in4,6to4,6over4,etc all don't make it easy).

Technically "6to4" is correct as they are tunneling IPv6 to IPv4, hence
6to4. It is just a wrong name because "6to4" is an actual technology.

hence why those links used to be called "SIT" on Linux. or just "tunnel".

>> Also making a claim like that they are 6to4 that is known to be false,
>> is a bit weird as there is no 2002::/16 address in the participants
>> hosts:
> 
> All I wanted to point out is that there is a large diversity in how RING
> nodes' IPv6 connectivity is arranged. I'll rephrase it as "Some hosts
> are behind exotic setups". 

Quite likely. But most will be properly connected and managed and in a
nice coloration. Not on a flaky dsl link.

>> <snip>
> 
>> Actually, what that demonstrates is that out of a set of well-managed
>> nodes, there are issues with PMTU. Hence, please contact these
>> networks (they are part of the ring, thus that should be easy) and
>> make them behave properly. That solves another set of problems.
> 
> Do you want to help engage with these networks? 

Have been doing so for over 10 years... thus if help is needed, I'll try
to scrounge up some cycles from somewhere. A better IPv6 is the goal of
it all, not bandaiding it.

But as you have the contacts at those nodes, contacting these folks
should be very easy to get these issues resolved.

>> You might want to run a similar one from all the nodes, thus making a
>> cross-RING MTU determination to get even better results, as I did it
>> only from one vantage point. Maybe time for ring-mtu? :)
> 
> That sounds like a great idea, maybe it can be added to RING SQA as a
> secondary type of alert? "MTU suddenly decreased or increased towards a
> significant set of RING nodes"? https://github.com/NLNOG/ring-sqa

That sounds something very useful.

And actually, having that tool might be a big reason for a lot of ISPs
to contribute a node to the RING as they get free monitoring.

Note that there is on problem with MTU, the paths might just be
assymetric and thus wrong indicators might be received. But as you have
access to all the nodes, should be easy to do a traceroute from both
sides to see if the route is assymetric or not.

>>> For NLNOG RING applications we mandate that there is 1 globally unique
>>> IPv6 address on the host, we do not specify how this should be
>>> accomplished. This leads to some variety, not all of those
>>> implementations I would describe as "well behaved".
>>
>> While that is absolutely true, most of those boxes ARE well behaved, as
>> the providers involved will take sure that there are no problems.
>>
>> And they definitely are not located in an access network on a dingy home
>> DSL line...
> 
> I've asked some incumbents to provide this, but so far no dice.

It basically means they need to allocate a DSL link or similar to this.

> Thanks
> for taking a deep dive. Randy Bush presented at RIPE69 comparing the
> RING with RIPE Atlas, I thought it interesting:
> 
>     https://ripe69.ripe.net/presentations/92-141105.ripe-atlas-nlnog-compare.pdf

Atlas is likely the best we have for this.

Would be great to have some MTU tests from those boxes to check for
PMTUD blackholes.

Greets,
 Jeroen