<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC3068 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-nward-6to4-qualification-00" ipr="trust200902"
     submissionType="independent">
  <front>
    <title abbrev="">6to4 Qualification</title>

    <author fullname="Nathan Ward" initials="N.W." surname="Ward">
      <organization>Braintrust Ltd.</organization>

      <address>
        <postal>
          <street>Level 1, 206 Symonds St.</street>

          <city>Auckland</city>

          <region></region>

          <code>1010</code>

          <country>NZ</country>
        </postal>

        <phone>+64-21-431675</phone>

        <email>nward@braintrust.co.nz</email>
      </address>
    </author>

    <date day="3" month="March" year="2009" />

    <abstract>
      <t>A deployment problem exists with existing self-configuring 6to4
      implementations making often incorrect assumptions about the state of
      their IPv4 network connectivity.</t>

      <t>This document describes the problem, and proposes a qualification
      mechanism by which nodes can validate that their connectivity to the
      global IPv6 network is suitable for use with the 6to4 protocol.</t>
    </abstract>

    <note 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>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>6to4 as described in <xref target="RFC3056">RFC3056</xref> and <xref
      target="RFC3068">RFC3068</xref> is a commonly used method for connecting
      IPv6 capable networks without IPv6 transit to the global IPv6 network
      using automatic tunneling over IPv4, and anycasted relay routers. This
      document refers to a 6to4 router without other IPv6 transit as a 6to4
      node.</t>

      <t>Many implementations of 6to4 are automatically configured. The
      assumption is made that if a 6to4 node has a public (i.e. globally
      routable) IPv4 address, it is capable of 6to4, and the 6to4 interface
      and default route via the well known 6to4 relay address is automatically
      configured. Some of these implementations exist in end systems, and some
      implementations exist in mass market CPE devices.</t>

      <t>In reality, however, a public IPv4 address may be subject to IPv4
      NAT, or some kind of firewalling which restricts the ability for a 6to4
      node to exchange 6to4 packets with other 6to4 nodes and 6to4 relay
      routers. In this case, 6to4 should not be used.</t>

      <t>This document defines a mechanism for a 6to4 node to qualify the
      suitability of its IPv4 network connection for use with 6to4.</t>
    </section>

    <section title="Test Nodes">
      <t>There are two new special nodes that MUST connect to the 6to4
      network, and respond to ICMPv6 echo-request messages in certain ways.
      Anyone MAY run these test nodes, their usage scope MAY be limited by
      filtering advertisements for TBD1 and TBD2.</t>

      <section title="Symmetric Test Node">
        <t>The symmetric test node is a typical node with a 6to4 interface,
        which MUST have 2002::/16 routed to its 6to4 interface.</t>

        <t>The host MUST have connectivity to the global IPv4 network. The TBD
        prefix MUST be advertised to any networks for which this host is to
        provide a 6to4 qualification symmetric testing service.</t>

        <t>Connectivity to the IPv6 network is not required. Routes to subnets
        of 2002::/16 MUST NOT exist on the host.</t>

        <t>A packet filter MAY be configured to allow only IP protocol 41
        (0x29) to and from TBD1(IPv4). A packet filter MAY be configured to
        prevent any other packets to and from other addresses in the TBD1
        prefix.</t>

        <t>TBD1 SHOULD be routed to the host, and the host MUST null-route
        this prefix if so.</t>

        <t>The host MUST have an IPv4 interface with the address TBD1(IPv4).
        TBD1(IPv4) MUST be routed to the host.</t>

        <t>The host MUST have a 6to4 interface configured with the IPv6
        address TBD1(6to4) and the local IPv4 address TBD1(IPv4).</t>

        <t>The host MUST reply to ICMPv6 echo request messages received on the
        6to4 interface.</t>
      </section>

      <section title="Asymmetric Test Node">
        <t>The asymmetric test node is a typical node with a 6to4 interface,
        which MUST have 2002::/16 routed to its 6to4 interface.</t>

        <t>The host MUST have connectivity to the global IPv4 network, and a
        6to4-capable IPv4 address.</t>

        <t>The host MUST have connectivity to an IPv6 network, including
        typically at least one 6to4 relay. Routes to subnets of 2002::/16 MUST
        NOT exist on the host. TBD2 must be advertised to networks with 6to4
        relays for which this host is to provide a 6to4 qualification
        asymmetric testing service.</t>

        <t>The host MUST have an IPv6 interface configured with the address
        TBD2(1).</t>

        <t>TBD2 SHOULD be routed to the host, and the host MUST null-route
        this prefix if so.</t>

        <t>The host MUST have a 6to4 interface configured with the IPv6
        address corresponding to a locally assigned IPv4 address. The host
        MUST NOT use 192.88.99.1 as the local IPv4 address for the 6to4
        interface.</t>

        <t>The host MUST reply to ICMPv6 echo request messages destined to
        TBD2(1) when the source IPv6 address is in the 2002::/16 prefix.</t>
      </section>
    </section>

    <section title="Qualification">
      <t>Two similar tests are performed by sending ICMPv6 echo request
      message encapsulated in IPv4, and waiting for a response. This can be
      trivially implemented in software on most platforms as a low priority
      process, as it does not require a large amount of processing power.</t>

      <t>Sections 3.1 through 3.4 are the 4 steps in the qualification
      process, and SHALL be performed in order. The qualification process
      SHOULD be run at regular intervals to ensure reliable 6to4
      connectivity.</t>

      <section title="Initial Interface Configuration">
        <t>When a new IPv4 address becomes available that is suspected of
        being suitable for 6to4 use (candidate IPv4 address), the 6to4
        interface is configured with the appropriate address based on the
        candidate IPv4 address, with a 128-bit prefix length, and the
        following IPv6 routes:</t>

        <texttable>
          <ttcol>Destination</ttcol>

          <ttcol>Next-hop or connected interface</ttcol>

          <c>2002:C058:6301::/48</c>

          <c>Connected via 6to4 interface</c>

          <c>TBD1(6to4)</c>

          <c>Connected via 6to4 interface</c>

          <c>TBD2</c>

          <c>Next-hop via 2002:C058:6301::</c>
        </texttable>

        <t></t>
      </section>

      <section title="Symmetric Test">
        <t>The 6to4 node sends an ICMPv6 echo request message to TBD1(6to4)
        from its 6to4 IPv6 address. The 6to4 encapsulation will have an IPv4
        destination address of TBD1(IPv4), and a source address of the
        candidate IPv4 address.</t>

        <t>A symmetric test node responds to this ICMPv6 message normally.</t>

        <t>The 6to4 node receives an ICMPv6 echo response message encapsulated
        in IPv4 with the candidate IPv4 address as the destination, and
        TBD1(IPv4) as the source.</t>

        <t>If the 6to4 node does not receive this message within a timeout the
        candidate IPv4 address SHALL be considered unusable and this test run
        SHALL cease. Failure at this stage MAY mean an IPv4 firewall is in
        place.</t>

        <t>If the 6to4 node receives this message, qualification testing
        SHOULD proceed to the asymmetric test phase.</t>
      </section>

      <section title="Asymmetric Test">
        <t>The 6to4 node sends an ICMPv6 echo request message to TBD2 from its
        6to4 IPv6 address. The 6to4 encapsulation will have an IPv4
        destination address of 192.88.99.1, and a source address of the
        candidate IPv4 address.</t>

        <t>An asymmetric test node responds to this ICMPv6 message
        normally.</t>

        <t>The 6to4 node receives an ICMPv6 echo response message encapsulated
        in IPv4. The encapsulation MUST have the candidate IPv4 address as the
        destination address, and an IPv4 address that is not 192.88.99.1 as
        the source address.</t>

        <t>If the 6to4 node does not receive this message within a timeout the
        candidate IPv4 address SHALL be considered unusable and this test run
        SHALL cease. Failure at this stage MAY mean a stateful IPv4 firewall
        and possibly IPv4 NAT is in place.</t>

        <t>If the 6to4 node receives this message, the candidate IPv4 address
        SHOULD be considered usable, and the interface SHOULD be configured as
        per the Full Configuration section.</t>
      </section>

      <section title="Full Configuration">
        <t>Once a 6to4 node has an IPv4 address suitable for 6to4 use, the
        following routes are installed:</t>

        <texttable>
          <ttcol>Destination</ttcol>

          <ttcol>Next-hop or connected interface</ttcol>

          <c>2002::/16</c>

          <c>Connected via 6to4 interface</c>

          <c>::/0</c>

          <c>Next-hop via 2002:C058:6301::</c>
        </texttable>

        <t>The Symmetric Test and Asymmetric Test phases are performed
        periodically. If either of these tests fail the 2002::/16 route is
        withdrawn.</t>
      </section>
    </section>

    <section title="Examples">
      <t>The following are diagrams of example test scenarios.</t>

      <section title="Symmetric Test Pass">
        <figure>
          <artwork><![CDATA[           2002:C000:0201::/48        TBD1(6to4)           
+---------+192.0.2.1                  TBD1(IPv4)+---------+
|6to4 node|-------------------1---------------->|Symmetric|
|         |<------------------2-----------------|Test Node|
+---------+                                     +---------+]]></artwork>
        </figure>

        <t>1) 6to4 node sends ICMPv6 echo request message to TBD1(6to4).</t>

        <t>2) Symmetric test node responds, and response is received by 6to4
        node.</t>
      </section>

      <section title="Symmetric Test Failure">
        <figure>
          <artwork><![CDATA[           2002:C000:0201::/48        TBD1(6to4)           
+---------+192.0.2.1                  TBD1(IPv4)+---------+
|6to4 node|-------------------1---------------->|Symmetric|
|         |     FIREWALL<-----2-----------------|Test Node|
+---------+                                     +---------+]]></artwork>
        </figure>

        <t>1) 6to4 node sends ICMPv6 echo request message to TBD1(6to4).</t>

        <t>2) Symmetric test node responds, and response is not received by
        6to4 node because an intermediary firewall restriction.</t>
      </section>

      <section title="Asymmetric Test Pass">
        <figure>
          <artwork><![CDATA[           2002:C000:0201::/48                              
+---------+192.0.2.1                            +---------+ 
|6to4 node|---------------1-------------------->|6to4     | 
|         |<----------------         192.88.99.1|Relay    | 
+---------+                 \                   +---------+ 
                             \                      |       
                              \                     |       
                               3                    2       
                                \                   |       
                                 \                  |       
                                  \                 v       
                                   \            +----------+
                                    ------------|Asymmetric|
                                      Local IPv4|Test Node |
                                            TBD2+----------+]]></artwork>
        </figure>

        <t>1) 6to4 node sends ICMPv6 echo request message to TBD2 via 6to4
        relay.</t>

        <t>2) 6to4 relay decapsulates IPv6 packet and forwards to closest
        asymetric test node.</t>

        <t>3) Asymmetric test node responds to ICMPv6 message over 6to4 with
        source address of its local IPv4 interface, and response is received
        by 6to4 node.</t>
      </section>

      <section title="Asymmetric Test Failure">
        <figure>
          <artwork><![CDATA[           2002:C000:0201::/48                              
+---------+192.0.2.1                            +---------+ 
|6to4 node|---------------1-------------------->|6to4     | 
|         |     FIREWALL<---         192.88.99.1|Relay    | 
+---------+                 \                   +---------+ 
                             \                      |       
                              \                     |       
                               3                    2       
                                \                   |       
                                 \                  |       
                                  \                 v       
                                   \            +----------+
                                    ------------|Asymmetric|
                                      Local IPv4|Test Node |
                                            TBD2+----------+]]></artwork>
        </figure>

        <t>1) 6to4 node sends ICMPv6 echo request message to TBD2 via 6to4
        relay.</t>

        <t>2) 6to4 relay decapsulates IPv6 packet and forwards to closest
        asymetric test node.</t>

        <t>3) Asymmetric test node responds to ICMPv6 message over 6to4 with
        source address of its local IPv4 interface. A stateful firewall
        prevents the packet reaching 6to4 node.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests the assignment of two prefixes:</t>

      <section title="Symmetric Test Prefix">
        <t>A 24-bit IPv4 prefix, TBD1. Only one IPv4 address is used, however
        24 bits is likely to be widely accepted in BGP peering sessions.</t>

        <t>Note to editor: TBD1 is used in two ways in this document,
        TBD1(IPv4) and TBD1(6to4):</t>

        <t>- TBD1(IPv4) is an IPv4 address in this prefix with 1 in the host
        part, ie AAA.BBB.CCC.1/32</t>

        <t>- TBD1(6to4) is an IPv6 address in the 6to4 prefix corresponding to
        TBD1(6to4) with 1 in the host part, ie. 2002:AABB:CCDD::1</t>
      </section>

      <section title="Asymmetric Test Prefix">
        <t>A 32-bit IPv6 prefix, TBD2. Only one IPv6 address is used, however
        32 bits is likely to be widely accepted in BGP peering sessions.</t>

        <t>Note to editor: TBD2(1) refers to an address in this prefix with 1
        in the host part, ie. AAAA:BBBB::1.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Unknown at this time.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC3056;

      &RFC3068;
    </references>
  </back>
</rfc>
