draft-ietf-softwire-map-t-05.txt   draft-ietf-softwire-map-t-06.txt 
Network Working Group X. Li Network Working Group X. Li
Internet-Draft C. Bao Internet-Draft C. Bao
Intended status: Experimental CERNET Center/Tsinghua University Intended status: Experimental CERNET Center/Tsinghua University
Expires: August 14, 2014 W. Dec, Ed. Expires: April 17, 2015 W. Dec, Ed.
O. Troan O. Troan
Cisco Systems Cisco Systems
S. Matsushima S. Matsushima
SoftBank Telecom SoftBank Telecom
T. Murakami T. Murakami
IP Infusion IP Infusion
February 10, 2014 October 14, 2014
Mapping of Address and Port using Translation (MAP-T) Mapping of Address and Port using Translation (MAP-T)
draft-ietf-softwire-map-t-05 draft-ietf-softwire-map-t-06
Abstract Abstract
This document specifies the "Mapping of Address and Port" stateless This document specifies the "Mapping of Address and Port" stateless
IPv6-IPv4 Network Address Translation (NAT64) based solution IPv6-IPv4 Network Address Translation (NAT64) based solution
architecture for providing shared or non-shared IPv4 address architecture for providing shared or non-shared IPv4 address
connectivity to and across an IPv6 network. connectivity to and across an IPv6 network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on April 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. MAP-T Packet Forwarding . . . . . . . . . . . . . . . . . . . 9 8. MAP-T Packet Forwarding . . . . . . . . . . . . . . . . . . . 9
8.1. IPv4 to IPv6 at the CE . . . . . . . . . . . . . . . . . 9 8.1. IPv4 to IPv6 at the CE . . . . . . . . . . . . . . . . . 9
8.2. IPv6 to IPv4 at the CE . . . . . . . . . . . . . . . . . 10 8.2. IPv6 to IPv4 at the CE . . . . . . . . . . . . . . . . . 10
8.3. IPv6 to IPv4 at the BR . . . . . . . . . . . . . . . . . 11 8.3. IPv6 to IPv4 at the BR . . . . . . . . . . . . . . . . . 11
8.4. IPv4 to IPv6 at the BR . . . . . . . . . . . . . . . . . 11 8.4. IPv4 to IPv6 at the BR . . . . . . . . . . . . . . . . . 11
9. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 9. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Fragmentation and Path MTU Discovery . . . . . . . . . . . . 12 10. Fragmentation and Path MTU Discovery . . . . . . . . . . . . 12
10.1. Fragmentation in the MAP domain . . . . . . . . . . . . 12 10.1. Fragmentation in the MAP domain . . . . . . . . . . . . 12
10.2. Receiving IPv4 Fragments on the MAP domain borders . . . 12 10.2. Receiving IPv4 Fragments on the MAP domain borders . . . 12
10.3. Sending IPv4 fragments to the outside . . . . . . . . . 13 10.3. Sending IPv4 fragments to the outside . . . . . . . . . 12
11. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 13 11. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 13
12. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13 12. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13
12.1. EA-bit length 0 . . . . . . . . . . . . . . . . . . . . 13 12.1. EA-bit length 0 . . . . . . . . . . . . . . . . . . . . 13
12.2. Mesh and Hub and spoke modes . . . . . . . . . . . . . . 13 12.2. Mesh and Hub and spoke modes . . . . . . . . . . . . . . 13
12.3. Communication with IPv6 servers in the MAP-T domain . . 14 12.3. Communication with IPv6 servers in the MAP-T domain . . 13
12.4. Compatibility with other NAT64 solutions . . . . . . . . 14 12.4. Compatibility with other NAT64 solutions . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
17.1. Normative References . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . 16 17.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Examples of MAP-T translation . . . . . . . . . . . 19 Appendix A. Examples of MAP-T translation . . . . . . . . . . . 18
Appendix B. Port mapping algorithm . . . . . . . . . . . . . . . 22 Appendix B. Port mapping algorithm . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Experiences from initial service provider IPv6 network deployments, Experiences from initial service provider IPv6 network deployments,
such as [RFC6219], indicate that successful transition to IPv6 can such as [RFC6219], indicate that successful transition to IPv6 can
happen while supporting legacy IPv4 users without a full end-end dual happen while supporting legacy IPv4 users without a full end-to-end
IP stack deployment. However, due to public IPv4 address exhaustion dual IP stack deployment. However, due to public IPv4 address
this requires an IPv6 technology that supports IPv4 users utilizing exhaustion this requires an IPv6 technology that supports IPv4 users
shared IPv4 addressing, while also allowing the network operator to utilizing shared IPv4 addressing, while also allowing the network
optimalise their operations around IPv6 network practices. The use operator to optimize their operations around IPv6 network practices.
of double NAT64 translation based solutions is an optimal way to The use of double NAT64 translation based solutions is an optimal way
address these requirements, especially in combination with stateless to address these requirements, especially in combination with
translation techniques that minimize operational challenges outlined stateless translation techniques that minimize operational challenges
in [I-D.ietf-softwire-stateless-4v6-motivation]. outlined in [I-D.ietf-softwire-stateless-4v6-motivation].
The Mapping of Address and Port - Translation (MAP-T) architecture The Mapping of Address and Port - Translation (MAP-T) architecture
specified in this draft is such a double stateless NAT64 based specified in this draft is such a double stateless NAT64 based
solution. It builds on existing stateless NAT64 techniques specified solution. It builds on existing stateless NAT64 techniques specified
in [RFC6145], along with the stateless algorithmic address & in [RFC6145], along with the stateless algorithmic address &
transport layer port mapping scheme defined in MAP-E transport layer port mapping scheme defined in MAP-E
[I-D.ietf-softwire-map]. The MAP-T solution differs from MAP-E in [I-D.ietf-softwire-map]. The MAP-T solution differs from MAP-E in
the use of IPv4-IPv6 translation, rather than encapsulation, as the the use of IPv4-IPv6 translation, rather than encapsulation, as the
form of IPv6 domain transport. The translation mode is considered form of IPv6 domain transport. The translation mode is considered
advantageous in scenarios where the encapsulation overhead, or IPv6 advantageous in scenarios where the encapsulation overhead, or IPv6
operational practices (e.g. use of IPv6 only servers, or reliance on operational practices (e.g. Use of IPv6 only servers, or reliance on
IPv6 + protocol headers for traffic classification) rule out IPv6 + protocol headers for traffic classification) rule out
encapsulation. These scenarios are presented in encapsulation. These scenarios are presented in
[I-D.maglione-softwire-map-t-scenarios] [I-D.maglione-softwire-map-t-scenarios]
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
MAP Customer Edge (CE): A device functioning as a Customer Edge MAP-T Mapping of Address and Port by means of
address Translation.
MAP Customer Edge (CE): A device functioning as a Customer Edge (CE)
router in a MAP deployment. A typical MAP CE router in a MAP deployment. A typical MAP CE
adopting MAP rules will serve a residential adopting MAP rules will serve a residential
site with one WAN side IPv6 addressed site with one WAN side IPv6 addressed
interface, and one or more LAN side interface, and one or more LAN side
interfaces addressed using private IPv4 interfaces addressed using private IPv4
addressing. addressing.
MAP Border Relay (BR): A MAP enabled router managed by the service MAP Border Relay (BR): A MAP enabled router managed by the service
provider at the edge of a MAP domain. A provider at the edge of a MAP domain. A
Border Relay router has at least an Border Relay (BR) router has at least an
IPv6-enabled interface and an IPv4 interface IPv6-enabled interface and an IPv4 interface
connected to the native IPv4 network. A MAP connected to the native IPv4 network. A MAP
BR may also be referred to simply as a "BR" BR may also be referred to simply as a "BR"
within the context of MAP. within the context of MAP.
MAP domain: One or more MAP CEs and BRs connected by MAP domain: One or more MAP CEs and BRs connected by
means of an IPv6 network and sharing a common means of an IPv6 network and sharing a common
set of MAP Rules. A service provider may set of MAP Rules. A service provider may
deploy a single MAP domain, or may utilize deploy a single MAP domain, or may utilize
multiple MAP domains. multiple MAP domains.
MAP Rule: A set of parameters describing the mapping MAP Rule: A set of parameters describing the mapping
between an IPv4 prefix, IPv4 address or between an IPv4 prefix, IPv4 address or
shared IPv4 address and an IPv6 prefix or shared IPv4 address and an IPv6 prefix or
address. Each MAP domain uses a different address. Each MAP domain uses a different
mapping rule set. mapping rule set.
MAP Rule set: A Rule set is composed out of all the MAP MAP Rule set: A Rule set is composed out of all the MAP
Rules communicated to a device, that are Rules communicated to a device, that are
intended for determining the devices' traffic intended for determining the devices' IP+port
forwarding operations. A set has at least mapping and forwarding operations. The MAP
one entry, known as a default map rule. The
Rule set is interchangeably referred to in Rule set is interchangeably referred to in
this document as a Rule table. this document as a MAP Rule table or simply
Rule table. Two specific types of rules,
Basic Mapping Rule (BMR) and Forward Mapping
Rule (FMR), are defined in Section 5 of
[I-D.ietf-softwire-map]. The Default Mapping
Rule (DMR) is defined in this document.
MAP Rule table: See MAP Rule set. MAP Rule table: See MAP Rule set.
MAP node: A device that implements MAP. MAP node: A device that implements MAP.
Port-set: Each node has a separate part of the Port-set: Each node has a separate part of the
transport layer port space; denoted as a transport layer port space; denoted as a
port-set. port-set.
Port-set ID (PSID): Algorithmically identifies a set of ports Port-set ID (PSID): Algorithmically identifies a set of ports
skipping to change at page 6, line 35 skipping to change at page 6, line 35
O---+--------------O O---+--------------O
| |
User M User M
Private IPv4 Private IPv4
Network Network
Figure 1: MAP-T Architecture Figure 1: MAP-T Architecture
Each MAP-T CE is assigned with a regular IPv6 prefix from the Each MAP-T CE is assigned with a regular IPv6 prefix from the
operator's IPv6 network. This, in conjunction with MAP domain operator's IPv6 network. This, in conjunction with MAP domain
configuration settings is expanded using MAP procedures to form a MAP configuration settings and the use of the MAP procedures allows the
IPv6 address and an IPv4 address. To allow for IPv4 address sharing, computation of a MAP IPv6 address and a corresponding IPv4 address.
the CE may also have be configured with a TCP/UDP port-range that is To allow for IPv4 address sharing, the CE may also have be configured
codified by means of a MAP Port Set Identifier (PSID) value. Each CE with a TCP/UDP port-range that is identified by means of a MAP Port
is responsible for forwarding traffic between a given users' private Set Identifier (PSID) value. Each CE is responsible for forwarding
IPv4 address space and the CE's MAP derived IPv4 address + port set, traffic between a given user's private IPv4 address space and the MAP
as well as adapting traffic between IPv4 and IPv6 using stateless domain's IPv6 address space. The IPv4-IPv6 adaptation uses stateless
NAT64. NAT64, in conjunction with the MAP algorithm for address computation.
The MAP-T BR connects one or more MAP-T domains to external IPv4 The MAP-T BR connects one or more MAP-T domains to external IPv4
networks using stateless NAT64 as extended by the MAP-T behaviour networks using stateless NAT64 as extended by the MAP-T behaviour
described in this document. described in this document.
In contrast to MAP-E, NAT64 technology is used in the architecture In contrast to MAP-E, NAT64 technology is used in the architecture
for two purposes. Firstly, it is intended to diminish encapsulation for two purposes. Firstly, it is intended to diminish encapsulation
overhead and normalize IPv4 traffic to IPv6 as much as possible. overhead and allow IPv4 and IPv6 traffic to be treated as similarly
Secondly, it is intended to allow IPv4-only nodes to correspond as possible. Secondly, it is intended to allow IPv4-only nodes to
directly with IPv6 nodes in the MAP-T domain that have IPv4 embedded correspond directly with IPv6 nodes in the MAP-T domain that have
IPv6 addresses as per [RFC6052]). IPv4 embedded IPv6 addresses as per [RFC6052]).
The MAP-T architecture is based on the following key properties i) The MAP-T architecture is based on the following key properties i)
algorithmic IPv4-IPv6 address mapping codified as MAP Rules covered algorithmic IPv4-IPv6 address mapping codified as MAP Rules covered
in Section 5 ii) A MAP IPv6 address identifier, described in in Section 5 ii) A MAP IPv6 address identifier, described in
Section 6 iii) MAP-T IPv4-IPv6 forwarding behavior described in Section 6 iii) MAP-T IPv4-IPv6 forwarding behavior described in
Section 8. Section 8.
5. Mapping Rules 5. Mapping Rules
The MAP-T algorithmic mapping rules are identical to those in The MAP-T algorithmic mapping rules are identical to those in
Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with
the exception of Section 5.4 concerning the forwarding of traffic to/ the following exception. The forwarding of traffic to and from IPv4
from IPv4 nodes outside the MAP-T. destinations outside a MAP-T domain is to be performed as described
here under, instead of Section 5.4 of the MAP-E specification.
5.1. Destinations outside the MAP domain 5.1. Destinations outside the MAP domain
IPv4 traffic sent by MAP nodes that are all within one MAP domain is IPv4 traffic sent by MAP nodes that are all within one MAP domain is
translated to IPv6, with the sender's MAP IPv6 address, derived via translated to IPv6, with the sender's MAP IPv6 address, derived via
the BMR, as the IPv6 source address and the recipient's MAP IPv6 the Basic Mapping Rule (BMR), as the IPv6 source address and the
address, derived via the FMR, as the IPv6 destination address. recipient's MAP IPv6 address, derived via the Forward Mapping Rule
(FMR), as the IPv6 destination address.
IPv4 destinations outside of the MAP domain are represented by means IPv4 addressed destinations outside of the MAP domain are represented
of IPv4-Embedded IPv6 address s per [RFC6052], using the BR's IPv6 by means of IPv4-Embedded IPv6 address as per [RFC6052], using the
prefix. For a CE sending traffic to any such destination the source BR's IPv6 prefix. For a CE sending traffic to any such destination,
address of the IPv6 packet will be the CE's MAP IPv6 address and the the source address of the IPv6 packet will be that of the CE's MAP
destination IPv6 address will be the destination IPv4-embedded-IPv6 IPv6 address, and the destination IPv6 address will be the
address. This representation is termed as the MAP-T Default Mapping destination IPv4-embedded-IPv6 address. This address mapping is
Rule (DMR) and is specified in terms of an IPv6 prefix advertised by termed as following the MAP-T Default Mapping Rule (DMR) and is
one or more BRs. A typical MAP-T CE will install an IPv4 default defined in terms of the IPv6 prefix advertised by one or more BRs,
route using this rule. A BR will use this rule when translating all which provide external connectivity. A typical MAP-T CE will install
outside IPv4 source addresses to the IPv6 MAP domain. an IPv4 default route using this rule. A BR will use this rule when
translating all outside IPv4 source addresses to the IPv6 MAP domain.
It is recommended that the DMR IPv6 prefix-length SHOULD be by The DMR IPv6 prefix-length SHOULD be by default 64 bits long, and in
default 64 bits long, and in any case MUST NOT exceed 96 bits. The any case MUST NOT exceed 96 bits. The mapping of the IPv4
mapping of the IPv4 destination behind the IPv6 prefix will by destination behind the IPv6 prefix will by default follow the /64
default follow the /64 rule as per [RFC6052]. Any trailing bits rule as per [RFC6052]. Any trailing bits after the IPv4 address are
after the IPv4 address are set to 0x0. set to 0x0.
6. The IPv6 Interface Identifier 6. The IPv6 Interface Identifier
The Interface identifier format of a MAP-T node is the same as The Interface identifier format of a MAP-T node is the same as
described in section 6 of [I-D.ietf-softwire-map]. For convenience described in section 6 of [I-D.ietf-softwire-map]. For convenience
this is cited below: this is cited below:
| 128-n-o-s bits | | 128-n-o-s bits |
| 16 bits| 32 bits | 16 bits| | 16 bits| 32 bits | 16 bits|
+--------+----------------+--------+ +--------+----------------+--------+
skipping to change at page 8, line 36 skipping to change at page 8, line 36
identical for all CEs and BRs within a given MAP-T domain. identical for all CEs and BRs within a given MAP-T domain.
o The Basic Mapping Rule and optionally the Forwarding Mapping o The Basic Mapping Rule and optionally the Forwarding Mapping
Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
Length of Embedded Address bits Length of Embedded Address bits
o Use of Hub and spoke mode or Mesh mode. (If all traffic should be o Use of Hub and spoke mode or Mesh mode. (If all traffic should be
sent to the BR, or if direct CE to CE correspondence should be sent to the BR, or if direct CE to CE correspondence should be
supported). supported).
o Use of Translation mode (MAP-T) o Use of IPv4-IPv6 Translation (MAP-T)
o The BR's IPv6 prefix used in the DMR o The BR's IPv6 prefix used in the DMR
7.1. MAP CE 7.1. MAP CE
For a given MAP domain, the MAP configuration parameters that are the For a given MAP domain, the MAP configuration parameters are the same
same across all CEs within that domain. These values may be across all CEs within that domain. These values may be conveyed and
configured using a variety of methods, including DHCPv6, Broadband configured on the CEs using a variety of methods, including; DHCPv6,
Forum's "TR-69" Residential Gateway management interface, Netconf, or Broadband Forum's "TR-69" Residential Gateway management interface,
manual configuration. This document does not prescribe any of these Netconf, or manual configuration. This document does not prescribe
methods, but recommends that a MAP CE SHOULD implement DHCPv6 options any of these methods, but recommends that a MAP CE SHOULD implement
as per [I-D.ietf-softwire-map-dhcp]. Other configuration and DHCPv6 options as per [I-D.ietf-softwire-map-dhcp]. Other
management methods may use the data model described by this option configuration and management methods may use the data model described
for consistency and convenience of implementation on CEs that support by this option for consistency and convenience of implementation on
multiple configuration methods. CEs that support multiple configuration methods.
Besides the MAP configuration parameters, a CE requires an the IPv6 Besides the MAP configuration parameters, a CE requires an the IPv6
prefix to be assigned to the CE. This End-user IPv6 prefix is prefix to be assigned to the CE. This End-user IPv6 prefix is
configured as part of obtaining IPv6 Internet access, and is acquired configured as part of obtaining IPv6 Internet access, and is acquired
using standard IPv6 means applicable in the network where the CE is using standard IPv6 means applicable in the network where the CE is
located. located.
The MAP provisioning parameters, and hence the IPv4 service itself, The MAP provisioning parameters, and hence the IPv4 service itself,
are tied to the End-user IPv6 prefix; thus, the MAP service is also are tied to the End-user IPv6 prefix; thus, the MAP service is also
tied to this in terms of authorization, accounting, etc. tied to this in terms of authorization, accounting, etc.
A single MAP CE MAY be connected to more than one MAP domain, just as A single MAP CE MAY be connected to more than one MAP domain, just as
any router may have more than one IPv4-enabled service provider any router may have more than one IPv4-enabled service provider
facing interface and more than one set of associated addresses facing interface and more than one set of associated addresses
assigned by DHCPv6. Each domain a given CE operates within would assigned by DHCPv6. Each domain a given CE operates within would
require its own set of MAP configuration elements and would generate require its own set of MAP configuration elements and would generate
its own IPv4 address. Each MAP domain requires a distinct End-user its own IPv4 address. Each MAP domain requires a distinct End-user
IPv6 prefix. IPv6 prefix.
The MAP DHCPv6 option is specified in [I-D.ietf-softwire-map-dhcp]
7.2. MAP BR 7.2. MAP BR
The MAP BR MUST be configured with the same MAP elements as the MAP The MAP BR MUST be configured with the same MAP elements as the MAP
CEs operating within the same domain. CEs operating within the same domain.
For increased reliability and load balancing, the BR IPv6 prefix MAY For increased reliability and load balancing, the BR IPv6 prefix MAY
be shared across a given MAP domain. As MAP is stateless, any BR may be shared across a given MAP domain. As MAP is stateless, any BR may
be used for forwarding to/from the domain at any time. be used for forwarding to/from the domain at any time.
Since MAP uses provider address space, no specific routes need to be Since MAP uses provider address space, no specific routes need to be
advertised externally for MAP to operate, neither in IPv6 nor IPv4 advertised externally for MAP to operate, neither in IPv6 nor IPv4
BGP. However, the BR prefix needs to be advertised in the service BGP. However, the BR prefix needs to be advertised in the service
provider's IGP. provider's IGP.
8. MAP-T Packet Forwarding 8. MAP-T Packet Forwarding
The end-end packet flow in MAP-T involves an IPv4 or IPv6 packet The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet
being forwarded by a CE of BR in one of two directions for each such being forwarded by a CE of BR in one of two directions for each such
case. This section presents a conceptual view of the operations case. This section presents a conceptual view of the operations
involved in such forwarding. involved in such forwarding.
8.1. IPv4 to IPv6 at the CE 8.1. IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT NAT44 function, A MAP-T CE receiving IPv4 packets SHOULD perform NAPT NAT44
and create any necessary NAPT44 bindings. The source address and processing, and create any necessary NAPT44 bindings. The source
port of the packet obtained as a result of the NAPT44 process MUST address and source port-range of packets resulting from the NAPT44
correspond to the source IPv4 address and source transport port processing MUST correspond to the source IPv4 address and source
number derived to belong to the CE by means of the MAP Basic Mapping transport port-range assigned to the CE by means of the MAP Basic
Rule (BMR). Mapping Rule (BMR).
The IPv4 packet is subject to a longest IPv4 destination address + The IPv4 packet is subject to a longest IPv4 destination address +
port match MAP rule selection, which then determines the parameters port match MAP rule selection, which then determines the parameters
for the subsequent NAT64 operation. By default, all traffic is for the subsequent NAT64 operation. By default, all traffic is
matched to the default mapping rule (DMR), and subject to the matched to the default mapping rule (DMR), and subject to the
stateless NAT64 operation using the DMR parameters for NAT64 stateless NAT64 operation using the DMR parameters for NAT64
Section 5.1. Packets that are matched to (optional) Forward Mapping Section 5.1. Packets that are matched to (optional) Forward Mapping
Rules (FMRs) are subject to the stateless NAT64 operation using the Rules (FMRs) are subject to the stateless NAT64 operation using the
FMR parameters Section 5 for the MAP algorithm. In all cases the FMR parameters Section 5 for the MAP algorithm. In all cases the
CE's MAP IPv6 address Section 6 is used as a source address. CE's MAP IPv6 address Section 6 is used as a source address.
skipping to change at page 10, line 27 skipping to change at page 10, line 25
A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one
or more Forward Mapping Rules. or more Forward Mapping Rules.
8.2. IPv6 to IPv4 at the CE 8.2. IPv6 to IPv4 at the CE
A MAP-T CE receiving an IPv6 packet performs its regular IPv6 A MAP-T CE receiving an IPv6 packet performs its regular IPv6
operations (filtering, pre-routing, etc). Only packets that are operations (filtering, pre-routing, etc). Only packets that are
addressed to the CE's MAP-T IPv6 addresses, and with source addresses addressed to the CE's MAP-T IPv6 addresses, and with source addresses
matching the IPv6 map-rule prefixes of a DMR or FMR, are processed by matching the IPv6 map-rule prefixes of a DMR or FMR, are processed by
the MAP-T CE, with the DMR or FMR being selected based on a longest the MAP-T CE, with the DMR or FMR being selected based on a longest
match. The CE MUST check that MAP-T received packets' destination match. The CE MUST check that each MAP-T received packet's
transport-layer destination port number is in the range allowed for destination transport-layer destination port number is in the range
by the CE's MAP BMR configuration. The CE MUST silently drop any non allowed for by the CE's MAP BMR configuration. The CE MUST silently
conforming packets and an appropriate counter incremented. For drop any non conforming packet and an appropriate counter
packets whose source address longest matches an FMR prefix, the CE incremented. When receiving a packet whose source IP address longest
MUST perform a check of consistency of the source address against the matches an FMR prefix, the CE MUST perform a check of consistency of
allowed values from the derived source port-range. If the packets' the source address against the allowed values as per the derived
source port number is found to be outside the range allowed, the CE allocated source port-range. If the source port number of a packet
MUST drop the packet and SHOULD respond with an ICMPv6 "Destination is found to be outside the allocated range, the CE MUST drop the
Unreachable, Source address failed ingress/egress policy" (Type 1, packet and SHOULD respond with an ICMPv6 "Destination Unreachable,
Code 5). Source address failed ingress/egress policy" (Type 1, Code 5).
For each MAP-T packet, the CE's NAT64 function MUST derive the IPv4 For each MAP-T processed packet, the CE's NAT64 function MUST compute
source and destination addresses. The IPv4 destination address is an IPv4 source and destination addresses. The IPv4 destination
derived by extracting relevant information from the IPv6 destination address is computed by extracting relevant information from the IPv6
and the information stored in the BMR as per Section 5. The IPv4 destination and the information stored in the BMR as per Section 5.
source address is formed by classifying the packet's source as The IPv4 source address is formed by classifying a packet's source as
longest matching a DMR or FMR rule prefix, and then using the longest matching a DMR or FMR rule prefix, and then using the
respective rule parameters for the NAT64 operation. respective rule parameters for the NAT64 operation.
The resulting IPv4 packet is then forwarded to the CE's NAPT NAPT44 The resulting IPv4 packet is then forwarded to the CE's NAPT NAPT44
function, where the destination IPv4 address and port number MUST be function, where the destination IPv4 address and port number MUST be
mapped to their original value, before being forwarded according to mapped to their original value, before being forwarded according to
the CE's regular IPv4 rules. When the NAPT44 function is not the CE's regular IPv4 rules. When the NAPT44 function is not
enabled, by virtue of MAP configuration, the traffic from the enabled, by virtue of MAP configuration, the traffic from the
stateless NAT64 function is directly forwarded according to the CE's stateless NAT64 function is directly forwarded according to the CE's
IPv4 rules. IPv4 rules.
8.3. IPv6 to IPv4 at the BR 8.3. IPv6 to IPv4 at the BR
A MAP-T BR receiving IPv6 packets MUST select a matching MAP rule A MAP-T BR receiving an IPv6 packet MUST select a matching MAP rule
based on a longest address match of the packets' source address based on a longest address match of the packet's source address
against the BR's configured MAP Rules. In combination with the port- against the MAP Rules present on the BR. In combination with the
set-id derived from the packet's source IPv6 address, the selected Port-Set-Id derived from the packet's source IPv6 address, the
MAP rule allows the BR to verify that the CE is using its allowed selected MAP rule allows the BR to verify that the CE is using its
address and port range. Thus, the BR MUST perform a validation of allowed address and port range. Thus, the BR MUST perform a
the consistency of the source against the allowed values from the validation of the consistency of the source against the allowed
identified port-range. If the packets' source port number is found values from the identified port-range. If the packet's source port
to be outside the range allowed, the BR MUST drop the packet and number is found to be outside the range allowed, the BR MUST drop the
increment a counter to indicate that a potential spoofing attack may packet and increment a counter to indicate the event. The BR SHOULD
be underway. also respond with an ICMPv6 "Destination Unreachable, Source address
failed ingress/egress policy" (Type 1, Code 5).
When constructing the IPv4 packet, the BR MUST derive the source and When constructing the IPv4 packet, the BR MUST derive the source and
destination IPv4 addresses as per Section 5 of this document and destination IPv4 addresses as per Section 5 of this document and
translate the IPv6 to IPv4 headers as per [RFC6145]. The resulting translate the IPv6 to IPv4 headers as per [RFC6145]. The resulting
IPv4 packets are then passed to regular IPv4 forwarding. IPv4 packet is then passed to regular IPv4 forwarding.
8.4. IPv4 to IPv6 at the BR 8.4. IPv4 to IPv6 at the BR
A MAP-T BR receiving IPv4 packets uses a longest match IPv4 + A MAP-T BR receiving IPv4 packets uses a longest match IPv4 +
transport layer port lookup to identify the target MAP-T domain and transport layer port lookup to identify the target MAP-T domain and
select the FMR and DMR rules. The MAP-T BR MUST then compute and select the FMR and DMR rules. The MAP-T BR MUST then compute and
apply the IPv6 destination addresses from the IPv4 destination apply the IPv6 destination addresses from the IPv4 destination
address and port as per the selected FMR. The MAP-T BR MUST also address and port as per the selected FMR. The MAP-T BR MUST also
compute and apply the IPv6 source addresses from the IPv4 source compute and apply the IPv6 source addresses from the IPv4 source
address as per Section 5.1 (i.e. Using the IPv4 source and the BR's address as per Section 5.1 (i.e. Using the IPv4 source and the BR's
IPv6 prefix it forms an IPv6 embedded IPv4 address). Throughout the IPv6 prefix it forms an IPv6 embedded IPv4 address). Throughout the
generic IPv4 to IPv6 header translation procedures following generic IPv4 to IPv6 header translation procedures following
[RFC6145] apply. The resulting IPv6 packets are then passed to [RFC6145] apply. The resulting IPv6 packets are then passed to
regular IPv6 forwarding. regular IPv6 forwarding.
Note that the operation of a BR when forwarding to/from MAP-T domains Note that the operation of a BR when forwarding to/from MAP-T domains
that are defined without IPv4 address sharing is the same as that of that are defined without IPv4 address sharing is the same as that of
stateless NAT64 IPv4/IPv6 translation. stateless NAT64 IPv4/IPv6 translation.
9. ICMP Handling 9. ICMP Handling
MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per
[RFC6145], however additional behavior is also required due to the [RFC6145], however additional behavior is also required due to the
presence of NAPT44. Unlike TCP and UDP, which provide two transport presence of NAPT44. Unlike TCP and UDP, which provide two transport
protocol port fields to represent both source and destination, the protocol port fields to represent both source and destination, the
ICMP/ICMPv6 [RFC0792], [RFC4443] Query message header has only one ID ICMP/ICMPv6 [RFC0792], [RFC4443] Query message header has only one ID
field which needs to be used to identify a sending IPv4 host. When field which needs to be used to identify a sending IPv4 host. When
receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field
to a port value derived from the CE's Port-set-id. In the return to a port value derived from the CE's Port-Set-Id.
path, a MAP-T BR receiving an IPv4 ICMP packet containing an ID field
which is bound for a shared address in the MAP-T domain, the MAP-T BR A MAP-T BR receiving an IPv4 ICMP packet , which contains an ID field
SHOULD use the ID value as a substitute for the destination port in that is bound for a shared address in the MAP-T domain, SHOULD use
determining the IPv6 destination address. In all other cases, the the ID value as a substitute for the destination port in determining
MAP-T BR MUST derive the destination IPv6 address by simply mapping the IPv6 destination address. In all other cases, the MAP-T BR MUST
the destination IPv4 address without additional port info. derive the destination IPv6 address by simply mapping the destination
IPv4 address without additional port info.
10. Fragmentation and Path MTU Discovery 10. Fragmentation and Path MTU Discovery
Due to the different sizes of the IPv4 and IPv6 header, handling the Due to the different sizes of the IPv4 and IPv6 header, handling the
maximum packet size is relevant for the operation of any system maximum packet size is relevant for the operation of any system
connecting the two address families. There are three mechanisms to connecting the two address families. There are three mechanisms to
handle this issue: Path MTU discovery (PMTUD), fragmentation, and handle this issue: Path MTU discovery (PMTUD), fragmentation, and
transport-layer negotiation such as the TCP Maximum Segment Size transport-layer negotiation such as the TCP Maximum Segment Size
(MSS) option [RFC0897]. MAP uses all three mechanisms to deal with (MSS) option [RFC0897]. MAP uses all three mechanisms to deal with
different cases. different cases.
10.1. Fragmentation in the MAP domain 10.1. Fragmentation in the MAP domain
Translating an IPv4 packet to carry it across the MAP domain will Translating an IPv4 packet to carry it across the MAP domain will
increase its size typically by 20 bytes. It is strongly recommended increase its size typically by 20 bytes. The MTU in the MAP domain
that the MTU in the MAP domain be well managed and that the IPv6 MTU should be well managed and the IPv6 MTU on the CE WAN side interface
on the CE WAN side interface be set so that no fragmentation occurs SHOULD be configured so that no fragmentation occurs within the
within the boundary of the MAP domain. boundary of the MAP domain.
Fragmentation in MAP-T domain is to be handled as described in Fragmentation in MAP-T domain SHOULD be handled as described in
section 4 and 5 of [RFC6145]. section 4 and 5 of [RFC6145].
10.2. Receiving IPv4 Fragments on the MAP domain borders 10.2. Receiving IPv4 Fragments on the MAP domain borders
Forwarding of an IPv4 packet received from the outside of the MAP Forwarding of an IPv4 packet received from the outside of the MAP
domain requires the IPv4 destination address and the transport domain requires the IPv4 destination address and the transport
protocol destination port. The transport protocol information is protocol destination port. The transport protocol information is
only available in the first fragment received. As described in only available in the first fragment received. As described in
section 5.3.3 of [RFC6346] a MAP node receiving an IPv4 fragmented section 5.3.3 of [RFC6346] a MAP node receiving an IPv4 fragmented
packet from outside has to reassemble the packet before sending the packet from outside SHOULD reassemble the packet before sending the
packet onto the MAP domain. If the first packet received contains packet onto the MAP domain. If the first packet received contains
the transport protocol information, it is possible to optimize this the transport protocol information, it is possible to optimize this
behavior by using a cache and forwarding the fragments unchanged. A behavior by using a cache and forwarding the fragments unchanged. A
description of such a caching algorithm is outside the scope of this description of such a caching algorithm is outside the scope of this
document. document.
10.3. Sending IPv4 fragments to the outside 10.3. Sending IPv4 fragments to the outside
Two IPv4 hosts behind two different MAP CE's with the same IPv4 Two IPv4 hosts behind two different MAP CE's with the same IPv4
address sending fragments to an IPv4 destination host outside the address sending fragments to an IPv4 destination host outside the
skipping to change at page 14, line 11 skipping to change at page 13, line 50
destination, and port-index range. By default, a MAP CE configured destination, and port-index range. By default, a MAP CE configured
only with a BMR, as per this specification, will use it to configure only with a BMR, as per this specification, will use it to configure
its IPv4 parameters and IPv6 MAP address without enabling mesh mode. its IPv4 parameters and IPv6 MAP address without enabling mesh mode.
12.3. Communication with IPv6 servers in the MAP-T domain 12.3. Communication with IPv6 servers in the MAP-T domain
By default, MAP-T allows communication between both IPv4-only and any By default, MAP-T allows communication between both IPv4-only and any
IPv6 enabled devices, as well as with native IPv6-only servers IPv6 enabled devices, as well as with native IPv6-only servers
provided that the servers are configured with an IPv4-mapped IPv6 provided that the servers are configured with an IPv4-mapped IPv6
address. This address could be part of the IPv6 prefix used by the address. This address could be part of the IPv6 prefix used by the
DMR in the MAP-T domain. Such IPv6 servers (e.g. An HTTP server, or DMR in the MAP-T domain. Such IPv6 servers (e.g. An HTTP server, or
a web content cache device) are thus able to serve both IPv6 users as a web content cache device) are thus able to serve both IPv6 users as
well as IPv4-only users alike utilizing IPv6. Any such IPv6-only well as IPv4-only users alike utilizing IPv6. Any such IPv6-only
servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147]
become required only when IPv6 servers in the MAP-T domain are become required only when IPv6 servers in the MAP-T domain are
expected themselves to initiate communication to external IPv4-only expected themselves to initiate communication to external IPv4-only
hosts. hosts.
12.4. Compatibility with other NAT64 solutions 12.4. Compatibility with other NAT64 solutions
The MAP-T CEs NAT64 function is by default compatible for use with The MAP-T CEs NAT64 function is by default compatible for use with
skipping to change at page 15, line 11 skipping to change at page 14, line 51
exist with MAP because each BRs checks that the IPv6 source exist with MAP because each BRs checks that the IPv6 source
address of a received IPv6 packet is a CE address based on address of a received IPv6 packet is a CE address based on
Forwarding Mapping Rule. Forwarding Mapping Rule.
Attacks facilitated by restricted port-set: From hosts that are not Attacks facilitated by restricted port-set: From hosts that are not
subject to ingress filtering of [RFC2827], some attacks are subject to ingress filtering of [RFC2827], some attacks are
possible by an attacker injecting spoofed packets during ongoing possible by an attacker injecting spoofed packets during ongoing
transport connections ([RFC4953], [RFC5961], [RFC6056]. The transport connections ([RFC4953], [RFC5961], [RFC6056]. The
attacks depend on guessing which ports are currently used by attacks depend on guessing which ports are currently used by
target hosts, and using an unrestricted port-set is preferable, target hosts, and using an unrestricted port-set is preferable,
i.e. Using native IPv6 connections that are not subject to MAP i.e. Using native IPv6 connections that are not subject to MAP
port-range restrictions. To minimize this type of attacks when port-range restrictions. To minimize this type of attacks when
using a restricted port set, the MAP CE's NAT44 filtering behavior using a restricted port set, the MAP CE's NAT44 filtering behavior
SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs
SHOULD use a DNS transport proxy function to handle DNS traffic, SHOULD use a DNS transport proxy function to handle DNS traffic,
and source such traffic from IPv6 interfaces not assigned to and source such traffic from IPv6 interfaces not assigned to MAP-
MAP-T. Practicalities of these methods are discussed in T. Practicalities of these methods are discussed in Section 5.9
Section 5.9 of [I-D.dec-stateless-4v6]. of [I-D.dec-stateless-4v6].
ICMP Flooding Given the necessity to process and translate ICMP and ICMP Flooding Given the necessity to process and translate ICMP and
ICMPv6 messages by the BR and CE nodes, a foreseeable attack ICMPv6 messages by the BR and CE nodes, a foreseeable attack
vector is that of a flood of such messages leading to a saturation vector is that of a flood of such messages leading to a saturation
of the nodes' ICMP computing resources. This attack vector is not of the node's ICMP computing resources. This attack vector is not
specific to MAP, and its mitigation lies a combination of policing specific to MAP, and its mitigation lies a combination of policing
the rate of ICMP messages, policing the rate at which such the rate of ICMP messages, policing the rate at which such
messages can get processed by the MAP nodes, and of course messages can get processed by the MAP nodes, and of course
identifying and blocking off the source(s) of such traffic. identifying and blocking off the source(s) of such traffic.
[RFC6269] outlines general issues with IPv4 address sharing. [RFC6269] outlines general issues with IPv4 address sharing.
15. Contributors 15. Contributors
The following individuals authored major contribution to this The following individuals authored major contributions to this
document: document, and made the document possible:
Chongfeng Xie (China Telecom) Room 708, No.118, Xizhimennei Street Chongfeng Xie (China Telecom) Room 708, No.118, Xizhimennei Street
Beijing 100035 CN Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn Beijing 100035 CN Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn
Qiong Sun (China Telecom) Room 708, No.118, Xizhimennei Street Qiong Sun (China Telecom) Room 708, No.118, Xizhimennei Street
Beijing 100035 CN Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn Beijing 100035 CN Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn
Rajiv Asati (Cisco Systems) 7025-6 Kit Creek Road Research Triangle Rajiv Asati (Cisco Systems) 7025-6 Kit Creek Road Research Triangle
Park NC 27709 USA Email: rajiva@cisco.comc Park NC 27709 USA Email: rajiva@cisco.comc
skipping to change at page 16, line 17 skipping to change at page 16, line 11
Yu Zhai CERNET Center/Tsinghua University Room 225, Main Building, Yu Zhai CERNET Center/Tsinghua University Room 225, Main Building,
Tsinghua University Beijing 100084 CN Email: jacky.zhai@gmail.com Tsinghua University Beijing 100084 CN Email: jacky.zhai@gmail.com
16. Acknowledgements 16. Acknowledgements
This document is based on the ideas of many. In particular Remi This document is based on the ideas of many. In particular Remi
Despres, who has tirelessly worked on generalized mechanisms for Despres, who has tirelessly worked on generalized mechanisms for
stateless address mapping. stateless address mapping.
The authors would like to thank Mohamed Boucadair, Guillaume Gottard, The authors would also like to thank Mohamed Boucadair, Guillaume
Dan Wing, Jan Zorz, Nejc Scoberne, Tina Tsou, Gang Chen, Maoke Chen, Gottard, Dan Wing, Jan Zorz, Nejc Scoberne, Tina Tsou, Gang Chen,
Xiaohong Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni Qin, Chunfa Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni
Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta Maglione and Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta
Hongyu Chen for their review and comments. Maglione and Hongyu Chen for their review and comments.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
skipping to change at page 17, line 6 skipping to change at page 16, line 48
IPv4 Address Shortage", RFC 6346, August 2011. IPv4 Address Shortage", RFC 6346, August 2011.
17.2. Informative References 17.2. Informative References
[I-D.dec-stateless-4v6] [I-D.dec-stateless-4v6]
Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address
Sharing", draft-dec-stateless-4v6-04 (work in progress), Sharing", draft-dec-stateless-4v6-04 (work in progress),
October 2011. October 2011.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Bao, C., Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
for configuration of Softwire Address and Port Mapped "DHCPv6 Options for configuration of Softwire Address and
Clients", draft-ietf-softwire-map-dhcp-06 (work in Port Mapped Clients", draft-ietf-softwire-map-dhcp-09
progress), November 2013. (work in progress), October 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014.
[I-D.ietf-softwire-stateless-4v6-motivation] [I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
softwire-stateless-4v6-motivation-05 (work in progress), softwire-stateless-4v6-motivation-05 (work in progress),
November 2012. November 2012.
[I-D.maglione-softwire-map-t-scenarios] [I-D.maglione-softwire-map-t-scenarios]
Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use
cases for MAP-T", draft-maglione-softwire- cases for MAP-T", draft-maglione-softwire-map-
map-t-scenarios-03 (work in progress), October 2013. t-scenarios-04 (work in progress), April 2014.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC0897] Postel, J., "Domain name system implementation schedule", [RFC0897] Postel, J., "Domain name system implementation schedule",
RFC 897, February 1984. RFC 897, February 1984.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
skipping to change at page 20, line 11 skipping to change at page 20, line 11
its IPv6 address within the indicated end-user IPv6 prefix. its IPv6 address within the indicated end-user IPv6 prefix.
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
Example 2 - BR: Example 2 - BR:
Another example can be made of a MAP-T BR, Another example can be made of a MAP-T BR,
configured with the following FMR when receiving a packet configured with the following FMR when receiving a packet
with the following characteristics: with the following characteristics:
IPv4 source address: 1.2.3.4 (0x01020304) IPv4 source address: 10.2.3.4 (0x0a020304)
TCP source port: 80 TCP source port: 80
IPv4 destination address: 192.0.2.18 (0xc0000212) IPv4 destination address: 192.0.2.18 (0xc0000212)
TCP destination port: 1232 TCP destination port: 1232
Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix), Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix), 192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bits length)} 16 (Rule EA-bits length)}
MAP-T BR Prefix (DMR): 2001:db8:ffff::/64 MAP-T BR Prefix (DMR): 2001:db8:ffff::/64
skipping to change at page 20, line 33 skipping to change at page 20, line 33
the mapped destination IPv6 address for the corresponding the mapped destination IPv6 address for the corresponding
MAP-T CE, and also the source IPv6 address for MAP-T CE, and also the source IPv6 address for
the mapped IPv4 source address. the mapped IPv4 source address.
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12)) IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8 PSID length: 8
PSID: 0 x34 (1232) PSID: 0 x34 (1232)
The resulting IPv6 packet will have the following header fields: The resulting IPv6 packet will have the following header fields:
IPv6 source address: 2001:db8:ffff:0:0001:0203:0400:: IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034 IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
TCP source Port: 80 TCP source Port: 80
TCP destination Port: 1232 TCP destination Port: 1232
Example 3- FMR: Example 3- FMR:
An IPv4 host behind a MAP-T CE (configured as per the previous An IPv4 host behind a MAP-T CE (configured as per the previous
examples) corresponding with an IPv4 host 1.2.3.4 will have its examples) corresponding with an IPv4 host 10.2.3.4 will have its
packets converted into IPv6 using the DMR configured on the MAP-T packets converted into IPv6 using the DMR configured on the MAP-T
CE as follows: CE as follows:
Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix), Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
0.0.0.0/0 (Rule IPv4 prefix)} 0.0.0.0/0 (Rule IPv4 prefix)}
IPv4 source address: 192.0.2.18 IPv4 source address: 192.0.2.18
IPv4 destination address: 1.2.3.4 IPv4 destination address: 10.2.3.4
IPv4 source port: 1232 IPv4 source port: 1232
IPv4 destination port: 80 IPv4 destination port: 80
MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034 MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 destination address: 2001:db8:ffff:0:0001:0203:0400:: IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400::
Example 4 - Rule with no embedded address bits and no address sharing Example 4 - Rule with no embedded address bits and no address sharing
End-user IPv6 prefix: 2001:db8:0012:3400::/56 End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix), 192.0.2.1/32 (Rule IPv4 prefix),
0 (Rule EA-bits length)} 0 (Rule EA-bits length)}
PSID length: 0 (Sharing ratio is 1) PSID length: 0 (Sharing ratio is 1)
PSID offset: n/a PSID offset: n/a
 End of changes. 47 change blocks. 
147 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/