|
There are many web sites that list IPv6 enabled service providers, or attempt to categorize the IPv6 capability of ISPs. While these opinions are helpful, there is no standard criteria used by the sites, so it is difficult to compare the results. This document surveys current listings, and proposes a set of guidelines that could be taken into consideration by theses sites, or by anyone looking to evaluate an ISP's IPv6 capability. This guideline can also be used as a checklist by ISPs planning activation of IPv6 in their network.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on June 12, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
There are many web sites that give listings of IPv6 enabled service providers, or rate ISPs according to their IPv6 enabledness. Appendix A (Links to Listing Programs) gives examples of these.
There are several motivations for these listings which benefit both the ISPs and the users. It gives ISPs a goal to work for in turning up IPv6, i.e. earning a rating as "IPv6 capable". It also can be used by ISPs for publicity, a platform for telling the world that their service is ready for IPv4 address exhaustion. Listings can also be a guide for users to select the IPv6 capability they want when they choose their ISP, assuming they have a choice in their service area.
This document surveys examples of currently known listings, and proposes a set of basic guidelines that can be used in revised or new listings like this or by individuals evaluating an ISP's capability. These guidelines would help those that intend to start such programs. It may also help in keeping one listing or rating guideline from being widely different from another, so it would not confuse users who decided to choose ISPs on the basis that the ISP is on one of these IPv6 enabled service provider listings.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
The IPv6 enabled program (http://ipv6forum.org/ipv6_enabled/) lists ISPs at two levels: basic and advanced. At the time of this writing, the advanced level list has not been started yet. The requirements for being listed in the basic list are, to have a prefix assigned or allocated (IPv6 enabled program does not check if the prefix is an assignment or allocation), have a global AS route it, and keep reachability as much as possible.
The IPv6 Enabled Program checks the following.
The ISP's AS number is checked against a database to see if the AS exists and is unique.
The ISP's IPv6 prefix is checked against a database to see if the applying ISP is the rightful owner. Actual traffic to the prefix from a customer is also checked. Checking at the time of writing is done by using a script that the ISP will paste to a web site, and the script checks if it was accessed via IPv6.
The check noted in the previous section is done periodically to check global reachability.
IPv6 Ripeness (http://labs.ripe.net/content/ipv6-ripeness/) is part of a study conducted by RIPE NCC. Stars are given to LIRs registered in the RIPE NCC service region by checking there status in IPv6 deployment.
Stars are earned by checking the following criteria.
The programs discussed in this section share these criteria in common.
IPv6 Ripeness also checks if a route6 is registered (have good routing manners), and a reverse DNS is set up. IPv6 Enabled Program checks for actual traffic which requires the presence of an active web server inside the ISP.
This guideline can be used to check any LIR or a PI address holder, that claims to be an ISP. The guideline is only intended to check an ISP's network accessibility. In turn, this guideline can also be used as a minimum requirement checklist by ISPs who want to newly turn up IPv6 in their network.
We divide the listing into three levels, Experimental, Basic, and Advanced. Experimental level is what is a minimal set of capabilities for any ISP to claim that they have some form of IPv6 working and available to some subset of customers. The Experimental level will not guarantee that the ISP has a fully working or production quality IPv6 network or that IPv6 service is available to all customers. The Experimental level is what is absolutely necessary to provide service defined in [RFC5211] (Curran, J., “An Internet Transition Plan,” July 2008.) section 2.1 as PREP1+PREP2+PREP3 strengthened by the addition of section 2.2 "Trans1". This means that in addition to preparing for IPv6 deployment, an Experimental level ISP MUST offer IPv6-based Internet Service to at least some customers as a trial.
The Basic level will take the requirements one step further in bring the level of deployment closer to the quality of the IPv4 network. The Basic level includes what is absolutely necessary to provide service defined as MUST in [RFC5211] (Curran, J., “An Internet Transition Plan,” July 2008.) section 2.2 as TRANS1+TRANS2+TRANS3 and to the extent possible the capabilities defined as SHOULD.
The requirements of the Basic level should be covered in order to provide any of the service types defined in the General Terminology section in [RFC4084] (Klensin, J., “Terminology for Describing Internet Connectivity,” May 2005.).
The Advanced level will take the requirements further to bring the level of deployment and support to parity with what is generally recognized as "full production support" in the IPv4 services offered by ISPs today. This corresponds to the service level defined in [RFC5211] (Curran, J., “An Internet Transition Plan,” July 2008.) section 2.3 as POST1+POST2+POST3.
The Experimental level listing checks an ISP to meet the following criteria.
The Basic level listing checks an ISP to meet the following criteria.
Detailed criteria for Advanced level are difficult to specify, as they depend on the specific operational characteristic of the particular network. In general the Advanced level listing requires an ISP to meet the following criteria, essentially full parity with IPv4 level of service.
The listings can be made more useful if checking is done according to the target users of the ISP service. ISP for residential, ISP for ISPs (transit providers), ISP for enterprises, and ISP for data centers have different requirements. This document does not go into discussing the requirements for each type of services are. This document intends to discuss the requirements that should be common to any services provided by any ISP.
This draft does not introduce any new Security Considerations.
None.
The author would like to thank the Task Force on IPv4 Address Exhaustion, Japan. Parts of this document was inspired from work by Brian Carpenter and Sheng Jiang. Thanks to Vesna Manojlovic for providing generous input to the draft.
| [RFC5211] | Curran, J., “An Internet Transition Plan,” RFC 5211, July 2008 (TXT). |
| [RFC1981] | McCann, J., Deering, S., and J. Mogul, “Path MTU Discovery for IP version 6,” RFC 1981, August 1996 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4084] | Klensin, J., “Terminology for Describing Internet Connectivity,” BCP 104, RFC 4084, May 2005 (TXT). |
Below are some programs that list IPv6 enabled service providers.
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://www.ipv6-to-standard.org/
Hurricane Electric IPv6 Progress Report http://bgp.he.net/ipv6-progress-report.cgi
| Seiichi Kawamura | |
| NEC BIGLOBE, Ltd. | |
| 14-22, Shibaura 4-chome | |
| Minatoku, Tokyo 108-8558 | |
| JAPAN | |
| Email: | kawamucho@mesh.ad.jp |
| Edward J. Jankiewicz | |
| SRI International, Inc. | |
| 333 Ravenswood Ave | |
| Menlo Park, CA | |
| USA | |
| Email: | edward.jankiewicz@sri.com |