[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-kawamura-ipv6-isp-listings-00.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Vesna
Thanks for the wonderful list of feedbacks.
I've been interested in the RPSL ping point by Brian Haberman
for its original puropose, but I see some people do
think this could be used for checking. I have mixed
feelings about this. Its not used much just yet
and I don't really know what it proves.
rDNS and mail servers (MX) have good comments.
We had some good comments at the mic yesterday.
This really helps. Thanks.
Regards,
Seiichi
Vesna Manojlovic wrote:
> Hi Seiichi, list,
>
> as one of the people from the RIPE NCC working on "IPv6 Ripeness",
> (http://labs.ripe.net/Members/becha/content-ipv6-ripeness )
> let me forward the comments we've received.
>
> We have asked what additional criteria shall we use for the "5th star";
> we suggested either to
> - ping the "pingable" address in the route6 object as proposed in
> http://www.ietf.org/id/draft-haberman-rpsl-reachable-test-04.txt
> or
> - observe addresses from the allocated IPv6 range connecting to
> www.ripe.net (during certain time period)
>
> We've received feedback from the ipv6-wg list, LinkedIn forums and the
> Forum on the RIPELabs, and private contributions from people writing to
> claim their T-shirt award for 4 stars ;)
>
> I hope you will find the summary of the comments useful.
>
> Regards,
> Vesna Manojlovic
>
> =====
>
> IPv6 deployment criteria suggestions summary
>
> 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.
>
> Reachability of the reverse DNS servers:
>
> There was quite a support for this option, worded in various ways:
>
> - 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?
>
> Reachability of the LIR web services:
>
> - have www.<theirdomain> with working IPv6 connectivity (now,
> <theirdomain> might not be that easy to determine for some of the LIRs
> out there)
>
> - 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?)
>
> - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6
> connectivity for a fifth star.
>
> Connecting to www.ripe.net
>
> For:
>
> - Regarding what method to use for the five star rating, 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 option b) for the fifth star "observe addresses from the
> allocated IPv6 range connecting to www.ripe.net (during certain time
> period)"
>
> Against:
>
> - None of our customers nor we ourself probably will ever connect to
> http://www.ripe.net This is probably true for all hosting providers.
>
> For *.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?
>
> - In any case, we do access the ripe whois server from our datacenter
> via IPv6. 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 is probably the
> better option.
>
> Reachability of the mail service
>
> - have IPv6 capable MXes for some/all of the listed contact e-mail
> addresses for the inet6num and/or the organization object
>
> (supported by anonymous contributors several times)
>
> - You might monitor your mailserver log to see which systems does send
> or receive emails via IPv6.
>
> - Are able to send email over IPv6 to ipv6-test@ripe.net -- A new one! A
> “pull” approach – you prove it to us that you can send us email over
> IPv6. Not easily scriptable.
>
> - (on the Labs Forum): having a v6 reachable email contact in whois
> (address information already present in ripedb)
>
> - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6
> connectivity [as the additional criteria]
>
> - 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?
>
> extra:
>
> * a minimal list of services would be an interesting criterium (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.
>
> * Whether the final-MX for the LIR is v6-enabled and reachable.
>
> =====
>
>
- --
Seiichi Kawamura <kawamucho@mesh.ad.jp>
NEC BIGLOBE Ltd.
+81 3 3798 6085 office
+81 90 1547 4791 mobile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkxOnWIACgkQcrhTYfxyMkL2kwCgiLEeBAbFnnoZm3arIrLOGqn5
cjYAnitNSFStHXHeY3PWcMA7GD8nT5LH
=rSqq
-----END PGP SIGNATURE-----