summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7599.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7599.txt')
-rw-r--r--doc/rfc/rfc7599.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7599.txt b/doc/rfc/rfc7599.txt
new file mode 100644
index 0000000..ac0cc30
--- /dev/null
+++ b/doc/rfc/rfc7599.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) X. Li
+Request for Comments: 7599 C. Bao
+Category: Standards Track Tsinghua University
+ISSN: 2070-1721 W. Dec, Ed.
+ O. Troan
+ Cisco Systems
+ S. Matsushima
+ SoftBank Telecom
+ T. Murakami
+ IP Infusion
+ July 2015
+
+
+ Mapping of Address and Port using Translation (MAP-T)
+
+Abstract
+
+ This document specifies the solution architecture based on "Mapping
+ of Address and Port" stateless IPv6-IPv4 Network Address Translation
+ (NAT64) for providing shared or non-shared IPv4 address connectivity
+ to and across an IPv6 network.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7599.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 1]
+
+RFC 7599 MAP-T July 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 2]
+
+RFC 7599 MAP-T July 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Conventions .....................................................4
+ 3. Terminology .....................................................5
+ 4. Architecture ....................................................6
+ 5. Mapping Rules ...................................................8
+ 5.1. Destinations outside the MAP Domain ........................8
+ 6. The IPv6 Interface Identifier ...................................9
+ 7. MAP-T Configuration ............................................10
+ 7.1. MAP CE ....................................................10
+ 7.2. MAP BR ....................................................11
+ 8. MAP-T Packet Forwarding ........................................11
+ 8.1. IPv4 to IPv6 at the CE ....................................11
+ 8.2. IPv6 to IPv4 at the CE ....................................12
+ 8.3. IPv6 to IPv4 at the BR ....................................12
+ 8.4. IPv4 to IPv6 at the BR ....................................13
+ 9. ICMP Handling ..................................................13
+ 10. Fragmentation and Path MTU Discovery ..........................14
+ 10.1. Fragmentation in the MAP Domain ..........................14
+ 10.2. Receiving IPv4 Fragments on the MAP Domain Borders .......14
+ 10.3. Sending IPv4 Fragments to the Outside ....................14
+ 11. NAT44 Considerations ..........................................15
+ 12. Usage Considerations ..........................................15
+ 12.1. EA-Bit Length 0 ..........................................15
+ 12.2. Mesh and Hub-and-Spoke Modes .............................15
+ 12.3. Communication with IPv6 Servers in the MAP-T Domain ......15
+ 12.4. Compatibility with Other NAT64 Solutions .................16
+ 13. Security Considerations .......................................16
+ 14. References ....................................................17
+ 14.1. Normative References .....................................17
+ 14.2. Informative References ...................................18
+ Appendix A. Examples of MAP-T Translation .........................21
+ Appendix B. Port-Mapping Algorithm ................................24
+ Acknowledgements ..................................................25
+ Contributors ......................................................25
+ Authors' Addresses ................................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 3]
+
+RFC 7599 MAP-T July 2015
+
+
+1. Introduction
+
+ Experiences from initial service provider IPv6 network deployments,
+ such as [RFC6219], indicate that successful transition to IPv6 can
+ happen while supporting legacy IPv4 users without a full end-to-end
+ dual-IP-stack deployment. However, due to public IPv4 address
+ exhaustion, this requires an IPv6 technology that supports IPv4 users
+ utilizing shared IPv4 addressing, while also allowing the network
+ operator to optimize their operations around IPv6 network practices.
+ The use of double NAT64 translation-based solutions is an optimal way
+ to address these requirements, especially in combination with
+ stateless translation techniques that minimize operational challenges
+ outlined in [Solutions-4v6].
+
+ The Mapping of Address and Port using Translation (MAP-T)
+ architecture specified in this document is such a double stateless
+ NAT64-based solution. It builds on existing stateless NAT64
+ techniques specified in [RFC6145], along with the stateless
+ algorithmic address and transport-layer port-mapping scheme defined
+ in the Mapping of Address and Port with Encapsulation (MAP-E)
+ specification [RFC7597]. The MAP-T solution differs from MAP-E in
+ that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as
+ the form of IPv6 domain transport. The translation mode is
+ considered advantageous in scenarios where the encapsulation
+ overhead, or IPv6 operational practices (e.g., the use of IPv6-only
+ servers, or reliance on IPv6 + protocol headers for traffic
+ classification) rule out encapsulation. These scenarios are
+ presented in [MAP-T-Use-Cases].
+
+2. Conventions
+
+ 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 RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 4]
+
+RFC 7599 MAP-T July 2015
+
+
+3. Terminology
+
+ MAP-T: Mapping of Address and Port using
+ Translation.
+
+ MAP Customer Edge (CE): A device functioning as a Customer Edge
+ router in a MAP deployment. A typical MAP CE
+ adopting MAP Rules will serve a residential
+ site with one WAN-side IPv6-addressed
+ interface and one or more LAN-side interfaces
+ addressed using private IPv4 addressing.
+
+ MAP Border Relay (BR): A MAP-enabled router managed by the service
+ provider at the edge of a MAP domain. A BR
+ has at least an IPv6-enabled interface and an
+ IPv4 interface connected to the native IPv4
+ network. A MAP BR may also be referred to as
+ simply a "BR" within the context of MAP.
+
+ MAP domain: One or more MAP CEs and BRs connected by
+ means of an IPv6 network and sharing a common
+ set of MAP Rules. A service provider may
+ deploy a single MAP domain or may utilize
+ multiple MAP domains.
+
+ MAP Rule: A set of parameters describing the mapping
+ between an IPv4 prefix, IPv4 address, or
+ shared IPv4 address and an IPv6 prefix or
+ address. Each MAP domain uses a different
+ mapping rule set.
+
+ MAP rule set: A rule set is composed of all the MAP Rules
+ communicated to a device that are intended to
+ determine the device's IP+port mapping and
+ forwarding operations. The MAP rule set is
+ interchangeably referred to in this document
+ as a MAP rule table or as simply a "rule
+ table". Two specific types of rules -- the
+ Basic Mapping Rule (BMR) and the Forwarding
+ Mapping Rule (FMR) -- are defined in
+ Section 5 of [RFC7597]. The Default Mapping
+ Rule (DMR) is defined in this document.
+
+ MAP rule table: See MAP rule set.
+
+ MAP node: A device that implements MAP.
+
+
+
+
+
+Li, et al. Standards Track [Page 5]
+
+RFC 7599 MAP-T July 2015
+
+
+ Port set: Each node has a separate part of the
+ transport-layer port space; this is denoted
+ as a port set.
+
+ Port Set ID (PSID): Algorithmically identifies a set of ports
+ exclusively assigned to a CE.
+
+ Shared IPv4 address: An IPv4 address that is shared among multiple
+ CEs. Only ports that belong to the assigned
+ port set can be used for communication. Also
+ known as a port-restricted IPv4 address.
+
+ End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by
+ means other than MAP itself, e.g.,
+ provisioned using DHCPv6 Prefix Delegation
+ (PD) [RFC3633], assigned via Stateless
+ Address Autoconfiguration (SLAAC) [RFC4862],
+ or configured manually. It is unique for
+ each CE.
+
+ MAP IPv6 address: The IPv6 address used to reach the MAP
+ function of a CE from other CEs and from BRs.
+
+ Rule IPv6 prefix: An IPv6 prefix assigned by a service provider
+ for a MAP Rule.
+
+ Rule IPv4 prefix: An IPv4 prefix assigned by a service provider
+ for a MAP Rule.
+
+ Embedded Address (EA) bits:
+ The IPv4 EA-bits in the IPv6 address identify
+ an IPv4 prefix/address (or part thereof) or a
+ shared IPv4 address (or part thereof) and a
+ Port Set Identifier.
+
+4. Architecture
+
+ Figure 1 depicts the overall MAP-T architecture, which sees any
+ number of privately addressed IPv4 users (N and M) connected by means
+ of MAP-T CEs to an IPv6 network that is equipped with one or more
+ MAP-T BRs. CEs and BRs that share MAP configuration parameters,
+ referred to as "MAP Rules", form a MAP-T domain.
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 6]
+
+RFC 7599 MAP-T July 2015
+
+
+ Functionally, the MAP-T CE and BR utilize and extend some
+ well-established technology building blocks to allow the IPv4 users
+ to correspond with nodes on the public IPv4 network or on the IPv6
+ network as follows:
+
+ o A (NAT44) Network Address and Port Translation (NAPT) [RFC2663]
+ function on a MAP CE is extended with support for restricting the
+ allowable TCP/UDP ports for a given IPv4 address. The IPv4
+ address and port range used are determined by the MAP provisioning
+ process and identical to MAP-E [RFC7597].
+
+ o A stateless NAT64 function [RFC6145] is extended to allow
+ stateless mapping of IPv4 and transport-layer port ranges to the
+ IPv6 address space.
+
+ User N
+ Private IPv4
+ | Network
+ |
+ O--+---------------O
+ | | MAP-T CE |
+ | +-----+--------+ |
+ | NAPT44| MAP-T | |
+ | +-----+ | +-._ ,-------. .------.
+ | +--------+ | ,-' `-. ,-' `-.
+ O------------------O / \ O---------O / Public \
+ / IPv6-only \ | MAP-T |/ IPv4 \
+ ( Network --+ Border +- Network )
+ \ / | Relay |\ /
+ O------------------O \ / O---------O \ /
+ | MAP-T CE | ;". ,-' `-. ,-'
+ | +-----+--------+ | ," `----+--' ------'
+ | NAPT44| MAP-T | |, |
+ | +-----+ | + IPv6 node(s)
+ | | +--------+ | (with IPv4-embedded IPv6 address)
+ O---+--------------O
+ |
+ User M
+ Private IPv4
+ Network
+
+ Figure 1: MAP-T Architecture
+
+ Each MAP-T CE is assigned with a regular IPv6 prefix from the
+ operator's IPv6 network. This, in conjunction with MAP domain
+ configuration settings and the use of the MAP procedures, allows the
+ computation of a MAP IPv6 address and a corresponding IPv4 address.
+ To allow for IPv4 address sharing, the CE may also have to be
+
+
+
+Li, et al. Standards Track [Page 7]
+
+RFC 7599 MAP-T July 2015
+
+
+ configured with a TCP/UDP port range that is identified by means of a
+ MAP Port Set Identifier (PSID) value. Each CE is responsible for
+ forwarding traffic between a given user's private IPv4 address space
+ and the MAP domain's IPv6 address space. The IPv4-IPv6 adaptation
+ uses stateless NAT64, in conjunction with the MAP algorithm for
+ address computation.
+
+ The MAP-T BR connects one or more MAP-T domains to external IPv4
+ networks using stateless NAT64 as extended by the MAP-T behavior
+ described in this document.
+
+ In contrast to MAP-E, NAT64 technology is used in the architecture
+ for two purposes. First, it is intended to diminish encapsulation
+ overhead and allow IPv4 and IPv6 traffic to be treated as similarly
+ as possible. Second, it is intended to allow IPv4-only nodes to
+ correspond directly with IPv6 nodes in the MAP-T domain that have
+ IPv4-embedded IPv6 addresses as per [RFC6052].
+
+ The MAP-T architecture is based on the following key properties:
+
+ 1. Algorithmic IPv4-IPv6 address mapping codified as MAP Rules, as
+ described in Section 5
+
+ 2. A MAP IPv6 address identifier, as described in Section 6
+
+ 3. MAP-T IPv4-IPv6 forwarding behavior, as described in Section 8
+
+5. Mapping Rules
+
+ The MAP-T algorithmic mapping rules are identical to those in
+ Section 5 of the MAP-E specification [RFC7597], with the following
+ exception: the forwarding of traffic to and from IPv4 destinations
+ outside a MAP-T domain is to be performed as described in this
+ document, instead of Section 5.4 of the MAP-E specification.
+
+5.1. Destinations outside the MAP Domain
+
+ 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
+ the Basic Mapping Rule (BMR), as the IPv6 source address and the
+ recipient's MAP IPv6 address, derived via the Forwarding Mapping Rule
+ (FMR), as the IPv6 destination address.
+
+ IPv4-addressed destinations outside of the MAP domain are represented
+ by means of IPv4-embedded IPv6 addresses as per [RFC6052], using the
+ BR's IPv6 prefix. For a CE sending traffic to any such destination,
+ the source address of the IPv6 packet will be that of the CE's MAP
+ IPv6 address, and the destination IPv6 address will be the
+
+
+
+Li, et al. Standards Track [Page 8]
+
+RFC 7599 MAP-T July 2015
+
+
+ destination IPv4-embedded IPv6 address. This address mapping is said
+ to be following the MAP-T Default Mapping Rule (DMR) and is defined
+ in terms of the IPv6 prefix advertised by one or more BRs, which
+ provide external connectivity. A typical MAP-T CE will install 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.
+
+ The DMR IPv6 prefix length SHOULD be 64 bits long by default and in
+ any case MUST NOT exceed 96 bits. The mapping of the IPv4
+ destination behind the IPv6 prefix will by default follow the /64
+ rule as per [RFC6052]. Any trailing bits after the IPv4 address are
+ set to 0x0.
+
+6. The IPv6 Interface Identifier
+
+ The interface identifier format of a MAP-T node is the same as the
+ format described in Section 6 of [RFC7597]. The format diagram is
+ provided here for convenience:
+
+ | 128-n-o-s bits |
+ | 16 bits| 32 bits | 16 bits|
+ +--------+----------------+--------+
+ | 0 | IPv4 address | PSID |
+ +--------+----------------+--------+
+
+ Figure 2: IPv6 Interface Identifier
+
+ In the case of an IPv4 prefix, the IPv4 address field is right-padded
+ with zeros up to 32 bits. The PSID is left-padded with zeros to
+ create a 16-bit field. For an IPv4 prefix or a complete IPv4
+ address, the PSID field is zero.
+
+ If the End-user IPv6 prefix length is larger than 64, the most
+ significant parts of the interface identifier are overwritten by the
+ prefix.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 9]
+
+RFC 7599 MAP-T July 2015
+
+
+7. MAP-T Configuration
+
+ For a given MAP domain, the BR and CE MUST be configured with the
+ following MAP parameters. The values for these parameters are
+ identical for all CEs and BRs within a given MAP-T domain.
+
+ o The Basic Mapping Rule and, optionally, the Forwarding Mapping
+ Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
+ Length of embedded address bits
+
+ 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
+ supported)
+
+ o Use of IPv4-IPv6 translation (MAP-T)
+
+ o The BR's IPv6 prefix used in the DMR
+
+7.1. MAP CE
+
+ For a given MAP domain, the MAP configuration parameters are the same
+ across all CEs within that domain. These values may be conveyed and
+ configured on the CEs using a variety of methods, including DHCPv6,
+ the Broadband Forum's "TR-69" Residential Gateway management
+ interface [TR069], the Network Configuration Protocol (NETCONF), or
+ manual configuration. This document does not prescribe any of these
+ methods but recommends that a MAP CE SHOULD implement DHCPv6 options
+ as per [RFC7598]. Other configuration and management methods may use
+ the data model described by this option for consistency and
+ convenience of implementation on CEs that support multiple
+ configuration methods.
+
+ Besides the MAP configuration parameters, a CE requires an IPv6
+ prefix to be assigned to the CE. This End-user IPv6 prefix is
+ configured as part of obtaining IPv6 Internet access and is acquired
+ using standard IPv6 means applicable in the network where the CE is
+ located.
+
+ The MAP provisioning parameters, and hence the IPv4 service itself,
+ are tied to the End-user IPv6 prefix; thus, the MAP service is also
+ tied to this in terms of authorization, accounting, etc.
+
+ 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-
+ facing interface and more than one set of associated addresses
+ assigned by DHCPv6. Each domain within which a given CE operates
+
+
+
+
+
+Li, et al. Standards Track [Page 10]
+
+RFC 7599 MAP-T July 2015
+
+
+ would require its own set of MAP configuration elements and would
+ generate its own IPv4 address. Each MAP domain requires a distinct
+ End-user IPv6 prefix.
+
+7.2. MAP BR
+
+ The MAP BR MUST be configured with the same MAP elements as the MAP
+ CEs operating within the same domain.
+
+ 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 used for forwarding to/from the domain at any time.
+
+ Since MAP uses provider address space, no specific IPv6 or IPv4
+ routes need to be advertised externally outside the service
+ provider's network for MAP to operate. However, the BR prefix needs
+ to be advertised in the service provider's IGP.
+
+8. MAP-T Packet Forwarding
+
+ The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet
+ being forwarded by a CE or BR in one of two directions for each such
+ case. This section presents a conceptual view of the operations
+ involved in such forwarding.
+
+8.1. IPv4 to IPv6 at the CE
+
+ A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
+ and create any necessary NAPT44 bindings. The source address and
+ source port range of packets resulting from the NAPT44 processing
+ MUST correspond to the source IPv4 address and source transport port
+ range assigned to the CE by means of the MAP Basic Mapping Rule
+ (BMR).
+
+ The IPv4 packet is subject to a longest IPv4 destination address +
+ port match MAP Rule selection, which then determines the parameters
+ for the subsequent NAT64 operation. By default, all traffic is
+ matched to the DMR and is subject to the stateless NAT64 operation
+ using the DMR parameters for NAT64 (Section 5.1). Packets that are
+ matched to (optional) Forwarding Mapping Rules (FMRs) are subject to
+ the stateless NAT64 operation using 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.
+
+ A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one
+ or more Forwarding Mapping Rules.
+
+
+
+
+
+Li, et al. Standards Track [Page 11]
+
+RFC 7599 MAP-T July 2015
+
+
+8.2. IPv6 to IPv4 at the CE
+
+ A MAP-T CE receiving an IPv6 packet performs its regular IPv6
+ operations (filtering, pre-routing, etc.). Only packets that are
+ 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
+ the MAP-T CE, with the DMR or FMR being selected based on a longest
+ match. The CE MUST check that each MAP-T received packet's
+ transport-layer destination port number is in the range allowed for
+ by the CE's MAP BMR configuration. The CE MUST silently drop any
+ nonconforming packet and increment an appropriate counter. When
+ receiving a packet whose source IP address longest matches an FMR
+ prefix, the CE MUST perform a check of consistency of the source
+ address against the allowed values as per the derived allocated
+ source port range. If the source port number of a packet is found to
+ be outside the allocated range, the CE MUST drop the packet and
+ SHOULD respond with an ICMPv6 "Destination Unreachable, source
+ address failed ingress/egress policy" (Type 1, Code 5).
+
+ For each MAP-T processed packet, the CE's NAT64 function MUST compute
+ an IPv4 source and destination address. The IPv4 destination address
+ is computed by extracting relevant information from the IPv6
+ destination and the information stored in the BMR as per Section 5.
+ 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
+ respective rule parameters for the NAT64 operation.
+
+ The resulting IPv4 packet is then forwarded to the CE's NAPT44
+ function, where the destination IPv4 address and port number MUST be
+ mapped to their original value before being forwarded according to
+ the CE's regular IPv4 rules. When the NAPT44 function is not
+ enabled, by virtue of MAP configuration, the traffic from the
+ stateless NAT64 function is directly forwarded according to the CE's
+ IPv4 rules.
+
+8.3. IPv6 to IPv4 at the BR
+
+ A MAP-T BR receiving an IPv6 packet MUST select a matching MAP Rule
+ based on a longest address match of the packet's source address
+ against the MAP Rules present on the BR. In combination with the
+ Port Set ID derived from the packet's source IPv6 address, the
+ selected MAP Rule allows the BR to verify that the CE is using its
+ allowed address and port range. Thus, the BR MUST perform a
+ validation of the consistency of the source against the allowed
+ values from the identified port range. If the packet's source port
+ number is found to be outside the range allowed, the BR MUST drop the
+
+
+
+
+
+Li, et al. Standards Track [Page 12]
+
+RFC 7599 MAP-T July 2015
+
+
+ packet and increment a counter to indicate the event. The BR SHOULD
+ 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
+ destination IPv4 addresses as per Section 5 of this document and
+ translate the IPv6-to-IPv4 headers as per [RFC6145]. The resulting
+ IPv4 packet is then passed to regular IPv4 forwarding.
+
+8.4. IPv4 to IPv6 at the BR
+
+ A MAP-T BR receiving IPv4 packets uses a longest match IPv4 +
+ 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
+ apply the IPv6 destination addresses from the IPv4 destination
+ 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
+ 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). The generic
+ IPv4-to-IPv6 header translation procedures outlined in [RFC6145]
+ apply throughout. The resulting IPv6 packets are then passed to
+ regular IPv6 forwarding.
+
+ 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 stateless NAT64 IPv4/IPv6 translation.
+
+9. ICMP Handling
+
+ MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per
+ [RFC6145]; however, additional behavior is also required due to the
+ presence of NAPT44. Unlike TCP and UDP, which provide two transport-
+ protocol port fields to represent both source and destination, the
+ ICMP/ICMPv6 [RFC792] [RFC4443] Query message header has only one ID
+ 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
+ to a port value derived from the CE's Port Set ID.
+
+ A MAP-T BR receiving an IPv4 ICMP packet that contains an ID field
+ that is bound for a shared address in the MAP-T domain SHOULD use the
+ ID value as a substitute for the destination port in determining the
+ IPv6 destination address. In all other cases, the MAP-T BR MUST
+ derive the destination IPv6 address by simply mapping the destination
+ IPv4 address without additional port information.
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 13]
+
+RFC 7599 MAP-T July 2015
+
+
+10. Fragmentation and Path MTU Discovery
+
+ Due to the different sizes of the IPv4 and IPv6 headers, handling the
+ maximum packet size is relevant for the operation of any system
+ connecting the two address families. There are three mechanisms to
+ handle this issue: Path MTU Discovery (PMTUD), fragmentation, and
+ transport-layer negotiation such as the TCP Maximum Segment Size
+ (MSS) option [RFC879]. MAP can use all three mechanisms to deal with
+ different cases.
+
+ Note: The NAT64 [RFC6145] mechanism is not lossless. When
+ IPv4-originated communication traverses a double NAT64 function
+ (a.k.a. NAT464), any IPv4-originated ICMP-independent Path MTU
+ Discovery, as specified in [RFC4821], ceases to be entirely reliable.
+ This is because the DF=1/MF=1 combination as defined in [RFC4821]
+ results in DF=0/MF=1 after a double NAT64 translation.
+
+10.1. Fragmentation in the MAP Domain
+
+ Translating an IPv4 packet to carry it across the MAP domain will
+ increase its size (typically by 20 bytes). The MTU in the MAP domain
+ should be well managed, and the IPv6 MTU on the CE WAN-side interface
+ SHOULD be configured so that no fragmentation occurs within the
+ boundary of the MAP domain.
+
+ Fragmentation in MAP-T domains SHOULD be handled as described in
+ Sections 4 and 5 of [RFC6145].
+
+10.2. Receiving IPv4 Fragments on the MAP Domain Borders
+
+ The forwarding of an IPv4 packet received from outside of the MAP
+ domain requires the IPv4 destination address and the transport-
+ protocol destination port. The transport-protocol information is
+ only available in the first fragment received. As described in
+ Section 5.3.3 of [RFC6346], a MAP node receiving an IPv4 fragmented
+ packet from outside SHOULD reassemble the packet before sending the
+ packet onto the MAP domain. If the first packet received contains
+ the transport-protocol information, it is possible to optimize this
+ behavior by using a cache and forwarding the fragments unchanged. A
+ description of such a caching algorithm is outside the scope of this
+ document.
+
+10.3. Sending IPv4 Fragments to the Outside
+
+ Two IPv4 hosts behind two different MAP CEs with the same IPv4
+ address sending fragments to an IPv4 destination host outside the
+ domain may happen to use the same IPv4 fragmentation identifier,
+ resulting in incorrect reassembly of the fragments at the destination
+
+
+
+Li, et al. Standards Track [Page 14]
+
+RFC 7599 MAP-T July 2015
+
+
+ host. Given that the IPv4 fragmentation identifier is a 16-bit
+ field, it can be used similarly to port ranges. Thus, a MAP CE
+ SHOULD rewrite the IPv4 fragmentation identifier to a value
+ equivalent to a port of its allocated port set.
+
+11. NAT44 Considerations
+
+ The NAT44 implemented in the MAP CE SHOULD conform to the behavior
+ and best current practices documented in [RFC4787], [RFC5508], and
+ [RFC5382]. In MAP address-sharing mode (determined by the MAP
+ domain / rule configuration parameters), the operation of the NAT44
+ MUST be restricted to the available port numbers derived via the
+ Basic Mapping Rule.
+
+12. Usage Considerations
+
+12.1. EA-Bit Length 0
+
+ The MAP solution supports the use and configuration of domains where
+ a BMR expresses an EA-bit length of 0. This results in independence
+ between the IPv6 prefix assigned to the CE and the IPv4 address
+ and/or port range used by MAP. The k-bits of PSID information may in
+ this case be derived from the BMR.
+
+ The constraint imposed is that each such MAP domain be composed of
+ just one MAP CE that has a predetermined IPv6 end-user prefix. The
+ BR would be configured with an FMR for each such Customer Premises
+ Equipment (CPE), where the rule would uniquely associate the IPv4
+ address + optional PSID and the IPv6 prefix of that given CE.
+
+12.2. Mesh and Hub-and-Spoke Modes
+
+ The hub-and-spoke mode of communication, whereby all traffic sent by
+ a MAP-T CE is forwarded via a BR, and the Mesh mode, whereby a CE is
+ directly able to forward traffic to another CE, are governed by the
+ activation of Forwarding Mapping Rules that cover the IPv4-prefix
+ destination and port-index range. By default, a MAP CE configured
+ only with a BMR, as per this specification, will use it to configure
+ its IPv4 parameters and IPv6 MAP address without enabling Mesh mode.
+
+12.3. Communication with IPv6 Servers in the MAP-T Domain
+
+ By default, MAP-T allows communication between both IPv4-only and any
+ IPv6-enabled devices, as well as with native IPv6-only servers,
+ provided that the servers are configured with an IPv4-mapped IPv6
+ 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
+ a web content cache device) are thus able to serve IPv6 users and
+
+
+
+Li, et al. Standards Track [Page 15]
+
+RFC 7599 MAP-T July 2015
+
+
+ IPv4-only users alike, utilizing IPv6. Any such IPv6-only servers
+ SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] will be
+ required only when IPv6 servers in the MAP-T domain are themselves
+ expected to initiate communication to external IPv4-only hosts.
+
+12.4. Compatibility with Other NAT64 Solutions
+
+ The MAP-T CE's NAT64 function is by default compatible for use with
+ [RFC6146] stateful NAT64 devices that are placed in the operator's
+ network. In such a case, the MAP-T CE's DMR prefix is configured to
+ correspond to the NAT64 device prefix. This in effect allows the use
+ of MAP-T CEs in environments that need to perform statistical
+ multiplexing of IPv4 addresses, while utilizing stateful NAT64
+ devices, and can take the role of a customer-side translator (CLAT)
+ as defined in [RFC6877].
+
+13. Security Considerations
+
+ Spoofing attacks: With consistency checks between IPv4 and IPv6
+ sources that are performed on IPv4/IPv6 packets received by MAP
+ nodes, MAP does not introduce any new opportunity for spoofing
+ attacks that would not already exist in IPv6.
+
+ Denial-of-service attacks: In MAP domains where IPv4 addresses are
+ shared, the fact that IPv4 datagram reassembly may be necessary
+ introduces an opportunity for DoS attacks. This is inherent in
+ address sharing and is common with other address-sharing
+ approaches such as Dual-Stack Lite (DS-Lite) and NAT64/DNS64. The
+ best protection against such attacks is to accelerate IPv6 support
+ in both clients and servers.
+
+ Routing loop attacks: Routing loop attacks may exist in some
+ "automatic tunneling" scenarios and are documented in [RFC6324].
+ They cannot exist with MAP because each BR checks that the IPv6
+ source address of a received IPv6 packet is a CE address based on
+ the Forwarding Mapping Rule.
+
+ Attacks facilitated by restricted port set: From hosts that are not
+ subject to ingress filtering [RFC2827], an attacker can inject
+ spoofed packets during ongoing transport connections [RFC4953]
+ [RFC5961] [RFC6056]. The attacks depend on guessing which ports
+ are currently used by target hosts. Using an unrestricted port
+ set is preferable, i.e., using native IPv6 connections that are
+ not subject to MAP port-range restrictions. To minimize these
+ types of attacks when using a restricted port set, the MAP CE's
+ NAT44 filtering behavior SHOULD be "Address-Dependent Filtering"
+ as described in Section 5 of [RFC4787]. Furthermore, the MAP CEs
+ SHOULD use a DNS transport proxy function to handle DNS traffic
+
+
+
+Li, et al. Standards Track [Page 16]
+
+RFC 7599 MAP-T July 2015
+
+
+ and source such traffic from IPv6 interfaces not assigned to
+ MAP-T. Practicalities of these methods are discussed in
+ Section 5.9 of [Stateless-4Via6].
+
+ ICMP Flooding: Given the necessity to process and translate ICMP and
+ ICMPv6 messages by the BR and CE nodes, a foreseeable attack
+ vector is that of a flood of such messages leading to a saturation
+ of the node's ICMP computing resources. This attack vector is not
+ specific to MAP, and its mitigation lies in a combination of
+ policing the rate of ICMP messages, policing the rate at which
+ such messages can get processed by the MAP nodes, and of course
+ identifying and blocking off the source(s) of such traffic.
+
+ [RFC6269] outlines general issues with IPv4 address sharing.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ DOI 10.17487/RFC6052, October 2010,
+ <http://www.rfc-editor.org/info/rfc6052>.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
+ <http://www.rfc-editor.org/info/rfc6145>.
+
+ [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
+ the IPv4 Address Shortage", RFC 6346,
+ DOI 10.17487/RFC6346, August 2011,
+ <http://www.rfc-editor.org/info/rfc6346>.
+
+ [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
+ Murakami, T., and T. Taylor, Ed., "Mapping of Address and
+ Port with Encapsulation (MAP-E)", RFC 7597,
+ DOI 10.17487/RFC7597, July 2015,
+ <http://www.rfc-editor.org/info/rfc7597>.
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 17]
+
+RFC 7599 MAP-T July 2015
+
+
+14.2. Informative References
+
+ [MAP-T-Use-Cases]
+ Maglione, R., Ed., Dec, W., Leung, I., and E. Mallette,
+ "Use cases for MAP-T", Work in Progress,
+ draft-maglione-softwire-map-t-scenarios-05, October 2014.
+
+ [RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, DOI 10.17487/RFC0792, September 1981,
+ <http://www.rfc-editor.org/info/rfc792>.
+
+ [RFC879] Postel, J., "The TCP Maximum Segment Size and Related
+ Topics", RFC 879, DOI 10.17487/RFC0879, November 1983,
+ <http://www.rfc-editor.org/info/rfc879>.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, DOI 10.17487/RFC2663, August 1999,
+ <http://www.rfc-editor.org/info/rfc2663>.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+ May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+ [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+ Host Configuration Protocol (DHCP) version 6", RFC 3633,
+ DOI 10.17487/RFC3633, December 2003,
+ <http://www.rfc-editor.org/info/rfc3633>.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443,
+ DOI 10.17487/RFC4443, March 2006,
+ <http://www.rfc-editor.org/info/rfc4443>.
+
+ [RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
+ Translation (NAT) Behavioral Requirements for Unicast
+ UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787,
+ January 2007, <http://www.rfc-editor.org/info/rfc4787>.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+ Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+ <http://www.rfc-editor.org/info/rfc4821>.
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 18]
+
+RFC 7599 MAP-T July 2015
+
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862,
+ DOI 10.17487/RFC4862, September 2007,
+ <http://www.rfc-editor.org/info/rfc4862>.
+
+ [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
+ RFC 4953, DOI 10.17487/RFC4953, July 2007,
+ <http://www.rfc-editor.org/info/rfc4953>.
+
+ [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+ Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+ RFC 5382, DOI 10.17487/RFC5382, October 2008,
+ <http://www.rfc-editor.org/info/rfc5382>.
+
+ [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+ Behavioral Requirements for ICMP", BCP 148, RFC 5508,
+ DOI 10.17487/RFC5508, April 2009,
+ <http://www.rfc-editor.org/info/rfc5508>.
+
+ [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
+ Robustness to Blind In-Window Attacks", RFC 5961,
+ DOI 10.17487/RFC5961, August 2010,
+ <http://www.rfc-editor.org/info/rfc5961>.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056,
+ DOI 10.17487/RFC6056, January 2011,
+ <http://www.rfc-editor.org/info/rfc6056>.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
+ April 2011, <http://www.rfc-editor.org/info/rfc6146>.
+
+ [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+ Beijnum, "DNS64: DNS Extensions for Network Address
+ Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+ DOI 10.17487/RFC6147, April 2011,
+ <http://www.rfc-editor.org/info/rfc6147>.
+
+ [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
+ China Education and Research Network (CERNET) IVI
+ Translation Design and Deployment for the IPv4/IPv6
+ Coexistence and Transition", RFC 6219,
+ DOI 10.17487/RFC6219, May 2011,
+ <http://www.rfc-editor.org/info/rfc6219>.
+
+
+
+
+
+Li, et al. Standards Track [Page 19]
+
+RFC 7599 MAP-T July 2015
+
+
+ [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+ P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+ DOI 10.17487/RFC6269, June 2011,
+ <http://www.rfc-editor.org/info/rfc6269>.
+
+ [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
+ IPv6 Automatic Tunnels: Problem Statement and Proposed
+ Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
+ <http://www.rfc-editor.org/info/rfc6324>.
+
+ [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+ Combination of Stateful and Stateless Translation",
+ RFC 6877, DOI 10.17487/RFC6877, April 2013,
+ <http://www.rfc-editor.org/info/rfc6877>.
+
+ [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
+ W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
+ Configuration of Softwire Address and Port-Mapped
+ Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
+ <http://www.rfc-editor.org/info/rfc7598>.
+
+ [Solutions-4v6]
+ Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O.,
+ Borges, I., and G. Chen, "Motivations for Carrier-side
+ Stateless IPv4 over IPv6 Migration Solutions", Work in
+ Progress, draft-ietf-softwire-stateless-4v6-motivation-05,
+ November 2012.
+
+ [Stateless-4Via6]
+ Dec, W., Asati, R., Bao, C., Deng, H., and M. Boucadair,
+ "Stateless 4Via6 Address Sharing", Work in Progress,
+ draft-dec-stateless-4v6-04, October 2011.
+
+ [TR069] Broadband Forum TR-069, "CPE WAN Management Protocol",
+ Amendment 5, CWMP Version: 1.4, November 2013,
+ <https://www.broadband-forum.org>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 20]
+
+RFC 7599 MAP-T July 2015
+
+
+Appendix A. Examples of MAP-T Translation
+
+ Example 1 - Basic Mapping Rule:
+
+ Given the following MAP domain information and IPv6 end-user prefix
+ assigned to a MAP CE:
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
+ 192.0.2.0/24 (Rule IPv4 prefix),
+ 16 (Rule EA-bit length)}
+ PSID length: (16 - (32 - 24) = 8 (sharing ratio of 256)
+ PSID offset: 6 (default)
+
+ A MAP node (CE or BR) can, via the BMR or equivalent FMR, determine
+ the IPv4 address and port set as shown below:
+
+ EA bits offset: 40
+ IPv4 suffix bits (p): Length of IPv4 address (32) -
+ IPv4 prefix length (24) = 8
+ IPv4 address: 192.0.2.18 (0xc0000212)
+ PSID start: 40 + p = 40 + 8 = 48
+ PSID length (q): o - p = (End-user prefix len -
+ Rule IPv6 prefix len) - p
+ = (56 - 40) - 8 = 8
+ PSID: 0x34
+
+ Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
+ 63696-63699, 64720-64723
+
+ The BMR information allows a MAP CE to determine (complete) its
+ IPv6 address within the indicated End-user IPv6 prefix.
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 21]
+
+RFC 7599 MAP-T July 2015
+
+
+ Example 2 - BR:
+
+ Another example is a MAP-T BR configured with the following FMR
+ when receiving a packet with the following characteristics:
+
+ IPv4 source address: 10.2.3.4 (0x0a020304)
+ TCP source port: 80
+ IPv4 destination address: 192.0.2.18 (0xc0000212)
+ TCP destination port: 1232
+
+ Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
+ 192.0.2.0/24 (Rule IPv4 prefix),
+ 16 (Rule EA-bit length)}
+
+ MAP-T BR Prefix (DMR): 2001:db8:ffff::/64
+
+ The above information allows the BR to derive the mapped destination
+ IPv6 address for the corresponding MAP-T CE, and also the source
+ IPv6 address for the mapped IPv4 source address, as follows:
+
+ IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
+ PSID length: 8
+ PSID: 0 x34 (1232)
+
+ The resulting IPv6 packet will have the following header fields:
+
+ IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
+ IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
+ TCP source port: 80
+ TCP destination port: 1232
+
+
+ Example 3 - FMR:
+
+ An IPv4 host behind a MAP-T CE (configured as per the previous
+ examples) corresponding with IPv4 host 10.2.3.4 will have its
+ packets converted into IPv6 using the DMR configured on the MAP-T
+ CE as follows:
+
+ Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
+ 0.0.0.0/0 (Rule IPv4 prefix)}
+
+ IPv4 source address: 192.0.2.18
+ IPv4 destination address: 10.2.3.4
+ IPv4 source port: 1232
+ IPv4 destination port: 80
+ MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
+ IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400::
+
+
+
+Li, et al. Standards Track [Page 22]
+
+RFC 7599 MAP-T July 2015
+
+
+ Example 4 - Rule with no embedded address bits and no address
+ sharing:
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
+ 192.0.2.1/32 (Rule IPv4 prefix),
+ 0 (Rule EA-bit length)}
+ PSID length: 0 (sharing ratio is 1)
+ PSID offset: n/a
+
+ A MAP node can, via the BMR or equivalent FMR, determine the
+ IPv4 address and port set as shown below:
+
+ EA bits offset: 0
+ IPv4 suffix bits (p): Length of IPv4 address -
+ IPv4 prefix length = 32 - 32 = 0
+ IPv4 address: 192.0.2.18 (0xc0000212)
+ PSID start: 0
+ PSID length: 0
+ PSID: null
+
+ The BMR information allows a MAP CE to also determine (complete) its
+ full IPv6 address by combining the IPv6 prefix with the MAP interface
+ identifier (that embeds the IPv4 address).
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 23]
+
+RFC 7599 MAP-T July 2015
+
+
+ Example 5 - Rule with no embedded address bits and address sharing
+ (sharing ratio of 256):
+
+ End-user IPv6 prefix: 2001:db8:0012:3400::/56
+ Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
+ 192.0.2.18/32 (Rule IPv4 prefix),
+ 0 (Rule EA-bit length)}
+ PSID length: (16 - (32 - 24)) = 8 (sharing ratio of 256;
+ provisioned with DHCPv6)
+ PSID offset: 6 (default)
+ PSID: 0x20 (provisioned with DHCPv6)
+
+ A MAP node can, via the BMR, determine the IPv4 address and port set
+ as shown below:
+
+ EA bits offset: 0
+ IPv4 suffix bits (p): Length of IPv4 address -
+ IPv4 prefix length = 32 - 32 = 0
+ IPv4 address 192.0.2.18 (0xc0000212)
+ PSID start: 0
+ PSID length: 8
+ PSID: 0x34
+
+ Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
+ 63696-63699, 64720-64723
+
+ The BMR information allows a MAP CE to also determine (complete) its
+ full IPv6 address by combining the IPv6 prefix with the MAP interface
+ identifier (that embeds the IPv4 address and PSID).
+
+ IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034
+
+ Note that the IPv4 address and PSID are not derived from the IPv6
+ prefix assigned to the CE but are provisioned separately, using, for
+ example, MAP options in DHCPv6.
+
+Appendix B. Port-Mapping Algorithm
+
+ The driving principles and the mathematical expression of the mapping
+ algorithm used by MAP can be found in Appendix B of [RFC7597].
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 24]
+
+RFC 7599 MAP-T July 2015
+
+
+Acknowledgements
+
+ This document is based on the ideas of many, particularly Remi
+ Despres, who has tirelessly worked on generalized mechanisms for
+ stateless address mapping.
+
+ The authors would also like to thank Mohamed Boucadair, Guillaume
+ Gottard, Dan Wing, Jan Zorz, Nejc Skoberne, Tina Tsou, Gang Chen,
+ Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomek Mrugalski, Jacni
+ Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta
+ Maglione, and Hongyu Chen for their review and comments.
+
+Contributors
+
+ The following individuals authored major contributions to this
+ document and made the document possible:
+
+ Chongfeng Xie
+ China Telecom
+ Room 708, No. 118, Xizhimennei Street
+ Beijing 100035
+ China
+ Phone: +86-10-58552116
+ Email: xiechf@ctbri.com.cn
+
+ Qiong Sun
+ China Telecom
+ Room 708, No. 118, Xizhimennei Street
+ Beijing 100035
+ China
+ Phone: +86-10-58552936
+ Email: sunqiong@ctbri.com.cn
+
+ Rajiv Asati
+ Cisco Systems
+ 7025-6 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+ Email: rajiva@cisco.com
+
+ Gang Chen
+ China Mobile
+ 29, Jinrong Avenue
+ Xicheng District, Beijing 100033
+ China
+ Email: phdgang@gmail.com, chengang@chinamobile.com
+
+
+
+
+
+Li, et al. Standards Track [Page 25]
+
+RFC 7599 MAP-T July 2015
+
+
+ Wentao Shang
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: wentaoshang@gmail.com
+
+ Guoliang Han
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: bupthgl@gmail.com
+
+ Yu Zhai
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+ Email: jacky.zhai@gmail.com
+
+Authors' Addresses
+
+ Xing Li
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: xing@cernet.edu.cn
+
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: congxiao@cernet.edu.cn
+
+
+ Wojciech Dec (editor)
+ Cisco Systems
+ Haarlerbergpark Haarlerbergweg 13-19
+ Amsterdam, NOORD-HOLLAND 1101 CH
+ The Netherlands
+
+ Email: wdec@cisco.com
+
+
+
+Li, et al. Standards Track [Page 26]
+
+RFC 7599 MAP-T July 2015
+
+
+ Ole Troan
+ Cisco Systems
+ Philip Pedersens vei 1
+ Lysaker 1366
+ Norway
+
+ Email: ot@cisco.com
+
+
+ Satoru Matsushima
+ SoftBank Telecom
+ 1-9-1 Higashi-Shinbashi, Munato-ku
+ Tokyo
+ Japan
+
+ Email: satoru.matsushima@g.softbank.co.jp
+
+
+ Tetsuya Murakami
+ IP Infusion
+ 1188 East Arques Avenue
+ Sunnyvale, CA 94085
+ United States
+
+ Email: tetsuya@ipinfusion.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Standards Track [Page 27]
+