[atlas] Survey results on Atlas open-sourcing

On Thu, Jan 5, 2012 at 1:11 PM, Philip Homburg <philip.homburg at ripe.net> wrote:
> On 1/5/12 9:26 , Iñigo Ortiz de Urbina wrote:
>>
>> This is good to hear. I was meaning that according to the FAQ, there seems
>> to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q:
>> I have an IPv6-only network. Will the probe work on it? A: Although the
>> probe itself is IPv6-ready in general, some of the off-the-shelf software
>> components on it are not (yet). We hope that this will be resolved soon, but
>> until then the probe needs IPv4 to communicate with our infrastructure. The
>> measurements themselves can run on IPv6. "
>
> The main limiting factor is DNS. For static configurations it should work.
>
> For normal (dynamic) configuration, the problem is that we have no support
> for either DHCPv6 or the DNS resolver option in RA.
> So without IPv4, the probe will not have a DNS resolver.
>
> But I guess the FAQ needs to be updated to say that it can be made to work
> with static configuration.
>

Thank you so much for making these points clear.

I'd like to suggest this addition to the FAQ, it can be used as a
draft to start from:

"
Although the probe itself is IPv6-ready in general, some of the
off-the-shelf software components on it are not (yet).
More particularly, current firmware does not support DHCPv6 (RFC3345)
or DNS resolver option in RA (RFC6106) and thus no way of dynamically
acquiring DNS information to function properly.
We hope that this will be resolved soon, but until then the probe
needs IPv4 to communicate with our infrastructure, unless full IPv6
configuration is performed manually.
The measurements themselves can run on IPv6.
"

>> But, as Jens already jumped in, I want to support his comments on adding
>> DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user
>> experience is degraded due to HTTP, DNS response times themselves, and not
>> the latency.
>
> For DNS it is just a matter of adding it to the user interface. Http
> requires a policy decision on how to avoid getting probe hosts in trouble.
>

My particular use case would require HTTP probing first, rather than
DNS probing. Both of them are interesting for many scenarios, though.

Have a nice day,