draft-despres-softwire-4rd.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC4953 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4953.xml">
<!ENTITY RFC5569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5569.xml">
<!ENTITY RFC5961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
<!ENTITY RFC5969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC6056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC2491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2491.xml">
<!ENTITY I-D.despres-softwire-sam SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-despres-softwire-sam-01.xml'>
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml'>
<!ENTITY I-D.ietf-v6ops-tunnel-loops SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-tunnel-loops.xml'>
<!ENTITY I-D.ymbk-aplusp SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp'>
<!ENTITY I-D.operators-softwire-stateless-4v6-motivation SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.operators-softwire-stateless-4v6-motivation'>

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-xxxx-softwire-4rd-00"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="IPv4 Residual Deployment">IPv4 Residual Deployment
    on IPv6 infrastructure - protocol specification</title>


   <author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
      <organization>IP Infusion</organization>
      <address>
	    <postal>
          <street>1188 East Arques Avenue</street>
	      <city>Sunnyvale</city>
	      <country>USA</country>
	    </postal>
	    <email>tetsuya@ipinfusion.com</email>
      </address>
    </author>

 
    <author fullname="Ole Troan" initials="O." surname="Troan">
      <organization>cisco</organization>
      <address>
        <postal>
          <street></street>
          <city>Oslo</city>
          <country>Norway</country>
        </postal>
        <email>ot@cisco.com</email>
      </address>
    </author>

	<!---
    <author fullname="Remi Despres" initials="R." surname="Despres">
      <organization>RD-IPtech</organization>
      <address>
        <postal>
          <street>3 rue du President Wilson</street>
          <city>Levallois</city>
          <country>France</country>
        </postal>
        <email>remi.despres@free.fr</email>
      </address>
    </author>

    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization>SoftBank</organization>
      <address>
	    <postal>
          <street>1-9-1 Higashi-Shinbashi, Munato-ku</street>
	      <city>Tokyo</city>
	      <country>Japan</country>
	    </postal>
	    <email>satoru.matsushima@tm.softbank.co.jp</email>
      </address>
    </author>
    
    --->

    <date month="June" year="2011" />

    <area>Internet</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword></keyword>

    <abstract>
      <t>This document specifies an automatic tunneling mechanism for
      providing IPv4 connectivity service to end users over a service
      provider's IPv6 network. Key aspects include stateless
      operation, sharing of IPv4 addresses, and an algorithmic mapping
      between IPv4 addresses and IPv6 tunnel endpoints.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>4rd is a protocol mechanism to deploy IPv4 to sites via a
      service provider's (SP's) IPv6 network.  Similar to Dual-Stack
      Lite <xref target="I-D.ietf-softwire-dual-stack-lite"></xref>,
      4rd is designed to allow IPv4 traffic to be delivered over an
      IPv6 network without the direct provisioning of IPv4
      addresses. 4rd can provide an IPv4 prefix, an IPv4 address or a
      shared IPv4 address. Like 6rd <xref target="RFC5969"></xref>,
      4rd is operated in a fully stateless manner within the SP
      network. The motivation for a stateless alternative to
      Dual-Stack Lite is described in "Motivations for Stateless IPv4
      over IPv6 Migration Solutions" <xref
      target="I-D.operators-softwire-stateless-4v6-motivation"></xref>.
      </t>

      <t>4rd relies on IPv6 and is designed to deliver
      production-quality dual-stack service while allowing IPv4 to be
      phased out within the SP network. The phasing out of IPv4 within
      the SP network is independent of whether the end user disables
      IPv4 service or not.  Further, "Greenfield" IPv6-only networks
      may use 4rd in order to deliver IPv4 to sites via the IPv6
      network in a way that does not require protocol translation
      between IPv4 and IPv6.</t>

      <t>4rd utilizes an algorithmic mapping between the IPv6 and IPv4
      addresses that are assigned for use within the SP network. This
      mapping provides automatic determination of IPv6 tunnel
      endpoints from IPv4 destination addresses, allowing the
      stateless operation of 4rd. 4rd views the IPv6 network as a link
      layer for IPv4 and supports an automatic tunneling abstraction
      similar to the Non-Broadcast Multiple Access (NBMA) <xref
      target="RFC2491"></xref> model.</t>

      <t>The 4rd algorithmic mapping is also used to automatically
      provision IPv4 addresses and allocating a set of non-overlapping
      ports for each 4rd CE.  The "SP-facing" (i.e., "WAN") side of
      the 4rd CE, operate as native IPv6 interface with no need for
      IPv4 operation or support. On the "end-user-facing" (i.e.,
      "LAN") side of a CE, IPv6 and IPv4 are implemented as for any
      native dual-stack service delivered by the SP.</t>

      <t>A 4rd domain consists of 4rd Customer Edge (CE) routers and
      one or more 4rd Border Relays (BRs). IPv4 packets encapsulated
      by 4rd follow the IPv6 routing topology within the SP network
      between CEs and among CEs and BRs. CE to CE traffic is direct,
      while BRs are traversed only for IPv4 packets that are destined
      to or are arriving from outside a given 4rd domain. As 4rd is
      stateless, BRs may be reached using anycast for failover and
      resiliency.</t>

      <t>4rd does not require any stateful NAPT <xref
      target="RFC3022"></xref> functions at the BRs or elsewhere
      within the SP network. Instead, 4rd allows for sharing of IPv4
      addresses among multiple sites by automatically allocating a set
      of non-overlapping ports for each CE as part of the stateless
      mapping function. It is expected that the CE will, in turn,
      perform local IPv4 Network Address and Port Translation (NAPT)
      <xref target="RFC3022"></xref> functions for the site as is
      commonly performed today, except avoiding ports outside of the
      allocated port set. Although 4rd is designed primarily to
      support IPv4 deployment to a customer site (such as a
      residential home network) by an SP, it can equally be applied to
      an individual host acting as a CE router.</t>
    </section>

    <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 title="Terminology">
      <t><list hangIndent="22" style="hanging">
	<t hangText="4rd domain (Domain):">A set of 4rd CEs and BRs
	connected to the same virtual 4rd link. A service provider may
	deploy 4rd with a single 4rd domain, or may utilize multiple
	4rd domains. Each domain requires a separate 4rd prefix.</t>

	<t hangText="4rd Border Relay (BR):">A 4rd-enabled router
	managed by the service provider at the edge of a 4rd domain.
	A Border Relay router has at least one of each of the
	following: an IPv6-enabled interface, a 4rd virtual interface
	acting as an endpoint for the 4rd IPv4 in IPv6 tunnel, and an
	IPv4 interface connected to the native IPv4 network. A 4rd BR
	may also be referred to simply as a "BR" within the context of
	4rd.</t>

	<t hangText="4rd Customer Edge (CE):">A device functioning as
	a Customer Edge router in a 4rd deployment. In a residential
	broadband deployment, this type of device is sometimes
	referred to as a "Residential Gateway" (RG) or "Customer
	Premises Equipment" (CPE). A typical 4rd CE serving a
	residential site has one WAN side interface, one or more LAN
	side interfaces, and a 4rd virtual interface. A 4rd CE may
	also be referred to simply as a "CE" within the context of
	4rd.</t>

        <t hangText="CE IPv6 prefix:">The IPv6 prefix assigned to a CE by
	other means than 4rd itself, and used by 4rd to derive a CE 4rd
	prefix.</t>

        <t hangText="CE IPv6 address:">The IPv6 address given to the
        CE as part of normal IPv6 Internet access. This address is
        used by a 4rd CE to create the 4rd prefix as well as to send
        and receive IPv6-encapsulated IPv4 packets.</t>

        <t hangText="CE 4rd prefix:">The 4rd prefix of the CE. It is
        derived from the CE IPv6 prefix by a mapping rule according to
        <xref target="mapping-rules"></xref>. Depending on its length,
        it is an IPv4 prefix, an IPv4 address, or a shared IPv4
        address followed by a Port-set ID (<xref
        target="port-set-id"></xref>).</t>

        <t hangText="Port-set ID:">In a CE 4rd prefix longer than 32
        bits, bits that follow the first 32.  It algorithmically
        identifies a set of ports exclusively assigned to the CE. As
        specified in Section <xref target="port-set-id"></xref>, the set
        can comprise up to 4 disjoint port ranges.</t>

        <t hangText="Domain IPv6 prefix:">An IPv6 prefix assigned by an ISP to
	a 4rd domain.</t>

        <t hangText="Domain IPv4 prefix:">A 4rd prefix assigned by an
        ISP to the 4rd domain.</t>

        <t hangText="IPv4 Embedded Address (EA) bits:">The IPv4
        EA-bits in the IPv6 address identify an IPv4 prefix, IPv4
        address or part of IPv4 address and port set.</t>

	<t hangText="Shared IPv4 address:">An IPv4 address that is
	shared among multiple nodes. Each node has a separate part of
	the transport layer port space.</t>

      </list></t>
    </section>

    <section title="4rd Configuration">
      <t>The IPv4 prefix, IPv4 address or shared IPv4 address for use
      at a customer site is created by extracting the IPv4 embedded
      address (EA-bits) from the IPv6 prefix delegated to the
      site. Combined with the 4rd IPv4 prefix, the IPv4 prefix, IPv4
      address or shared IPv4 address is automatically created by the
      CE for the customer site when IPv6 service is obtained.</t>

      <t>For a given 4rd domain, the BR and CE MUST be configured with
      a set of mapping rules and BR IPv6 addresses. The configured
      values for these elements MUST be identical for all CEs and BRs
      within a given 4rd domain.</t>

      <t>A mapping rule consist of the following elements: a Domain
      IPv6 prefix and prefix length, a Domain 4rd prefix and prefix
      length, EA-bits length, and a Domain IPv6 suffix and length.
      See <xref target="mapping-rules">section</xref> for a detailed
      description of mapping rules.</t>

      <section title="Customer Edge Configuration">

	<t>The 4rd configuration elements are set to values that are
	the same across all CEs within a 4rd domain. The values may be
	configured in a variety of manners, including provisioning
	methods such as the Broadband Forum's "TR-69" [TR069]
	Residential Gateway management interface, an XML-based object
	retrieved after IPv6 connectivity is established, a DNS
	record, an SMIv2 MIB [RFC2578], or manual configuration by an
	administrator. A companion document [ref] describes how to
	configure the necessary parameters via IPv6 DHCP. A CE that
	allows IPv6 configuration by IPv6 DHCP SHOULD implement this
	option. Other configuration and management methods may use the
	format described by this option for consistency and
	convenience of implementation on CEs that support multiple
	configuration methods.</t>

	<t>The only remaining provisioning information the CE requires
	in order to calculate the 4rd address and enable IPv6
	connectivity is an IPv6 prefix for the CE. This CE IPv6 prefix
	is configured as part of obtaining IPv6 Internet access (i.e.,
	configured via SLAAC, DHCPv6, DHCPv6 PD, or otherwise).</t>

	<t>A single 4rd CE MAY be connected to more than one 4rd
	domain. Each domain a given CE operates within would require
	its own set of 4rd configuration elements and would generate
	its own 4rd address.</t>

      </section>
    </section>

    <section anchor="mapping-rule-parameters" title="Algorithmic mapping">

      <section anchor="mapping-rules" title="Mapping Rules">
        <section anchor="mapping-prefix" title="From a CE IPv6 Prefix to a CE 4rd Prefix">
          <t>A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes
   	  and CE 4rd prefixes.</t>

          <figure align="center" anchor="prefix-fig" title="From a CE IPv6 Prefix to a CE 4rd Prefix">
            <preamble></preamble>

            <artwork align="center"><![CDATA[
<---------------- CE IPv6 prefix (max 128) -------------->
+-------------------------------+------------------------+
|      Domain IPv6 prefix       |        EA-bits         |
+-------------------------------+------------------------+
<-- Domain IPv6 Prefix length ->:<--  EA-bits length  -->:
                                :                        :
                                :         ||             :
                                :         \/             :
                                :                        :
                                :<--  EA-bits length  -->:
            +-------------------+------------------------+
            | Domain 4rd prefix |        EA-bits         |
            +-------------------+------------------------+
            <----------- CE 4rd prefix (max 47) --------->
            ]]></artwork>

          </figure>

          <t>A CE derives its CE 4rd prefix from the CE IPv6 prefix,
          using parameters of the applicable mapping rule. If the
          domain has several mapping rules, the rule that applies is
          that whose Domain IPv6 prefix has the longest match with the
          CE IPv6 prefix. As shown in Figure 1, the CE 4rd prefix is
          created by concatenating the Domain 4rd prefix with the IPv4
          EA-bits, where the IPv4 EA-bits is the remainder of the CE
          IPv6 prefix after the Domain IPv6 prefix (the length of the
          Domain IPv6 prefix is defined by the mapping rule).</t>

        </section>

        <section anchor="port-set-id" title="From a CE 4rd Prefix to a Port-set ID">
	  <t>Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a
     	  full IPv4 address, or a shared IPv4 address followed by a Port-set ID
          (<xref target="port-set-id-fig"></xref>). If it includes a port set ID,
	  this ID specifies which ports are assigned to the the CE for its exclusive
	  use (<xref target="port-set"></xref>).</t>

          <figure align="center" anchor="port-set-id-fig" title="Variants of CE 4rd prefixes">
            <preamble></preamble>

            <artwork align="center"><![CDATA[
                     <-- CE 4rd prefix length -->
                     +--------------------------+- - -+
Shorter than 32 bits |       IPv4 prefix        | ... |
                     + -------------------------+- - -+
                     <--------------- 32 ------------->


                     <----- CE 4rd prefix length ----->
                     +--------------------------------+
      32 bits        |          IPv4 address          |
                     +--------------------------------+
                     <--------------- 32 ------------->


                     <----------- CE 4rd prefix length ---------->
                     +-------------------------------+-----------+
    33 to 47 bits    |      IPv4 shared address      |Port-set ID|
                     +-------------------------------+-----------+
                     <--------------- 32 -----------><- max 15 -->
            ]]></artwork>

          </figure>
	</section>

	<section anchor="port-set" title="From a Port-Set ID to a Port Set">
	  <!-- 
	  *** The naive encoding would be to use the port part of the
	  EA-bits to directly identify port ranges. But that would
	  require IPv6 provisioning specifically to avoid the 0-4096
	  port range. The following algorithm allows for a equal
	  distribution of ports avoiding the lower port range while
	  having no dependency of IPV6 provisioning.
	  ***
	  -->

	  <t>The value of a Port-set ID specifies which ports can be
	  used by a transport layer protocol (UDP, TCP, SCTP
	  etc). Design constraint of the algorithm are the
	  following:</t>

          <t><list hangIndent="22" style="hanging">
	    <t hangText="Fairness with respect to special-value ports:">
	    No port-set must contain any well-known ports [IANA reference].</t>

	    <t hangText="Fairness with respect to the number of ports">
	    For a Port-set-ID's having the same length, all sets must have
            the same number of ports.</t>

	    <t hangText="Exhaustiveness">
	    For any Port-set-ID length, the aggregate of port sets
	    assigned for all values must include all ordinary-value
	    ports.</t>
	  </list></t>

	  <t>If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges.
          As shown in Figure 3, each port range is defined by its port prefix,
          made of a range-specific "head" followed by the Port-set ID.  Head
          values are in binary 1, 01, 001, and 0001.  They are chosen to
          exclude ports 0-4095 and only them.</t>

          <figure align="center" anchor="port-range-fig" title="From Port-set ID to Port ranges">
            <preamble></preamble>
            <artwork align="center"><![CDATA[
                <------- Port (16 bits) -------->
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range a    |1|x x x x x x x x|             |  0xF780 - 0xF7FF
 (head = 1)     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   \               \
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range b    |0 1|x x x x x x x x|           |  0x7BC0 - 0x7BFF
 (head = 01)    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     \               \
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range c    |0 0 1|x x x x x x x x|         |  0x3DE0 - 0x3DFF
 (head = 001)   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       \               \
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range d    |0 0 0 1|x x x x x x x x|       |  0x1EF0 - 0x1EFF
 (head = 0001)  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                <- head-><--Port-set ID->                 /\
                <-- Port-range prefix --><-tail->         ||
                                                          ||
                                             Example of Port-ranges
                                           if the Port-set ID is 0xEF
            ]]></artwork>
          </figure>

	  <t>In the Port-set ID has 13 bits, only the 3 port ranges are assigned,
          having heads 1, 01, and 001.  If it has 14 bits, only the 2 port
   	  ranges having heads 1 and 01 are assigned. If it has 15 bits, only
   	  the port range having head 1 is assigned. (In these three cases, the
   	  smallest port range has only one element).</t>

	</section>

	<section anchor="address-mapping" title="From an IPv4 Address or IPv4 Address + Port to a CE IPv6 Address">
	  
          <figure align="center" anchor="address-mapping-fig" title="From 4rd Prefix to IPv6 address (shared IPv4 address case)">
            <preamble></preamble>
            <artwork align="center"><![CDATA[
                    Port-set ID
                         |
   <--- CE 4rd prefix ---|->
   +---------------+---+-|--+
   |IPv4 shared address| '  |
   +---------------+---+----+
                   <-------->
                  EA-bit length
                   :        :
                   :   ||   :
                   :   ||   :
                   :   \/   : Domain IPv6 suffix
                   :        :  |
+------------------+--------+--|-+----------------------------------+
|Domain IPv6 prefix| EA-bits|  ' |                  0               |
+------------------+--------+----+----------------------------------+
<------------ max 64 ------------>
<---------------------- CE IPv6 address (128) --------------------->
            ]]></artwork>
          </figure>

	  <t>In order to find whether a CE IPv6 address can be derived from an
	  IPv4 address, or an IPv4 address + a port, a mapping rule has to be
   	  found that matches the IPv4 information:</t>

	  <t><list style="symbols">
	    <t>If a mapping rule has a length L of CE IPv4 prefixes which does
            not exceed 32 bits, there is a match if the IPv4 address starts
            with the Domain 4rd prefix. The CE 4rd prefix is then the first L
            bits of the IPv4 address.</t>

	    <t>If a mapping rule has a length L of CE IPv4 prefixes which exceeds
            32 bits, the match can only be found with the IPv4 address and the
            port. For this, the port is examined to determine which port-
      	    range head it starts with: 1, 01,001, or 0001. The N bits that
            follow this head are taken as Port-set ID, where N is the length
            of Port set ID of the mapping rule. The CE 4rd prefix is then
            made of the IPv4 address followed by the Port-set ID.</t>
	  </list></t>

	  <t>If a match has been found, the CE IPv6 prefix is then made of the
	  Domain IPv6 prefix followed by bits of the CE 4rd prefix that
          follow the Domain 4rd prefix, followed by the Domain IPv6 prefix
          of the mapping rule if there is one, and followed by 0's up to 128
          bits to make a complete IPv6 address (<xref target="RFC4291"></xref>.
	  <xref target="address-mapping-fig"></xref>
          illustrates this process in the case of a shared IPv4 address.</t>
	</section>
      </section>
      </section>

      <section anchor="fragmentation" title="Encapsulation and Fragmentation Consideration">
	<!-- <section title="Maximum Transmission Unit"> -->

	<t>Maximum transmission unit (MTU) and fragmentation issues
	for IPv4 in IPv6 tunneling are discussed in detail in Section
	7.2 of <xref target="RFC2473"></xref>. 4rd's scope is limited to
        a service provider network. IPv6 Path MTU discovery MAY be used
        to adjust the MTU of the tunnel as described in Section 7.2 of
	<xref target="RFC2473"></xref>, or the 4rd Tunnel MTU might be
        explicitly configured.</t>

	<t>The use of an anycast source address could lead to any ICMP
	error message generated on the path being sent to a different
	BR. Therefore, using dynamic tunnel MTU Section 7.2 of
        <xref target="RFC2473"></xref> is subject to IPv6 Path MTU
        blackholes.</t>

	<t>Multiple BRs using the same anycast source address could
	send fragmented packets to the same 4rd CE at the same time.
	If the fragmented packets from different BRs happen to use the
	same fragment ID, incorrect reassembly might occur. For this
	reason, a BR using an anycast source address MUST NOT fragment
        the IPv6 encapsulated packet.</t>

	<t>If the MTU is well-managed such that the IPv6 MTU on the CE
	WAN side interface is set so that no fragmentation occurs
	within the boundary of the SP, then the 4rd Tunnel MTU should
	be set to the known IPv6 MTU minus the size of the
	encapsulating IPv6 header (40 bytes). For example, if the
	IPv6 MTU is known to be 1500 bytes, the 4rd Tunnel MTU might
	be set to 1460 bytes.  Absent more specific information, the
	4rd Tunnel MTU SHOULD default to 1280 bytes.</t>

	<t>For 4rd domain traversal, IPv4 packets are encapsulated in
	IPv6 packets whose Next header is set to 4 (i.e.  IPv4). If
	fragmentation of IPv6 packets is needed, it is performed
	according to <xref target="RFC2460"></xref>. Absent more specific
	information, the path MTU of a 4rd Domain has to be set to 1280
	<xref target="RFC2460"></xref>.</t>

	<t>In domains where IPv4 addresses are not shared, IPv6 destinations
	are derived from IPv4 addresses alone. Thus, each IPv4 packet can be
	encapsulated and decapsulated independently of each other. 4rd
	processing is completely stateless.</t>

	<t>On the other hand, in domains where IPv4 addresses are shared, BR's
	and CE's can have to encapsulate IPv4 packets whose IPv6 destinations
	depend on destination ports. Precautions are needed, due to the fact
	that the destination port of a fragmented datagram is available only
	in its first fragment. A sufficient precaution consists in
	reassembling each datagram received in multiple packets, and to treat
	it as though it would have been received in single packet. This
	function is such that 4rd is in this case stateful at the IP layer.
	(This is common with DS-lite and NAT64/DNS64 which, in addition, are
	stateful at the transport layer.)  At Domain entrance, this ensures
	that all pieces of all received IPv4 datagrams go to the right IPv6
	destinations.</t>

	<!-- *** A sender must rewrite it's identifier field to match -->
	<!-- part of its own port range. Replace below.  -->

	<t>Another peculiarity of shared IPv4 addresses is that, without
	precaution, a destination could simultaneously receive from different
	sources fragmented datagrams that have the same Datagram ID (the
	Identification field of <xref target="RFC0791"></xref>. 
	This would disturb the reassembly process. To eliminate this risk,
        CE MUST rewrite the datagram ID to an unique value among CEs having
        same shared IPv4 address upon sending the packets over 4rd tunnel.
        This value SHOULD be generated locally within the port-range assigned
	to a given CE. Note that replacing a Datagram ID in an IPv4 header
	implies an update of its Header-checksum fieald, by adding to it the
	one's complement difference between the old and the new values.</t>
      </section>

      <section anchor="behavior" title="BR and CE behaviors">
	<!-- *** merge single and multiple mapping rules -->
	<!-- *** how many mapping entries do you need? -->
	<!-- *** add text for doing longest match. -->

        <!--
        <section anchor="one-mapping-rule-behavior" title="Domains having only One Mapping rule">
        -->
	  <t>(a) BR reception of an IPv4 packet</t>
	  <t><list hangIndent="22" style="hanging">
	    <t hangText="Step 1">BR looks up an appropriate mapping rule with
	    a specific Domain 4rd prefix which has the longest match with an
	    IPv4 destination address in the received IPv4 packet. If the mapping
            rule is not found, the received packet should be discarded. If the
	    length of CE 4rd prefix associated with the mapping rule does not
	    exceed 32 bits, BR proceeds to step 2. If the length of CE 4rd prefix
	    exceeds 32 bits, BR checks that the received packet contains a complete
	    IPv4 datagram. If the packet is fragmented, BR should reassemble the
	    packet. Once BR can obtain the complete IPv4 datagram, BR proceeds to
	    step 2 as though the datagram has been received in a single packet.</t>

	    <t hangText="Step 2">BR generates a CE IPv6 address from the IPv4
	    destination address or the IPv4 destination address and the destination
	    port based on the mapping rule found in step 1. If the CE IPv6 address
	    can be successfully generated, BR encapsulates the IPv4 packet in IPv6
	    and forwards the IPv6 packet via the IPv6 interface. If the length of
	    the IPv6 encapsulated packet exceeds the MTU of the IPv6 interface,
	    the fragmentation should be done in IPv6.</t>
	  </list></t>

	  <t>(b) BR reception of an IPv6 packet</t>
	  <t><list hangIndent="22" style="hanging">
	    <t hangText="Step 1">If the received IPv6 packet is fragmented, the
	    reassembly should be done in IPv6 at first. Once BR obtains a complete
	    IPv6 packet, BR looks up an appropriate mapping rule with a specific
	    Domain 4rd prefix which has the longest match with an IPv4 source address
	    in the encapsulated IPv4 packet. If the mapping rule is not found, the
	    received IPv6 packet should be discarded. BR derives a CE IPv6 address
	    from the IPv4 source address or the IPv4 source address and the source
	    port in the encapsulated IPv4 packet based on the mapping rule. If the
	    CE IPv6 address is eqaul to the IPv6 source address in the received IPv6
	    packet, BR decapsulates the IPv4 packet and then forward it via the IPv4
	    interface.</t>
	  </list></t>

	  <t>(c) CE reception of an IPv4 packet</t>
	  <t><list hangIndent="22" style="hanging">
	    <t hangText="Step 1">CE looks up an appropriate mapping rule with
	    a specific Doamin 4rd prefix which has the longest match with an
	    IPv4 destination address in the received IPv4 packet. If the mapping
	    rule is found, the CE 4rd prefix must be checked. If the length
	    does not exceeds 32 bits, CE proceeds to step 2. If the length
	    exceeds 32 bits, CE checks that the received IPv4 packet contains a
	    complete IPv4 datagram. If the packet is fragmented, CE should reassemble
	    the packet. Once CE can obtain the complete IPv4 datagram, CE proceeds
	    to step 2 as though the datagram has been received in a single packet.
	    If the mapping rule is not found, CE proceeds to step 2.</t>

	    <t hangText="Step 2">If the mapping rule is found in step 1, CE derives
	    a IPv6 destination address from the IPv4 destination address or the IPv4
	    destination address and the destination port based on the mapping rule.
	    If the IPv6 destination address can be derived successfully, CE encapsulates
	    the IPv4 packet in IPv6 whose destination address is set to the derived
	    IPv6 address. If the mapping rule is not found in step 1, CE encapsulates
	    the IPv4 packet in IPv6 whose destination address is set to BR IPv6 address.
	    Then CE forwards the IPv6 packet via IPv6 interface. If the length of
	    the IPv6 packet exceeds the MTU of the IPv6 interface, the fragmentation
	    should be done in IPv6. Moreover, if using IPv4 shared address, a Datagram
	    ID in the received IPv4 header must be over-written before encapsulating
	    the IPv4 packet in IPv6. In case of shared IPv4 address, the Datagram ID 
            must be unique among CEs sharing the same IPv4 address. Hence, CE should
            assign the unique value and set this value to the datagram ID in IPv4 header.
	    This value may be generated from the port-range assigned to the CE to keep
	    the uniqueness among CEs sharing same IPv4 address.</t>
	  </list></t>

	  <t>(d) CE reception of an IPv6 packet</t>
	  <t><list hangIndent="22" style="hanging">
	    <t hangText="Step 1">If the received IPv6 packet is fragmented, the
	    reassembly should be done in IPv6 at first. Once CE obtains a complete
	    IPv6 packet, CE looks up an appropriate mapping rule with s specific
	    Domain 4rd prefix which has the longest match with an IPv4 source
	    address in the encapsulated IPv4 packet. If the mapping rule is found,
	    CE derives a CE IPv6 address from the IPv4 source address or the IPv4
	    source address and the source port based on the mapping rule and then
	    checks that the IPv6 source address of the received IPv6 packet is
	    matched to it. If the mapping rule is not found, CE checks that the
	    IPv6 source address is matched to BR IPv6 address. In case of success,
	    CE decapsulates the IPv4 packet and forward it via the IPv4 interface.</t>
	  </list></t>
        <!--
	</section>
        -->

<!-- 	<section anchor="multiple-mapping-rule-behavior" title="Domains having Multiple Mapping Rules"> -->
<!-- 	  <t>Some ISP will want to use 4rd in networks having several Domain 4rd -->
<!--           prefixes, an/or several Domain IPv6 prefixes, and/or assigning CE 4rd -->
<!--    	  prefixes of different lengths.  For this several mapping rules are -->
<!--    	  needed.</t> -->

<!-- 	  <t>A first possibility consists in establishing several 4rd domains, -->
<!--    	  each on having a single mapping rule. In this case, paths between -->
<!--    	  CE's belonging to different 4rd domains go from one domain to the -->
<!--    	  other in IPv4, and cross two BR's.</t> -->

<!-- 	  <t>A second possibility permits direct IPv6 paths between CE's by -->
<!--    	  supporting several mapping rules in a single domain, as described in -->
<!--     	  this section.  At time of writing, whether this will be in the 4rd -->
<!--     	  specification a MAY, a SHOULD, or a MUST, remains an open question.</t> -->

<!-- *** it MUST be a MUST -->


<!-- 	  <t>(a) BR reception of an IPv4 packet</t> -->
<!-- 	  <t><list hangIndent="22" style="hanging"> -->
<!-- 	    <t hangText="Step 1">If a mapping rule whose length of CE 4rd prefixes does not -->
<!--             exceed 32 bits applies to the IPv4 destination, the BR proceeds to step 2.  -->
<!-- 	    Otherwise, and unless the packet contains a complete IPv4 datagram, IPv4 datagram -->
<!--             reassembly is performed.  If a complete datagram is available, the BR then proceeds -->
<!-- 	    to step 2 as though the datagram had been received in a single packet.</t> -->

<!-- 	    <t hangText="Step 2">The BR checks that the IPv4 source doesn't start with the -->
<!--             Domain 4rd prefix of any rule.  In case of success, the packet is encapsulated -->
<!-- 	    and forwarded to this CE IPv6 address via the IPv6 interface.</t> -->
<!-- 	  </list></t> -->

<!-- 	  <t>(b) BR Reception of an IPv6 packet (reassembled if applicable)</t> -->
<!-- 	  <t><list hangIndent="22" style="hanging"> -->
<!-- 	    <t hangText="Step 1">The BR checks that a CE IPv6 address is successfully -->
<!--             derived from the source of the IPv4 encapsulated packet, and that the source -->
<!-- 	    address of the encapsulating packet is equal to it. In case of success, the -->
<!-- 	    BR tries to derive a CE IPv6 address from the destination of the encapsulated -->
<!--             packet. In case of success: (1) if the source CE 4rd prefix exceeds 32 bits, -->
<!-- 	    the Datagram ID of the packet is replaced by a locally generated one; (2) the -->
<!-- 	    encapsulating packet is retransmitted via the IPv6 interface with this CE IPv6 -->
<!-- 	    address as destination (and the BR IPv6 address as source address); in case of -->
<!-- 	    failure, the IPv4 packet is decapsulated and forwarded via the IPv4 interface.</t> -->
<!-- 	  </list></t> -->

<!-- 	  <t>(c) CE reception of an IPv4 packet</t> -->
<!-- 	  <t><list hangIndent="22" style="hanging"> -->
<!-- 	    <t hangText="Step 1">If the CE 4rd prefix of the CE does not exceed 32 bits, -->
<!--             and a mapping rule whose length of CE 4rd prefixes does not exceed 32 bits -->
<!-- 	    applies to the IPv4 destination, the CE proceeds to step 2. Otherwise, and -->
<!-- 	    unless the packet contains a complete IPv4 datagram, IPv4 datagram reassembly -->
<!-- 	    is performed. If a complete datagram is available, the BR then proceeds to step -->
<!-- 	    2 as though the datagram had been received in a single packet.</t> -->

<!-- 	    <t hangText="Step 2">The CE tries to derive a CE IPv6 address from the IPv4 -->
<!--             destination. It then encapsulates the IPv4 packet into an IPv6 packet whose -->
<!-- 	    destination is this CE IPv6 address, if one is obtained, or the BR IPv6 address -->
<!-- 	    otherwise.</t> -->
<!-- 	  </list></t> -->

<!-- 	  <t>(d) CE reception of an IPv6 packet (reassembled if applicable)</t> -->
<!-- 	  <t><list hangIndent="22" style="hanging"> -->
<!-- 	    <t hangText="Step 1">The CE checks that a CE IPv6 address is successfully -->
<!--             derived from the source of the IPv4 encapsulated packet, and that it is -->
<!-- 	    equal to the source address of the encapsulating packet. In case of success: -->
<!-- 	    (1) if the source CE 4rd prefix exceeds 32 bits, the Datagram ID of the packet -->
<!-- 	    is replaced by a locally generated one; (2) the IPv4 packet is decapsulated -->
<!-- 	    and forwarded via the IPv4 interface.</t> -->
<!--  	  </list></t> -->

<!-- 	  <t>NOTE: With consistency check made between encapsulated and -->
<!-- 	  encapsulating sources in BR's and CE's when they received tunneled -->
<!--    	  packets, no CE can forward an invalid IPv4 source address, or address -->
<!--    	  plus port, and have it forwarded at by the egress BR or CE. Yet, if -->
<!--     	  before tunneling a packet, a CE makes an additional check that the -->
<!--    	  IPv4 source is consistent with the CE IPv6 address, it can discard -->
<!--    	  invalid packets earlier than by leaving it to the egress BR or CE. -->
<!--    	  At time of writing, whether this test can remain a MAY, or might -->
<!--    	  require a SHOULD or a MUST remains an open question.</t> -->
<!-- 	</section> -->
    </section>

    <section title="NAT considerations">
      <t>The port-restricted NAT44 must be implemented in 4rd CE. 4rd
      CE must implement the behavior conforming to the best current
      practice documented in <xref target="RFC4787"></xref>,
      <xref target="RFC5508"></xref> and <xref target="RFC5382"></xref>. 
      The available port number in NAT44 in a given 4rd CE should be
      restricted in the port-set described in
      <xref target="port-set"></xref>.</t>
    </section>

    <section title="ICMP">
      <!-- *** NEW -->
      <!-- CE on sending will have to set ICMP identifier field on -->
      <!-- outgoing. -->
      <!-- Section 8 of 2473 for incoming ICMP errors on BR. -->
      <!-- Reference RFC5508??? -->
      <t>ICMP message should be supported in 4rd domain. Hence, the
      NAT44 in 4rd CE must implement the behavior for ICMP message
      conforming to the best current practice documented in
      <xref target="RFC5508"></xref>.</t>

      <t> If a 4rd CE receives an ICMP message having ICMP identifier
      field in ICMP header, NAT44 in the 4rd CE must rewrite this
      field to a specific value assigned from the port-set described
      in <xref target="port-set"></xref>. BR and other CEs must handle
      this field similar to the port number in tcp/udp header upon
      receiving the ICMP message with ICMP identifier field.</t>

      <t>If a 4rd BR and CE receives an ICMP error message without
      ICMP identifier field for some errors that is detected inside
      a IPv6 tunnel, a 4rd BR and CE should replay the ICMP error
      message to the original source. This behavior should be
      implemented conforming to the section 8 of
      <xref target="RFC2473"></xref>. The 4rd BR and CE obtain the
      origianl IPv6 tunnel packet storing in ICMP payload and then
      decapsulate IPv4 packet. Finally the 4rd BR and CE generate
      a new ICMP error message from the decapsulated IPv4 packet
      and then forward it.</t>

      <t>If a 4rd BR receives an ICMP error message on its IPv4 interface,
      the 4rd BR should replay the ICMP message to an appropriate 4rd
      CE. If IPv4 address is not shared, the 4rd BR generates a CE IPv6
      address from the IPv4 destination address in the ICMP error message
      and encapsulates the ICMP message in IPv6. If IPv4 address is shared,
      the 4rd BR derives an original IPv4 packet from the ICMP payload and
      generates a CE IPv6 address from the source address and the source
      port in the original IPv4 packet. If the 4rd BR can generate the CE
      IPv6 address, the 4rd BR encapsulates the ICMP error message in IPv6
      and then forward it to its IPv6 interface.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t><list hangIndent="22" style="hanging">
	<t hangText="Spoofing attacks">
	With consistency checks between IPv4 and IPv6 sources that are
        performed on IPv4/IPv6 packets received by BR's and CE's
        (<xref target="behavior"></xref>), 4rd does not introduce any
	opportunity for spoofing attack that would not pre-exist in IPv6.</t>

	<t hangText="Denial-of-service attacks">
	In 4rd domains where IPv4 addresses are shared, the fact that IPv4
        datagram reassembly may be necessary introduces an opportunity for
        DOS attacks (Section 4.4).  This is inherent to address sharing,
        and is common with other address sharing approaches such as DS-
        lite and NAT64/DNS64. The best protection against such attacks is
	to accelerate IPv6 enablement in both clients and servers so that,
	where 4rd is supported, it is less and less used.</t>

	<t hangText="Routing-loop attacks">
	Routing-loop attacks that may exist in some
	automatic-tunneling scenarios are documented in <xref
	target="I-D.ietf-v6ops-tunnel-loops"></xref>.  They cannot
	exist with 4rd because each BRs checks that the IPv6 source
	address of a received IPv6 packet is a CE address <xref
	target="mapping-rules"></xref>.</t>

	<t hangText="Attacks facilitated by restricted port sets">
	From hosts that are not subject to ingress filtering of
	<xref target="RFC2827"></xref>, some attacks are possible by
	intervening with faked packets during ongoing transport connections
	(<xref target="RFC4953"></xref>, <xref target="RFC5961"></xref>,
	<xref target="RFC6056"></xref>.
        These attacks, that have mitigations of their own are easier with
        hosts that only use restricted port sets (they depend on guessing
        which ports are currently used by target hosts).  To avoid using
        restricted port sets, the easiest approach consists in increasing
        the proportion of connections that are IPv6, i.e. using
        unrestricted port sets.</t>
      </list></t>
    </section>

    <section anchor="iana" title="IANA Consideration">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="acknowledgements" title="Acknowledgements">
      <t>The authors wish to thank Mark Townsley for his active encouragements
      to pursue the 4rd approach since it was first introduced in
      <xref target="I-D.despres-softwire-sam"></xref>. Questions raised by Wojciech
      Dec have been useful to clarify explanations. Olivier Vautrin, who
      independently proposed a similar approach with the same acronym
      deserves special recognition.</t>
    </section>
    
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC0791;
      &RFC2119;
      &RFC2460;
      &RFC3315;
      &RFC4291;
      &RFC2491;
    </references>

    <references title="Informative References">
      &I-D.despres-softwire-sam;
      &I-D.ietf-softwire-dual-stack-lite;
      &I-D.ietf-v6ops-tunnel-loops;
      &RFC2473;
      &RFC2827;
      &RFC3022;
      &RFC4787;
      &RFC4953;
      &RFC5382;
      &RFC5508;
      &RFC5961;
      &RFC5969;
      &RFC6056;
      &I-D.operators-softwire-stateless-4v6-motivation;
    </references>

    <!-- Change Log

v00 2011-04-08  TM	Initial version
v01 2011-06-23  OT	Revised version from Berlin discussion

-->
  </back>
</rfc>