+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / freeradius-server.git / commitdiff
