<?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 RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC3513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC6145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.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.despres-softwire-sam SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-despres-softwire-sam-01.xml'>
<!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'>
]>

<?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-murakami-softwire-4v6-translation-00"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="4via6-stateless-translation">4via6 Stateless Translation</title>

    <author fullname="Tetsuya Murakami" initials="T." surname="Murakami" role="editor">
      <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 initials="G. Chen" surname="Chen" fullname="Gang Chen">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>53A,Xibianmennei Ave., </street>
          <street>Xuanwu District,</street>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>chengang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Hui Deng" initials="H" surname="Deng">
      <organization>China Mobile</organization>   
      <address>
        <postal>
          <street>53A,Xibianmennei Ave.</street>
          <city>Beijing </city>
          <code>100053</code>
          <country>P.R.China</country>
        </postal>        
        <phone>+86-13910750201</phone>        
        <email>denghui02@gmail.com</email>
      </address>
    </author>

    <author fullname="Wojciech Dec" initials="W" surname="Dec">
      <organization>Cisco Systems</organization>   
      <address>
        <postal>
          <street>Haarlerbergpark Haarlerbergweg 13-19</street>
          <city>Amsterdam, NOORD-HOLLAND</city>
          <code>1101 CH</code>
          <country>Netherlands</country>
        </postal>        
        <phone></phone>        
        <email>wdec@cisco.com</email>
      </address>
    </author>

    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization>SoftBank Telecom</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="July" year="2011" />

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

    <abstract>
      <t>This document specify 4via6, a solution for IPv4 connectivity across
      IPv6 network utilizes 4rd algorithmic address mapping rule as a series
      of stateless IPv4 over IPv6 migration solutions. 4via6 employ stateless
      address translation techniques. It is useful for operators who want to
      provide IPv4 connectivity across restricted bandwidth IPv6 network with
      stateless operation.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>4via6 is a solution utilizes the same algorithmic address mapping
      rule between IPv4 addresses and IPv6 addresses defined in <xref
      target="I-D.murakami-softwire-4rd">4rd</xref>. 4via6 employ stateless
      address translation techniques well specified in <xref
      target="RFC6145"></xref> with the mapping rule in order to communicate
      IPv4 islands across IPv6 network, instead of IPv6 encapsulation
      mechanism in 4rd. Address mapping rule defined in <xref
      target="RFC6052"></xref> is also employed to preserve correspondant
      address of outside 4via6 domain.</t>
      
      <t>Since additional IP header is required and the size of the packet is
      increasing in encapsulation solutions, limited bandwidth resource in a
      network would be consumed by un-negligible overhead. It is undesirable
      in that has that limitation like wireless network. 4via6 is useful for
      operators who want to provide IPv4 connectivity across restricted
      bandwidth IPv6 network with stateless operation described in <xref
      target='I-D.operators-softwire-stateless-4v6-motivation'></xref>.</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="4via6 domain (Domain):">A set of 4via6 CEs and BRs
	connected to the same virtual link. A service provider may
	deploy 4via6 with a single 4via6 domain, or may utilize multiple
	4via6 domains. Each domain requires a separate 4via6 prefix.</t>

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

	<t hangText="4via6 Customer Edge (CE):">A device functioning as
	a Customer Edge router in a 4via6 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 4via6 CE adopting 4rd rules
        will serve a residential site with one WAN side interface, one or
        more LAN side interfaces. A 4via6 CE may also be referred to simply
        as a "CE" within the context of 4via6.</t>
	
<!--
        <t hangText="4via6 IPv6 prefix:">The IPv6 prefix assigned to a CE 
        by other means than 4rd itself, and used by 4rd to derive a CE 4via6
	prefix.</t>

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

        <t hangText="4rd prefix:">The 4via6 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 4via6 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 4via6 domain.</t>

        <t hangText="Domain IPv4 prefix:">A IPv4 prefix assigned by an ISP to
        the 4via6 domain.</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="4via6 Translation Framework">
     
      <t>Figure 1 depicts the overall architecture with IPv4 users networks
      connected through routed IPv6 networks. Therein, IPv4 users are
      connected to IPv6 network via CPE with 4via6 translation modules.</t> 
    
      <figure align="center" anchor="topology" title="Network Topology">
       <preamble></preamble>
       <artwork align="center">><![CDATA[
    Private IPv4
   |  Network
   |
O-------------------O
|        CPE        |
| +-------+-------+ |
| | NAT44 | 4via6 | |
| |       |  CE   | |\
| +-------+-------+ | \    ,-------.                     /------.
|                   |  \,-'         `-.               ,-/       `-.
O-------------------O /   Routed      \  O---------O /   Public    \
                     /    IPv6         \ |         |/     IPv4      \
                    |    Network       --+  4via6  +-   Network     |
                     \                /  |   BR    |\               /
                      \              /   O---------O \             /
                       ".         ,-'                  `-.       ,-'
                         `-------'                        `------'
        ]]></artwork>
      </figure>
 
      <t>4via6 CE has two functionalities. The first is to generate an IPv4 address
      or an shared IPv4 address and port-set. The second is to translate an IPv4 packet
      from/to an IPv6 packet across IPv6 network.</t>

      <t>When an unique IPv6 prefix is assigned to each CPE from SP's network, 4via6
      CE in the CPE generates IPv4 address or shared IPv4 address and port-set with
      4rd address mapping rule defined in 
      <xref target="I-D.murakami-softwire-4rd"></xref>.</t>

      <t>The address mapping rule is also used in 4via6 CE to forward the packets.
      When 4via6 CE sends a packet to BR, the source address is translated from IPv4
      to IPv6 address with 4rd mapping rule and the destination address is translated
      from IPv4 to IPv6 address with <xref target="RFC6052"></xref>. In the case of
      sending the packet to another CE, the destination address is translated with
      4rd address mapping rule.</t>

      <t> NAT44 must be implemented in 4via6 CPE with the behavior conforming to the
      best current practice documented in <xref target="RFC4787"></xref>,
      <xref target="RFC5508"></xref> and <xref target="RFC5382"></xref>. The NAT44
      must translate the port number into the port-set generated in a given 4via6 CE.</t>

      <t>At a BR side, when the BR sends a packet to a CE, the source address is
      translated from IPv4 to IPv6 address with <xref target="RFC6052"></xref> and
      the destination address is translated from IPv4 to IPv6 with 4rd mapping rule.</t>

    </section>

    <section title="Stateless Translation Algorithm" anchor="stateless-translation">
      <t>The stateless translation between IPv6 and IPv4 must conform to
      <xref target="RFC6145"></xref>. The address mapping rule must be based on
      <xref target="I-D.murakami-softwire-4rd"></xref> and
      <xref target="RFC6052"></xref>.</t>

      <t>In 4via6 stateless translation, the only difference is the forwarding mechanism
      across IPv6 network infrastructure. The automatic tunneling mechanism such as
      IPv4-in-IPv6 is used in <xref target="I-D.murakami-softwire-4rd"></xref>. Instead,
      for the outband direction, the source address is translated with 4rd mapping rule
      and the destination address is translated with <xref target="RFC6052"></xref>. From
      the inbound direction, the source address is translated with <xref target="RFC6052"></xref>
      and the destination address is translated with 4rd mapping rule. For the direct
      communication among CEs, both source address and destination address are translated
      with only 4rd mapping rule.</t>
    </section>

    <section title="Behavior of 4via6 Stateless Translation ">
      <section anchor="packet-forwarding" title="Behavior on 4via6 CE">
 
        <t>A 4via6 CE that receives IPv4 packets from CE LAN side checks the validity
        of its source and destination address. It also checks that the packet size
        is acceptable. If yes, NAT44 changes the IPv4 source address and the source
        port to its generated global IPv4 address and the port within the generated
        port-range. After that, 4via6 CE performs the translation of IPv4 source address
        and IPv4 destination address. The IPv4 source address is changed to the IPv6
        address that is assigned to the 4via6 CE. The IPv4 destination address is
        translated based on <xref target="RFC6052"></xref>. And the IPv4 header is
        replaced to the IPv6 header that is generated from the IPv4 header based on
        <xref target="RFC6145"></xref>.</t>

        <t>The 4via6 CE that receives IPv6 packet from CE WAN side checks the validity
        of its source and destination address. It also checks that the packet size
        is acceptable. If yes, it translates the IPv6 source and the IPv6 destination 
        address in the received packets. The IPv6 destination address is changed to
        the IPv4 address that is generated in the 4via6 CE based on
        <xref target="I-D.murakami-softwire-4rd"></xref>. The IPv6 source address is
        translated based on <xref target="RFC6052"></xref>. After that, the IPv6 header
        is replaced to the IPv4 header that is generated from the IPv6 header based on
        <xref target="RFC6145"></xref>.</t>
      </section>

      <section title="Behavior on 4via6 BR">
        <t>A 4rd BR that receives IPv4 packets from the outside IPv4 network checks
        the validity of its source and destination address. It also checks that
        the packet size is acceptable. If yes, it generates the IPv6 destination
        address from the IPv4 destination address based on
        <xref target="I-D.murakami-softwire-4rd"></xref> and translates the IPv4
        source address to the IPv6 source address based on
        <xref target="RFC6052"></xref>. As the result, the IPv4 header is replaced
        to the IPv6 header based on <xref target="RFC6145"></xref>.</t>

        <t>The 4rd BR that receives IPv6 packets from IPv6 network infrastructure
        checks the validity of its source and destination address. It also checks
        that the packet size is accpetable. If yes, it generates the IPv4 source
        address from the IPv6 source address based on
        <xref target="I-D.murakami-softwire-4rd"></xref> and translates the IPv6
        destination address to the IPv4 destination address based on
        <xref target="RFC6052"></xref>. As the result, the IPv6 header is replaced
        to the IPv4 header based on <xref target="RFC6145"></xref>.</t>
      </section>
    </section>

    <section anchor="pmtu-consideration" title="Path MTU and Fragmentation Consideration">
      <t>Basically, Path MTU and Fragmentation must confirm to Section 1.4 of
      <xref target="RFC6145"></xref>.</t>

      <t>In 4via6 stateless transition, a 4via6 BR and a 4via6 CE replace an IPv6 header
      to an IPv4 header in a received IPv6 packet upon forwarding the packet to a native
      IPv4 interface. If the size of the IPv4 packet might exceed to the IPv4 MTU on the
      native IPv4 interface, the 4via6 BR and the 4via6 CE might fragment the packet. In
      order for the receiver to reassemble the fragmented packet correctly, the 4via6 BR
      and the 4via6 CE must assign an unique value to a datagram ID in IPv4 header upon
      forwarding the packet to the native IPv4 interface.</t>
    </section>

    <section anchor="diff-4rd" title="Comparison with 4rd">
      <t>Differing from encapsulation model, translation approach doesn't need to know BR
      IPv6 address. Instead of that, a IPv6 mapping prefix should be delivered to 4via6
      CPEs or 4via6 hosts for generating IPv6 address by catenating IPv4 destination
      address with IPv6 mapping prefix. Such IPv6 mapping prefix shall be either the
      "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization
      deploying the address translators.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The security consideration is same as
      <xref target="I-D.murakami-softwire-4rd"></xref>.</t>
    </section>

    <section anchor="iana" title="IANA Consideration">
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="acknowledgements" title="Acknowledgements">
    </section>

  </middle>

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

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC2460;
      &RFC4291;
      &RFC6052;
      &RFC6145;
<!--
      &I-D.murakami-softwire-4rd;
-->

      <reference anchor="I-D.murakami-softwire-4rd">
        <front>
          <title>IPv4 Residual Deployment on IPv6 infrastructure - protocol specification (work in progress)</title>
          <author initials="T." surname="Murakami" fullname="Tetsuya Murakami">
            <organization abbrev="IPI">
            IP Infusion, Inc
            </organization>
          </author>
          <author initials="T." surname="Troan" fullname="Ole Troan">
            <organization abbrev="Cisco">
            Cisco
            </organization>
          </author>
          <date month="June" year="2011"/>
        </front>
      </reference>

    </references>

    <references title="Informative References">
      &I-D.despres-softwire-sam;
      &I-D.ietf-softwire-dual-stack-lite;
      &I-D.operators-softwire-stateless-4v6-motivation;
      &RFC1918;
      &RFC3513;
      &RFC4787;
      &RFC5382;
      &RFC5508;
    </references>

<!-- Change Log

v00 2011-06-27  TM	Initial version

-->
  </back>
</rfc>
