<?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'>
<!ENTITY I-D.mdt-softwire-mapping-address-and-port SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mdt-softwire-mapping-address-and-port-01.xml'>
<!ENTITY I-D.mdt-softwire-map-dhcp-option SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mdt-softwire-map-dhcp-option-01.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-mdt-softwire-map-encapsulation-00"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="MAP Encapsulation (MAP-E)">MAP Encapsulation (MAP-E) - 
    specification</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 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="January" year="2012" />

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

    <abstract>
      <t>This document specifies the &ldquo;Mapping of Address and Port&ldquo;
      (MAP) encapsulation based solution (MAP-E) with an automatic tunneling 
      mechanism for providing IPv4 connectivity service to end users over a
      service provider's IPv6 network.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>MAP-E is a protocol mechanism of the &ldque;Mapping of Address
      and Port&ldquo; (MAP) encapsulation based solution to deploy IPv4
      to sites via a service provider's (SP's) IPv6 network with the
      automatic tunneling mechanism (IPv4-in-IPv6). Similar to Dual-Stack
      Lite <xref target="I-D.ietf-softwire-dual-stack-lite"></xref>,
      MAP-E is designed to allow IPv4 traffic to be delivered over
      an IPv6 network without the direct provisioning of IPv4
      addresses. Like 6rd <xref target="RFC5969"></xref>, MAP-E is
      operated in a fully stateless manner within the SP network.</t>

      <t>MAP-E 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,
      &ldque;Greenfield&ldque; IPv6-only networks may use MAP-E 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>MAP-E utilizes an algorithmic mapping, defined in MAP
      <xref target="I-D.mdt-softwire-mapping-address-and-port"></xref>,
      between the IPv6 and IPv4 addresses that are assigned for use
      within the SP network. This mapping can provide automatic determination
      of IPv6 tunnel endpoints from IPv4 destination addresses, allowing the
      stateless operation of MAP-E. MAP-E 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 MAP algorithmic mapping is also used to automatically
      provision IPv4 addresses and allocating a set of non-overlapping
      ports for each MAP-E CE. The "SP-facing" (i.e., "WAN") side of the
      MAP-E 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 might be implemented as for any native 
      dual-stack service delivered by the SP.</t>

      <t>A MAP-E domain consists of MAP-E Customer Edge (CE) routers and
      one or more MAP-E Border Relays (BRs). IPv4 packets encapsulated
      by MAP-E 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 MAP-E domain. As MAP-E is
      stateless, BRs may be reached using anycast for failover and
      resiliency.</t>

      <t>MAP-E does not require any stateful NAPT <xref target="RFC3022">
      </xref> functions at the BRs or elsewhere within the SP network.
      Instead, MAP-E 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
      MAP-E 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="MAP-E:">Mapping of Address and Port &ndash; Encapsulation
    	mode. MAP-E utilizes a simple IPv4-in-IPv6 tunneling along with the
        MAP extensions for mapping between IPv4 and IPv6 defined in
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>
	and this draft.</t>

	<t hangText="MAP-E domain (Domain):">A set of MAP-E CEs and BRs
	connected to the same virtual MAP-E link. A service provider may
	deploy MAP-E with a single MAP-E domain, or may utilize multiple
	MAP-E domains. Each domain requires a separate MAP-E rule set.</t>

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

	<t hangText="MAP-E Customer Edge (CE):">A device functioning as
	a Customer Edge router in a MAP-E 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 MAP-E CE serving a
	residential site has one WAN side interface, one or more LAN
	side interfaces, and a MAP-E virtual interface. A MAP-E CE may
	also be referred to simply as a "CE" within the context of
	MAP-E.</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>

	<t hangText="MAP-E Rule:">A MAP rule defining the mapping relationship
	for a given MAP-E domain between IPv4 and IPv6, defined in
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>
	</t>

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

    <section title="MAP-E Configuration">
      <t>The IPv4 prefix, IPv4 address or shared IPv4 address for use
      at a customer site is automatically obtained based on BMR defined
      in MAP
      <xref target="I-D.mdt-softwire-mapping-address-and-port"></xref>
      from the IPv6 prefix delegated to the site.</t>

      <t>For a given MAP-E domain, the BR and CE MUST be configured with
      a set of mapping rules (BMR, FMR and DMR) defined in
      <xref target="I-D.mdt-softwire-mapping-address-and-port"></xref>
      . The configured values for these elements MUST be consistent
      for all CEs and BRs within a given MAP-E domain.</t>

      <t>The configuration elements in the set of mapping rules (BMR, FMR
      and DMR) may be provisioned via IPv6 DHCP defined in
      <xref target="I-D.mdt-softwire-map-dhcp-option"></xref> or manually.
      </t>

      <t>The only remaining provisioning information in order to enable
      MAP-E is an IPv6 prefix. This IPv6 prefix is configured as part of
      obtaining IPv6 Internet access (i.e., configured via SLAAC, DHCPv6,
      DHCPv6 PD, manual or otherwise).</t>
    </section>

    <section anchor="behavior" title="MAP-E Node Behavior">
      <section anchor="br-provisioning" title="Provisioning of MAP-E BR">
        <t>The MAP-E BR needs to be provisioned with information for the MAP-E
        domain or domains it is expected to handle, along with any necessary
        routing processes. For each MAP-E domain, the BR will have the
	following parameters:</t>

        <t>o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic
        Mapping Rule)</t>

        <t>o The MAP EA-bits (CE index), including IPv4 suffix, length and
	any port-range (including any excluded ports and the port number
        continuity parameter)</t>

        <t>o The BR prefix and its length (Default Mapping Rule)</t>

        <t>o The subnet ID</t>

        <t>A BR when configured for BMR, FMR and DMR, and performs the
        following functions:</t>

        <t>o Configures the IPv4/IPv6 stateless encapsulation parameters
	(BMR, FMR and DMR)</t>

        <t>Based on the above configuration, the IPv4-in-IPv6 encapsulation
        function can be performed by the BR.</t>

        <t>o Derive IPv4 address along with any applicable port-range from
        IPv4-translatable address (BMR)</t>

        <t>o Derive IPv4-translatable address from IPv4 address and port
	number (FMR)</t>

      </section>

      <section anchor="br-behavior" title="Packet Forwarding Behavior on MAP-E BR">
	<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 (FMR)
          with a specific Domain IPv4 prefix which has the longest match with
          an IPv4 destination address in the received IPv4 packet. If the FMR
          is not found, the received packet should be discarded. If the length
          of Domain IPv4 prefix plus EA-bits associated with the FMR does not
	  exceed 32 bits, BR proceeds to step 2. If the length 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 FMR 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 (BMR) with a specific
	  Domain IPv6 prefix which has the longest match with an IPv6 source address
	  in the received IPv6 packet. If the BMR 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 BMR. 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>
      </section>

      <section anchor="ce-provisioning" title="Provisioning of MAP-E CE">
        <t>A MAP-E CE requires the following parameters for provisioning:</t>

        <t>o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic
        Mapping Rule)</t>

        <t>o The MAP EA-bits (CE index), including IPv4 suffix, length and
	any port-range (including any excluded ports and the port number
        continuity parameter)</t>

        <t>o The BR prefix and its length (Default Mapping Rule)</t>

        <t>A MAP-E CE that receives a MAP DHCP option
	<xref target="I-D.mdt-softwire-map-dhcp-option"></xref> for BMR,
	FMR and DMR and performs the following (MAP initialization)
	functions:</t>

        <t>o Configures the NAT44 port-range mapping function parameters
        (BMR)</t>

        <t>o Configures the IPv4/IPv6 stateless encapsulation parameters
	(BMR, FMR and DMR) Based on the above configuration, the IPv4/IPv6
        encapsulation function can be performed in CE.</t>

        <t>o Derives IPv4 address along with any applicable port-range from
        IPv4-translatable address (BMR)</t>

        <t>o Derives IPv4-translatable address from IPv4 address (FMR)</t>
      </section>

      <section anchor="ce-behavior" title="Packet Forwarding Behavior on MAP-E CE">
        <t>(a) CE reception of an IPv4 packet</t>
	<t><list hangIndent="22" style="hanging">
	  <t hangText="Step 1">CE looks up an appropriate mapping rule (FMR)
	  with a specific Doamin IPv4 prefix which has the longest match with an
	  IPv4 destination address in the received IPv4 packet. If the FMR
	  is found, the length of Domain IPv4 prefix plus EA-bits 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 FMR is not found, CE proceeds to step 2.</t>

	  <t hangText="Step 2">If the FMR 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 FMR. 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 FMR is not found in step 1, CE uses the DMR and then
	  CE encapsulates the IPv4 packet in IPv6 whose destination address is set
	  to the 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>(b) 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 (BMR) with a
	  specific Domain IPv6 prefix which has the longest match with an IPv6
	  source address in the recieved IPv6 packet. If the BMR is found, the
          CE derives a CE IPv6 address from the IPv4 source address or the IPv4
	  source address and the source port based on the BMR and then checks
	  that the IPv6 source address of the received IPv6 packet is matched
	  to it. If the BMR is not found, CE checks that the IPv6 source address
	  is matched to the BR IPv6 address. In case of success, the CE can
  	  decapsulate the IPv4 packet and forward it via the IPv4 interface.</t>
	</list></t>
      </section>
    </section>

    <section title="Deriving IPv6 address from IPv4">
      <section title="Deriving IPv6 address from IPv4 Address and Port Number at the BR">
        <t>IPv6 Source Address and Source Port Number:</t>

        <t>At the BR, the IPv6 source address MUST be set to the BR IPv6
	address as per DMR
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>.
	The source Layer 4 port number MUST be unchanged.</t>

        <t>IPv6 Destination Address and Destination Port Number:</t>

        <t>At the BR, the IPv6 destination address (IPv4-translatable address)
        MUST be derived from the IPv4 destination address and the destination
        port number per FMR
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>.
	The destination Layer 4 port number MUST be unchanged.</t>
      </section>

      <section title="Deriving IPv6 address from IPv4 Address and Port Number at the CE">
        <t>IPv6 Source Address and Source Port Number:</t>

        <t>At the CE, the IPv6 source address (IPv4-translatable address) MUST
        be derived from the IPv4 source address as per BMR
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>.
	The source port number MUST be unchanged.</t>

        <t>IPv6 Destination Address and Destination Port Number:</t>

        <t>At the CE, if Forwarding Mapping Rules (FMRs) are enabled, the IPv4
        packet MUST be checked to see if the IPv4 destination address matches
        the FMR. If matching, the IPv6 destination address (IPv4-converted
        address) MUST be derived from the IPv4 destination address and the
        destination port number as per FMR. Otherwise, the IPv6 destination
        address MUST be set to the BR IPv6 address per DMR
	<xref target="I-D.mdt-softwire-mapping-address-and-port">MAP</xref>.
	The destination port number MUST be unchanged.</t>
      </section>
    </section>

    <section anchor="fragmentation" title="Encapsulation and Fragmentation Considerations">
      <!-- <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>. MAP-E'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 MAP-E 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 MAP-E 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 unless BR's having identical rules
      are required to use disjoint ranges of fragment ID.</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 MAP-E 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 MAP-E Tunnel MTU might
      be set to 1460 bytes.  Absent more specific information, the
      MAP-E Tunnel MTU SHOULD default to 1280 bytes.</t>

      <t>Alternatively, if BR's having identical rule are required
      to use disjoint ranges of fragment ID, a BR using an anycast
      source address SHOULD fragment the IPv6 encapsulated packet
      correctly.</t>

      <t>For MAP-E 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 MAP-E 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. MAP-E
      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 MAP-E 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>

      <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 MAP-E 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="forwarding" title="Packet Forwarding Considerations">
      <section anchor="mesh" title="Mesh model">
        <t>Basically, MAP-E should allow the mesh model in order for all CEs
        to communicate each others directly. If one mapping rules is applied
        to a given MAP-E domain, all CEs can communicate each others directly.
        If multiple mapping rules are applied to a given MAP-E domain, or if
        multiple MAP-E domains are existed, CE can communicate each others
        directly only if all CEs know all mapping rules. When a CE receives
        an IPv4 packet from its LAN side, the CE looks up a mapping rule
        corresponding to an IPv4 destination address in the received IPv4
        packet. If the corresponding mapping rule is found, CE can communicate
        to another CE directly based on the mapping rule defined as Forwarding
        mapping rule (FMR) in
	<xref target="I-D.mdt-softwire-mapping-address-and-port"></xref>
        . If the corresponding mapping rule is not found, CE must forward the
        packet to a given BR.</t>
      </section>
      <section anchor="hub-spoke" title="Hub & Spoke model">
        <t>In order to allow the mesh topology so that all CEs can communicate
        each others directly, all CE should know all mapping rules applied to
        a given MAP-E domain or MAP-E domains. However, if a CE knows only subset
        of mapping rules applied to a given MAP-E domain or MAP-E domains, a CE can
        not communicate to some CEs due to the lack of mapping rules. In this 
        case, an IPv4 packet toward to these CEs must be forwarded to a given
        BR. In order to achieve the hub & spoke mode fully, Forwarding mapping
        rule (FMR) defined in
	<xref target="I-D.mdt-softwire-mapping-address-and-port"></xref>
        should be disabled. In this case, all CEs do not look up the mapping
        rules upon receiving an IPv4 packet from its LAN side and then CE must
        encapsulate the IPv4 packet with IPv6 whose destination must be a given
        BR.</t>
      </section>
    </section>

    <section title="NAT Considerations">
      <t>NAT44 should be implemented in CPE which has MAP-E CE function. The
      NAT44 must conform that best current practice documented in <xref
      target="RFC4787"></xref>, <xref target="RFC5508"></xref> and <xref
      target="RFC5382"></xref>. When there are restricted available port
      numbers in a given MAP-E CE, the NAT44 must restrict mapping ports
      within the port-set.</t>
    </section>

    <section title="ICMP Considerations">
      <t>ICMP message should be supported in MAP-E domain. Hence, the
      NAT44 in MAP-E CE must implement the behavior for ICMP message
      conforming to the best current practice documented in
      <xref target="RFC5508"></xref>.</t>

      <t> If a MAP-E CE receives an ICMP message having ICMP identifier
      field in ICMP header, NAT44 in the MAP-E CE must rewrite this
      field to a specific value assigned from the port-set. 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 MAP-E BR and CE receives an ICMP error message without
      ICMP identifier field for some errors that is detected inside
      a IPv6 tunnel, a MAP-E 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 MAP-E BR and CE obtain the
      origianl IPv6 tunnel packet storing in ICMP payload and then
      decapsulate IPv4 packet. Finally the MAP-E BR and CE generate
      a new ICMP error message from the decapsulated IPv4 packet
      and then forward it.</t>

      <t>If a MAP-E BR receives an ICMP error message on its IPv4 interface,
      the MAP-E BR should replay the ICMP message to an appropriate MAP-E
      CE. If IPv4 address is not shared, the MAP-E 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 MAP-E 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 MAP-E BR can generate the CE
      IPv6 address, the MAP-E 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>), MAP-E does not introduce any
		opportunity for spoofing attack that would not pre-exist in
		IPv6.</t>

	<t hangText="Denial-of-service attacks:">
		In MAP-E domains where IPv4 addresses are shared, the fact that
		IPv4 datagram reassembly may be necessary introduces an
		opportunity for DOS attacks. 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 MAP-E is supported, it is less and less used.</t>

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

	<t hangText="Attacks facilitated by restricted port set:">
		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>. The attacks depend on guessing which
		ports are currently used by target hosts. Using unrestricted port
		set which mean that are IPv6 is exactly preferable. To avoid this
		attacks using restricted port set, NAT44 filtering behavior SHOULD
		be "Address-Dependent Filtering".</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>This draft is based on original idea described in <xref
      target="I-D.despres-softwire-sam"></xref>. The authors would like
      to thank Remi Despres, Mark Townsley, Wojciech Dec and Olivier
      Vautrin.</t>
    </section>
    
  </middle>

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

  <back>
    <references title="Normative References">
      &I-D.mdt-softwire-mapping-address-and-port;
      &I-D.mdt-softwire-map-dhcp-option;
      &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 2012-01-08  TM	Initial version

-->
  </back>
</rfc>
