<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC4084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4084.xml">
<!ENTITY RFC5211 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5211.xml">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-kawamura-ipv6-isp-listings-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="IPv6 ISP Listings">A Basic Guideline for Listing ISPs that Run IPv6</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Seiichi Kawamura" initials="S.K." 
            surname="Kawamura">
      <organization>NEC BIGLOBE, Ltd.</organization>

      <address>
        <postal>
          <street>14-22, Shibaura 4-chome</street>

          <!-- Reorder these if your country does things differently -->

          <city>Minatoku</city>

          <region>Tokyo</region>

          <code>108-8558</code>

          <country>JAPAN</country>
        </postal>

        <email>kawamucho@mesh.ad.jp</email>

        <!-- uri and facsimile elements may also be added -->
      </address>

    </author>
    <author fullname="Edward J. Jankiewicz" initials="E.J.J." 
            surname="Jankiewicz">
      <organization>SRI International, Inc.</organization>

      <address>
        <postal>
          <street>333 Ravenswood Ave</street>

          <!-- Reorder these if your country does things differently -->

          <city>Menlo Park</city>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>edward.jankiewicz@sri.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2010" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>IPv6</keyword>
    <keyword>ISP</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
      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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
      There are many web sites that give listings of IPv6 enabled service providers, or rate ISPs according to their IPv6 enabledness. <xref target="appendixA"></xref> gives examples of these.

</t>

      <t>
      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.
      </t>

      <t>
      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.
      </t>

        <section title="Requirements Language">
          <t>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 <xref
          target="RFC2119">RFC 2119</xref>.</t>
        </section>
    </section>

    <section title="Examples of Listing Criteria">

      <section title="IPv6 Enabled Program">
          <t>
          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.
          </t>
          <t>
The IPv6 Enabled Program checks the following.
          </t>

        <section title="Network Accessibility">
          <t>
        The ISP's AS number is checked against a database to see if the AS exists and is unique.
          </t>
        </section>

        <section title="Active IPv6 Address Requirement">
          <t>
        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.
          </t>
        </section>

        <section title="Persistence of IPv6 Service Reachability">
          <t>
        The check noted in the previous section is done periodically to check global reachability.
          </t>
        </section>
        </section>

        <section title="IPv6 Ripeness">
          <t>
 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. 
          </t>

        <section title="Criteria">
          <t>
        Stars are earned by checking the following criteria.
          </t>
          <t><list style="symbols">
            <t>Have an IPv6 prefix allocated or a PI assigned.</t>
            <t>Prefix is visible in the Routing Information System(RIS).</t>
            <t>A route6 object is registered in the RIPE database.</t>
            <t>Reverse DNS is setup for the IPv6 prefix.</t>
          </list></t>
        </section>
      </section>

    <section title="Summary of the Checking Criteria">

      <t>The programs discussed in this section share these criteria in common. 
          </t>
          <t><list style="symbols">
            <t>Have an IPv6 prefix allocated or a PI assigned.</t>
            <t>Prefix is visible in a routing database.</t>
          </list></t>

      <t>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.
      </t>

      </section>

  </section>



    <section title="Guidelines for Listing an IPv6 Enabled ISP">
        <section title="Scope of the Guideline">
  <t>
  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.
  </t>

        </section>
        <section title="Levels of the Listing">
          <t>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 <xref target="RFC5211"></xref> 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.</t>

          <t>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 <xref target="RFC5211"></xref> section 2.2 as TRANS1+TRANS2+TRANS3 and to the extent possible the capabilities defined as SHOULD.</t> 

           <t>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 <xref target="RFC4084"></xref>.</t>

           <t>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 <xref target="RFC5211"></xref> section 2.3 as POST1+POST2+POST3.
</t>

        </section>
        <section title="Experimental">
          <t>The Experimental level listing checks an ISP to meet the following criteria.</t>
          <t><list style="symbols">
            <t>Have an IPv6 prefix allocated or a PI assigned.</t>
            <t>Prefix is visible in at least one routing database.</t>
            <t>Have at least one server with an IPv6 address where accessibility can be checked.</t>
          </list></t>
        </section>
        <section title="Basic">
          <t>The Basic level listing checks an ISP to meet the following criteria.</t>
          <t><list style="symbols">
            <t>Reverse DNS for is set up for allocated prefixes.</t>
            <t>DNS cache servers are accessible via IPv6 transport.</t>
            <t>Path MTU discovery <xref target="RFC1981"></xref> is functional and is not filtered.</t>
            <t>Prefix visibility is seen in at least two routing databases belonging in different regions of the world.</t>
            <t>Some form of support is available to customers and to operators
      that want to contact the ISP on an issue that cannot be resolved
      within their network.</t>
            <t>Mail exchange(MX) servers are accessible via IPv6.</t>
          </list></t>
        </section>

        <section title="Advanced">
          <t>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.</t>

          <t><list style="symbols">
          <t>The capabilities described in Basic level MUST be available to all customers by default.</t>
          <t>Full support for IPv6 services comparable to support for IPv4 services MUST be available to all customers and operators.</t>
          <t>All public websites provided by the ISP for customer and other operators SHOULD be accessible from an IPv6-only client.</t>
</list></t>
        </section>

        <section title="Considerations">
          <t>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.</t>


        </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This draft does not introduce any new Security Considerations.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      &RFC5211;
    </references>

    <references title="Informative References">
      &RFC1981;
      &RFC2119;
      &RFC4084;
    </references>


    <section anchor="appendixA" title="Links to Listing Programs">
    <t>  Below are some programs that list IPv6 enabled service providers.</t>
      <t><list style="empty">
      <t>IPv6 Enabled Program http://ipv6forum.org/ipv6_enabled/</t>
      <t>IPv6 Ripeness http://labs.ripe.net/content/ipv6-ripeness/</t>
      <t>SixXS http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers</t>
      <t>IPv6 to Standard http://www.ipv6-to-standard.org/</t>
      <t>Hurricane Electric IPv6 Progress Report http://bgp.he.net/ipv6-progress-report.cgi</t>
      </list></t>
    </section>


  </back>
</rfc>



