idnits 2.17.1 draft-kawamura-ipv6-isp-listings-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 11, 2010) is 5066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Kawamura 3 Internet-Draft NEC BIGLOBE, Ltd. 4 Intended status: Informational June 11, 2010 5 Expires: December 13, 2010 7 A Basic Guideline for Listing ISPs that Run IPv6 8 draft-kawamura-ipv6-isp-listings-00 10 Abstract 12 There are many web sites that give listings of IPv6 enabled service 13 providers, or rate ISPs according to their IPv6 enabledness. This 14 document intends to gather information about currently known sites 15 and their methods of checking an ISPs enabledness. This document 16 also summarizes a basic guideline that these listings may consider 17 when checking an ISPs IPv6 enabledness. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 13, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 There are many web sites that give listings of IPv6 enabled service 54 providers, or rate ISPs according to their IPv6 enabledness. The 55 following are few examples of currently known programs. 57 IPv6 Enabled Program http://ipv6forum.org/ipv6_enabled/ 59 IPv6 Ripeness http://labs.ripe.net/content/ipv6-ripeness/ 61 SixXS http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers 63 IPv6 to Standard http://ipv6-to-standard.org/ 65 Hurricane Electric Free IPv6 Certification 66 http://ipv6.he.net/certification/ 68 There are several motivations for these listings which benefit both 69 the ISPs and the users. It gives ISPs a goal to work for in turning 70 up IPv6. It also can be used by ISPs for publicity (in telling the 71 world that their service is ready for IPv4 address exhaustion). 72 Listings can also be a guide for users when they choose their ISP. 74 This document intends to gather information about currently known 75 listings, and to summarize a basic guideline that can be used when 76 starting a new program of the like. There are many reason (such as 77 localization) that a new listing is started albeit the fact that 78 there already is one. A presence of a guideline would help those 79 that intend to start such programs. It may also help in keeping one 80 listing or rating guideline from being widely different from another, 81 so it would not confuse users who decided to choose ISPs on the basis 82 that the ISP is on one of these IPv6 enabled service provider 83 listings. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Summary of the Current Situation 93 The following are the list of currently known programs that list or 94 rate ISPs according to a guideline that each has determined. 96 IPv6 Enabled Program http://ipv6forum.org/ipv6_enabled/ 98 IPv6 Ripeness http://labs.ripe.net/content/ipv6-ripeness/ 100 SixXS http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers 102 IPv6 to Standard http://ipv6-to-standard.org/ 104 Hurricane Electric Free IPv6 Certification 105 http://ipv6.he.net/certification/ 107 note: the following description of each program is not yet complete. 109 2.1. IPv6 Enabled Program 111 The IPv6 enabled program lists ISPs at two levels: basic and 112 advanced. At the time of this writing, the advanced level list has 113 not been started yet. The basic requirements for being listed in the 114 basic list are, to have a prefix assigned or allocated (IPv6 enabled 115 program does not check if the prefix is an assignment or allocation), 116 have a global AS route it, and keep reachability as much as possible. 118 The IPv6 Enabled Program checks the following. 120 2.1.1. Network Accessibility Ability 122 The ISP's AS number is checked against a database to see if the AS 123 exists and is unique. 125 2.1.2. Active IPv6 Address Requirement 127 The ISP's IPv6 prefix is checked against a database to see if the 128 applying ISP is the rightful owner. Actual traffic to the prefix 129 from a customer is also checked. Checking at the time of writing is 130 done by using a script that the ISP will paste to a web site, and the 131 script checks if it was accessed via IPv6. 133 2.1.3. Persistence of IPv6 service Ability 135 The check noted in the previous section is done periodically to check 136 global reachability. 138 2.2. IPv6 Ripeness 140 IPv6 Ripeness is part of a study conducted by RIPE NCC. Stars are 141 given to LIRs registered in the RIPE NCC service region by checking 142 there status in IPv6 deployment. 144 2.2.1. Criteria 146 Stars are earned by checking the following criteria. 148 o Have an IPv6 prefix allocated or a PI assigned. 150 o Prefix is visible in the Routing Information System(RIS). 152 o A route6 object is registered in the RIPE database. 154 o Reverse DNS is setup for the IPv6 prefix. 156 2.3. Summary of the Checking Criteria 158 The programs discussed in this section share these criteria in 159 common. 161 o Have an IPv6 prefix allocated or a PI assigned. 163 o Prefix is visible in a routing database. 165 IPv6 Ripeness also checks if a route6 is registered (have good 166 routing manners), and a reverse DNS is set up. IPv6 Enabled Program 167 checks for actual traffic which requires the presence of an active 168 web server inside the ISP. 170 3. Guidelines for Listing an IPv6 Enabled ISP 172 3.1. Scope of the Guideline 174 This guideline can be used to check any LIR or a PI address holder, 175 that claims to be an ISP. The guideline is only intended to check an 176 ISP's network accessibility. In turn, this guideline can also be 177 used as a minimum requirement checklist by ISPs who want to newly 178 turn up IPv6 in their network. 180 3.2. Levels of the Listing 182 We divide the listing into two levels, basic and advanced. Basic 183 level is what is absolutely necessary for any ISP to claim that they 184 have some form of IPv6 working. The basic level will not guarantee 185 that the ISP has a fully working or production quality IPv6 network. 186 The advanced level will take the requirements one step further in 187 bring the level of deployment closer to the quality of the IPv4 188 network. It checks for the basics needed to achieve any of the 189 service types defined in the General Terminology section in 190 [RFC4084]. 192 3.3. Basic 194 The basic level listing checks an ISP to meet the following criteria. 196 o Have an IPv6 prefix allocated or a PI assigned. 198 o Prefix is visible in at least one routing database. 200 o Have at least one server with an IPv6 address where accessibility 201 can be checked. 203 3.4. Advanced 205 The advanced level listing checks an ISP to meet the following 206 criteria. 208 o Reverse DNS for is set up for allocated prefixes. 210 o DNS cache servers are accessible via IPv6 transport. 212 o Path MTU discovery [RFC1981] is functional and is not filtered. 214 o Prefix visibility is seen in at least two routing databases 215 belonging in different regions of the world. 217 3.5. Considerations 219 The listings can be made more useful if checking is done according to 220 the target users of the ISP service. ISP for residential, ISP for 221 ISPs (transit providers), ISP for enterprises, and ISP for data 222 centers have different requirements. This document does not go into 223 discussing the requirements for each type of services are. This 224 document intends to discuss the requirements that should be common to 225 any services provided by any ISP. 227 4. Security Considerations 229 None. 231 5. IANA Considerations 233 None. 235 6. Acknowledgements 237 The author would like to thank the Task Force on IPv4 Address 238 Exhaustion, Japan. Parts of this document was inspired from work by 239 Brian Carpenter and Sheng Jiang. 241 7. References 243 7.1. Normative References 245 7.2. Informative References 247 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 248 for IP version 6", RFC 1981, August 1996. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC4084] Klensin, J., "Terminology for Describing Internet 254 Connectivity", BCP 104, RFC 4084, May 2005. 256 Author's Address 258 Seiichi Kawamura 259 NEC BIGLOBE, Ltd. 260 14-22, Shibaura 4-chome 261 Minatoku, Tokyo 108-8558 262 JAPAN 264 Phone: +81 3 3798 6085 265 Email: kawamucho@mesh.ad.jp