Subject: draft-kawamura-ipv6-isp-listings-00.txt

From: Lindqvist Kurt Erik <[email-masked]>
Date: Tue, 20 Jul 2010 16:41:16 +0200

I have read the above documents and have some general comments and then some more nit like comments.

General comments: 
-----------------

In general it might be good with a document outlining some basic checklists to determine the level of IPv6 readiness in a service provider. However, I doubt the value of listing some of the current programs and what methodology they are currently using. These change, and keeping the document uptodate so it's meaningful might be hard and of little value. Also, there are some existing discussion on how to track IPv6 deployment - some of this was discussed at the RIPE meeting in Prague http://www.ripe.net/ripe/meetings/ripe-60/presentations/Aben-IPv6_at_web_clients_and_caching_resolvers.pdf and from what I understand similar discussions where held at the Google IPv6 day. 

Now, that type of measurement is not the same type of checklist / certification program as the I-D describes, but this brings me to what I believe is the biggest flaw of section 3 - it doesn't say much about actual deployment. Rather, the barrier is very low. For example in 3.3 it mentions an allocated or PI block. If this is for an ISP, a PI block is useless as the intention of PI is to not suballocate. I would set the requirement to PA bock only. Further - I believe the Basic class described in 3.3 should at least require sub-allocations of IPV6 prefixes, otherwise it's hard to argue that an ISP has 'deployed' IPv6. As for the Advance class in 3.4, I would suggest that an ISP provides more than basic services (i.e DNS) over IPv6 to end-users and/or the Internet in general. 

Still, while I am somewhat agreeing with a standardized measurement of IPv6 readiness in an AS/ISP I think that it's more useful to work on measuring actually deployed clients that can be observed and publishing that data. Even better would be standardized quality measures of these deployments. There are many drawbacks on doing this based on only observed data at a server side ala looking at a web-server, but as Lorenzo and Google have shown in many presentations, at least it gives data to do a risk assessment for a service operator. 

If this document could combine some level of Basic recommendations along the lines of "Have PA, hvae done X sub-delegations, provides Y services" together with a standard collection mechanism/schema (perhaps that is really a different document) similar to what RIPE does, what Google does, or even better- a format or method that would allow sharing of data, content/service operators could build a matrix and we could see the progress and quality of IPv6 deployment. 

I know that several content providers have been thinking of how they could best measure IPv6 deployment effects on their services, and I am sure there is a lot of thinking out there that might be worth tapping into. 

Nits: 
-----

Fist of all there are quite a few abbreviations that are not expanded when first used, like LIR. Secondly, the two paragraphs :

> 1.  Introduction
> 
> 
>    There are many web sites that give listings of IPv6 enabled service
>    providers, or rate ISPs according to their IPv6 enabledness.  The
>    following are few examples of currently known programs.
> 
>       IPv6 Enabled Program 
> http://ipv6forum.org/ipv6_enabled/
> 
> 
>       IPv6 Ripeness 
> http://labs.ripe.net/content/ipv6-ripeness/
> 
> 
>       SixXS 
> http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers
> 
> 
>       IPv6 to Standard 
> http://ipv6-to-standard.org/
> 
> 
>       Hurricane Electric Free IPv6 Certification
>       
> http://ipv6.he.net/certification/

...and....

> 
> 2.  Summary of the Current Situation
> 
> 
>    The following are the list of currently known programs that list or
>    rate ISPs according to a guideline that each has determined.
> 
> 
>       IPv6 Enabled Program 
> http://ipv6forum.org/ipv6_enabled/
> 
> 
>       IPv6 Ripeness 
> http://labs.ripe.net/content/ipv6-ripeness/
> 
> 
>       SixXS 
> http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers
> 
> 
>       IPv6 to Standard 
> http://ipv6-to-standard.org/
> 
> 
>       Hurricane Electric Free IPv6 Certification
>       
> http://ipv6.he.net/certification/
> 
> 
>    note: the following description of each program is not yet complete.

are repetitions that doesn't really add to the document. 

Best regards,

- kurtis -

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Jul 2010 09:14:08 -0700

Thanks for this. We will have a discussion in the coming working group meeting, and will I hope continue discussion in the mailer. 

> I have read the above documents and have some general comments and then some more nit like comments.

http://www.ipinc.net/IPv4.GIF

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 21 Jul 2010 12:06:25 +0900

Hi Kurt

Thanks for the review

Lindqvist Kurt Erik wrote:
> In general it might be good with a document outlining some basic checklists to determine 
> the level of IPv6 readiness in a service provider. However, I doubt the value
> of listing some of the current programs and what methodology they are currently using.
> These change, and keeping the document uptodate so it's meaningful might be hard and
> of little value.

I agree. The lists on this draft are noted here for reference and starting a discussion.
If this were to be an RFC, its not much worth listing them on the document.

> Now, that type of measurement is not the same type of checklist / certification 
> program as the I-D describes, but this brings me to what I believe is the
> biggest flaw of section 3 - it doesn't say much about actual deployment. ]
> Rather, the barrier is very low. For example in 3.3 it mentions an
> allocated or PI block. If this is for an ISP, a PI block is useless as the intention
> of PI is to not suballocate. I would set the requirement to PA bock only.

Good point. I agree with this.

> Further - I believe the Basic class described in 3.3 should at least require 
> sub-allocations of IPV6 prefixes, otherwise it's hard to argue that an ISP
> has 'deployed' IPv6. As for the Advance class in 3.4, I would suggest that an

Also agree here.

> ISP provides more than basic services (i.e DNS) over IPv6 to end-users and/or the Internet in general. 

Agree also.

> Still, while I am somewhat agreeing with a standardized measurement of IPv6 readiness in an 
> AS/ISP I think that it's more useful to work on measuring actually deployed
> clients that can be observed and publishing that data. Even better would be
> standardized quality measures of these deployments. There are many drawbacks
> on doing this based on only observed data at a server side ala looking at
> a web-server, but as Lorenzo and Google have shown in many presentations,
> at least it gives data to do a risk assessment for a service operator.

I think that would be interesting work too.

What I hear from small ISPs these days is
that they want a minimum list of things to do to be
able to communicate with the IPv6 world.

Bringing an ISP to be fully dual stacked will take years.
I think a minimum guideline would be useful (is there one out there already?), and
if these lists would measure readiness according to
minimum guidelines that would be even better.

> If this document could combine some level of Basic recommendations along the lines of
> "Have PA, hvae done X sub-delegations, provides Y services" together with a standard
> collection mechanism/schema (perhaps that is really a different document) similar to
> what RIPE does, what Google does, or even better- a format or method that would allow
> sharing of data, content/service operators could build a matrix and we could see the
> progress and quality of IPv6 deployment.

This sounds very cool. Although I admit I don't know too much about measurement.

Regards,
Seiichi

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Wed, 21 Jul 2010 08:28:22 +0200

> Bringing an ISP to be fully dual stacked will take years.

So I suggest that minumum is 

- PA Block
- Customer Assignments
- DNS resolvers IPv6 capable
- Native (v6 only or dual-stack) upstream connection
- SMTP relay / Submission IPv6
- IMAP/POP IPv6

With that you can run on v6. The last two I am not to determined on, but then a gradually increasing list of services that is supporting IPv6 

- Native transport to customers
- Web
- Jabber
- SIP
- etc

> I think a minimum guideline would be useful (is there one out there already?), and

Not that I know of. 

Best regards,

- kurtis -

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Jul 2010 10:27:53 +0200

Hi,

> - SMTP relay / Submission IPv6

Seconded.  These are the most crucial blocks for an ISP to enable useful
IPv6 connectivity for his customers.

> - IMAP/POP IPv6

I'm not sure about this - yes, if the ISP offers hosted mail services
for the customer, but this is already going into the "individual products"
section.  A pure transit ISP might not need that.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Seiichi Kawamura <[email-masked]>
Date: Sat, 24 Jul 2010 16:25:17 +0900

Hi Kurt, Gert

Thanks for the comments.

> IPv6 connectivity for his customers.

This is actually a pretty good 'what to do first' list.
I would add a note about PMTUD functionality with the
native upstream. I come across networks where packets
over 1500bytes don't get through from time to time...

I wonder if reverse DNS shoulod be mentioned or not.

> section.  A pure transit ISP might not need that.

I agree with Gert.

Regards,
Seiichi

---

From: "Frank Bulk - iName.com" <[email-masked]>
Date: Sat, 24 Jul 2010 09:20:14 -0500

Are you saying that an MTU greater than 1500 should be required

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Seiichi Kawamura
Sent: Saturday, July 24, 2010 2:25 AM
To: Gert Doering
Cc: Lindqvist Kurt Erik; IPv6 v6ops
Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt

<snip>

<snip>

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 24 Jul 2010 17:21:06 -1000 (HST)

> - Native (v6 only or dual-stack) upstream connection

If you by native you mean non-tunneled, I disagree with this. 
Operationally how does a user even verify that their connectivity does or 
does not transit through one or more tunnels on their way to whatever 
they're trying to reach even if their own connectivity is native?  If the 
ISPs peer(s) or upstream(s) have their act together, you may not even see 
much of a difference.  And consider that the upstream(s) could very well 
be tunneling internally all over their backbone.

So for the stated purposes of this draft why is requiring the ISP to have 
native upstream connectivity relevant at all?  Focus needs to be kept on 
the services visible to and directly accessed by users.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Seiichi Kawamura <[email-masked]>
Date: Sun, 25 Jul 2010 16:24:20 +0900

Hi

Tunnels, misconfigured(or intentionally configured) MTUs,
ICMP filtering was what I had in mind.

Regards,
Seiichi

---

From: "Frank Bulk" <[email-masked]>
Date: Sun, 25 Jul 2010 08:13:35 -0500

Ok, I follow you now.

Frank

-----Original Message-----
From: Seiichi Kawamura [mailto:[email-masked]] 
Sent: Sunday, July 25, 2010 2:24 AM
To: [email-masked]
Cc: IPv6 v6ops
Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt

Hi

Regards,
Seiichi

---

From: Chuck Anderson <[email-masked]>
Date: Sun, 25 Jul 2010 10:13:40 -0400

> the services visible to and directly accessed by users.

Agreed.  I think there is a bias against tunnels because they often 
imply:

- poor interconnectivity
- poor locality of interconnectivity
- high latency
- lower MTUs and the problems that brings

So the focus should be on improving those aspects, rather than 
avoiding tunnels explicitly.

---

From: Vesna Manojlovic <[email-masked]>
Date: Mon, 26 Jul 2010 15:08:18 +0200

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 [email-masked] -- 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.

=====

---

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 27 Jul 2010 17:48:34 +0900

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:
>  <theirdomain> might not be that easy to determine for some of the LIRs
> out there)
> 

- --
Seiichi Kawamura <[email-masked]>
   NEC BIGLOBE Ltd.
   +81 3 3798 6085  office
   +81 90 1547 4791 mobile