IPv6 RIPEness - Criteria for a Potential Fifth Star Rating

We proposed adding a fifth star to the rating system and asked for your feedback on two options:

a) Measure the reachability of the "pingable" address in the route6 object (as proposed in RFC 5943: A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing ) or,

b) Observe if the addresses from the allocated IPv6 range are connecting to http://www.ripe.net

We received feedback on the RIPE Labs forum, RIPE IPv6 Working Group mailing list , LinkedIn, and in the private comments from people who wrote to us to claim the T-shirt award for having a four-star RIPEness rating.

Here's what you had to say about the first option:

a) Measuring reachability of the address in the “pingable:” attribute

- "would be of more use for the broad public in the end."

- "the pingable attribute seems generally useful and this would encourage people to start using it."

- "The idea of publishing a 'ping6able' address is attractive, technically and at first glance. Although - wearing my security hat for a moment - publishing such an address might attract DoS traffic? Caveat: 'I still have to read the draft, and it all depends on implementation."

- "The 'pingable' address in the route6 object is probably a good idea for its forecoming consequences on global reachability tests it allows."

- "Its adoption may be too slow for choosing it for the purpose discussed here, so checking source addresses visiting RIPE website may be a first step in the meantime."

The second option received polarised opinions:

b) Measuring connections to www.ripe.net

- "a LIR that doesn't use the RIPE website over v6 at least once a month isn't really IPv6 enabled, and it also makes sure the LIR didn't just have a temporary test setup, so I would strongly vote for that alternative."

- "we support this option"

- "look at the source addresses of website visitors and match that up with the allocations."

- "None of our customers nor we ourselves probably will ever connect to http://www.ripe.net. This is probably true for all hosting providers."

In addition to the options above, we received a suggestion on a variation of b):

c) Alternatively: measuring the connections to *.ripe.net

It might make more sense to measure all *.ripe.net services, for instance also whois.ripe.net and lirportal.ripe.net.

- "other sub-domains like lirportal.ripe.net, labs.ripe.net, and ris.ripe.net" 

- "Perhaps also the whois server could additionally be used for this, too?"

- "I understood option b) as: "We are going to analyse the webserver logfiles" but if b) includes all services - as you wrote *.ripe.net - than b) makes a lot more sense to me"

And finally, there was an idea to combine the measurements of user/resolver IPv6 capability by Emile Aben with the LIR data on the LIR Portal

https://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-1/

Additional suggestions

Most of the additional suggestions we received fit into three categories: IPv6 capable reverse DNS servers, LIR’s web servers, and email.

d) Measuring the reachability of the reverse DNS servers: 

- "...have IPv6 transport (with addresses from their own prefix) to all/some of  the DNS servers that the IPv6 reverse zone is delegated to."

- "For the purposes of automation, I'd say 'at least one of the (reverse) DNS servers for the prefix answers to a DNS query over v6' should be sufficient, and better than the two first alternatives. While there may be some small relevance whether the DNS server is from another prefix, it would result in false negatives in the cases where a (somehow defined) organisation is using multiple prefixes (e.g. due to mergers etc.).  That would be confusing."

- "You might monitor (reverse) DNS queries on your system (to see who is resolving via IPv6 and who is queried for rDNSv6)."

- "Whether the reverse DNS nameserver for the /32 can be queried over v6, as DNS services themselves should be an important issue for IPv6 sites."

- "...reverse DNS nameservers have v6 records and are pingable through v6 and actually respond to v6?"

e) Measuring the reachability of the LIR web services:

- "Have www.<LIRrdomain> with working IPv6 connectivity (now, <LIRrdomain> might not be that easy to determine for some of the LIRs out there)."

- "ping6 on www6.intrinsec.net (LIR’s web site)"

- "LIR's website is difficult to determine. You might add a field on the LIR portal at OTOH what is IPv6 delivery of website? How many parts come via IPv6 how many via IPv4? Take our website www.iks-jena.de as an example. It delivers – dual stacked - all content via IPv6, but if IPv6 is enabled, the show remote client address is displayed as IPv6 AND IPv4 at the same time. Is this IPv6 enabled?"

- "Having a v6 reachable website (try to guess a website from the email contact domain? Provide an interface for the LIR to specify further information for tests but not making these public?)"

f) Measuring the reachability of the mail service

- "Having a v6 reachable email contact in whois  (address information already present in ripedb)."

- "Have IPv6 capable MXes for some/all of the listed contact email addresses for the inet6num and/or the organization object."

- "You might monitor your mailserver log to see which systems does send or receive emails via IPv6. "

- "Whether the final-MX for the LIR is v6-enabled and reachable."

- "I was thinking about data that is already in the RIPE database. My first thought was email but who is actually running email over IPv6?"

- "That emails to RIPE are sent over IPv6."

- "Check if able to send email over IPv6 to ipv6-test@ripe.net ."

g) Native vs tunnels

- "My preference for the fifth start would be to have native IPv6 connectivity instead of tunnels. But it'll require a bit more work to detect it and Keytrade wouldn't qualify so far..."

See: http://www.dia.uniroma3.it/~compunet/tunneldiscovery/

More Suggestions & Additional Information

Many people suggested that the fifth star should only be awarded to those who have all the criteria fulfilled:

- "A minimal list of services would be an interesting criterion (like at very least: MX -> IPv6, IPv6 website, DNS servers...)"

- "If the LIR is using native IPv6 services like mail, DNS, sticky DNS, time, ntp, webservers, etc."

- "Offering "complete" services over IPv6 would be a good criteria.  Offer v6 connectivity with v6 DNS / email / something else than just connectivity for ISPs, offering content/services over v6 for content/services providers..."

- "Something revolving around: 'is actually moving bits over IPv6, instead of just sitting on the paperwork of having address + BGP + DNS in place' would be useful"

For more on this, you should read this IETF internet draft by Seiichi Kwamura:

A Basic Guideline for Listing ISPs that Run IPv6

If you want to help define these guidelines, please take part in the discussion on the IPv6 Operations IETF working group:

http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00810.html

Conclusion

If we are going to add the fifth star to the rating, there is certain criteria to be satisfied:

• Easily automated

We base our rating on the data in INRDB, which is a collection of (public) data sets: RIPE database, so-called “stats” files about the resources allocated to LIRs, and RIS. The easiest would be if the additional rating would be already contained in this data set, or could be easily attached to it.

• Neutral and fair

Data that we will look at should be a fair representation of the deployment “in the wild”, and not necessarily based on the interaction between an LIR and the RIPE NCC. 

• Availability of historic data