From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7599.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc7599.txt (limited to 'doc/rfc/rfc7599.txt') 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, + . + + [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, + . + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, + . + + [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to + the IPv4 Address Shortage", RFC 6346, + DOI 10.17487/RFC6346, August 2011, + . + + [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, + . + + + + + + + + +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, + . + + [RFC879] Postel, J., "The TCP Maximum Segment Size and Related + Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, + . + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, DOI 10.17487/RFC2663, August 1999, + . + + [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, . + + [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, + . + + [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, + . + + [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, . + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, + . + + + + + + + +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, + . + + [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", + RFC 4953, DOI 10.17487/RFC4953, July 2007, + . + + [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, + . + + [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, + . + + [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, + . + + [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- + Protocol Port Randomization", BCP 156, RFC 6056, + DOI 10.17487/RFC6056, January 2011, + . + + [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, . + + [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, + . + + [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, + . + + + + + +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, + . + + [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, + . + + [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: + Combination of Stateful and Stateless Translation", + RFC 6877, DOI 10.17487/RFC6877, April 2013, + . + + [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, + . + + [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, + . + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3