--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed.
+Request for Comments: 7499 R. Marin-Lopez
+Category: Experimental F. Pereniguez-Garcia
+ISSN: 2070-1721 G. Lopez-Millan
+ University of Murcia
+ D. Lopez
+ Telefonica I+D
+ A. DeKok
+ Network RADIUS
+ April 2015
+
+
+ Support of Fragmentation of RADIUS Packets
+
+Abstract
+
+ The Remote Authentication Dial-In User Service (RADIUS) protocol is
+ limited to a total packet size of 4096 bytes. Provisions exist for
+ fragmenting large amounts of authentication data across multiple
+ packets, via Access-Challenge packets. No similar provisions exist
+ for fragmenting large amounts of authorization data. This document
+ specifies how existing RADIUS mechanisms can be leveraged to provide
+ that functionality. These mechanisms are largely compatible with
+ existing implementations, and they are designed to be invisible to
+ proxies and "fail-safe" to legacy RADIUS Clients and Servers.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. 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). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see 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/rfc7499.
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 1]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 2]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Requirements Language ......................................6
+ 2. Status of This Document .........................................6
+ 3. Scope of This Document ..........................................7
+ 4. Overview .......................................................10
+ 5. Fragmentation of Packets .......................................13
+ 5.1. Pre-Authorization .........................................14
+ 5.2. Post-Authorization ........................................18
+ 6. Chunk Size .....................................................21
+ 7. Allowed Large Packet Size ......................................22
+ 8. Handling Special Attributes ....................................23
+ 8.1. Proxy-State Attribute .....................................23
+ 8.2. State Attribute ...........................................24
+ 8.3. Service-Type Attribute ....................................25
+ 8.4. Rebuilding the Original Large Packet ......................25
+ 9. New T Flag for the Long Extended Type Attribute Definition .....26
+ 10. New Attribute Definition ......................................26
+ 10.1. Frag-Status Attribute ....................................27
+ 10.2. Proxy-State-Length Attribute .............................28
+ 10.3. Table of Attributes ......................................29
+ 11. Operation with Proxies ........................................29
+ 11.1. Legacy Proxies ...........................................29
+ 11.2. Updated Proxies ..........................................29
+ 12. General Considerations ........................................31
+ 12.1. T Flag ...................................................31
+ 12.2. Violation of RFC 2865 ....................................32
+ 12.3. Proxying Based on User-Name ..............................32
+ 12.4. Transport Behavior .......................................33
+ 13. Security Considerations .......................................33
+ 14. IANA Considerations ...........................................34
+ 15. References ....................................................35
+ 15.1. Normative References .....................................35
+ 15.2. Informative References ...................................35
+ Acknowledgements ..................................................37
+ Authors' Addresses ................................................37
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 3]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+1. Introduction
+
+ The RADIUS [RFC2865] protocol carries authentication, authorization,
+ and accounting information between a RADIUS Client and a RADIUS
+ Server. Information is exchanged between them through RADIUS
+ packets. Each RADIUS packet is composed of a header, and zero or
+ more attributes, up to a maximum packet size of 4096 bytes. The
+ protocol is a request/response protocol, as described in the
+ operational model ([RFC6158], Section 3.1).
+
+ The intention of the above packet size limitation was to avoid UDP
+ fragmentation as much as possible. Back then, a size of 4096 bytes
+ seemed large enough for any purpose. Now, new scenarios are emerging
+ that require the exchange of authorization information exceeding this
+ 4096-byte limit. For instance, the Application Bridging for
+ Federated Access Beyond web (ABFAB) IETF working group defines the
+ transport of Security Assertion Markup Language (SAML) statements
+ from the RADIUS Server to the RADIUS Client [SAML-RADIUS]. This
+ assertion is likely to be larger than 4096 bytes.
+
+ This means that peers desiring to send large amounts of data must
+ fragment it across multiple packets. For example, RADIUS-EAP
+ [RFC3579] defines how an Extensible Authentication Protocol (EAP)
+ exchange occurs across multiple Access-Request / Access-Challenge
+ sequences. No such exchange is possible for accounting or
+ authorization data. [RFC6158], Section 3.1 suggests that exchanging
+ large amounts of authorization data is unnecessary in RADIUS.
+ Instead, the data should be referenced by name. This requirement
+ allows large policies to be pre-provisioned and then referenced in an
+ Access-Accept. In some cases, however, the authorization data sent
+ by the RADIUS Server is large and highly dynamic. In other cases,
+ the RADIUS Client needs to send large amounts of authorization data
+ to the RADIUS Server. Neither of these cases is met by the
+ requirements in [RFC6158]. As noted in that document, the practical
+ limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
+ which may be significantly smaller than 4096 bytes. The combination
+ of the two limitations means that there is a pressing need for a
+ method to send large amounts of authorization data between RADIUS
+ Client and Server, with no accompanying solution.
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 4]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ [RFC6158], Section 3.1 recommends three approaches for the
+ transmission of large amounts of data within RADIUS. However, they
+ are not applicable to the problem statement of this document for the
+ following reasons:
+
+ o The first approach (utilization of a sequence of packets) does not
+ talk about large amounts of data sent from the RADIUS Client to a
+ RADIUS Server. Leveraging EAP (request/challenge) to send the
+ data is not feasible, as EAP already fills packets to PMTU, and
+ not all authentications use EAP. Moreover, as noted for the
+ NAS-Filter-Rule attribute ([RFC4849]), this approach does not
+ entirely solve the problem of sending large amounts of data from a
+ RADIUS Server to a RADIUS Client, as many current RADIUS
+ attributes are not permitted in Access-Challenge packets.
+
+ o The second approach (utilization of names rather than values) is
+ not usable either, as using names rather than values is difficult
+ when the nature of the data to be sent is highly dynamic (e.g., a
+ SAML statement or NAS-Filter-Rule attributes). URLs could be used
+ as a pointer to the location of the actual data, but their use
+ would require them to be (a) dynamically created and modified,
+ (b) securely accessed, and (c) accessible from remote systems.
+ Satisfying these constraints would require the modification of
+ several networking systems (e.g., firewalls and web servers).
+ Furthermore, the setup of an additional trust infrastructure
+ (e.g., Public Key Infrastructure (PKI)) would be required to allow
+ secure retrieval of the information from the web server.
+
+ o PMTU discovery does not solve the problem, as it does not allow
+ the sending of data larger than the minimum of (PMTU or 4096)
+ bytes.
+
+ This document provides a mechanism to allow RADIUS peers to exchange
+ large amounts of authorization data exceeding the 4096-byte limit by
+ fragmenting it across several exchanges. The proposed solution does
+ not impose any additional requirements to the RADIUS system
+ administrators (e.g., need to modify firewall rules, set up web
+ servers, configure routers, or modify any application server). It
+ maintains compatibility with intra-packet fragmentation mechanisms
+ (like those defined in [RFC3579] or [RFC6929]). It is also
+ transparent to existing RADIUS proxies, which do not implement this
+ specification. The only systems needing to implement this RFC are
+ the ones that either generate or consume the fragmented data being
+ transmitted. Intermediate proxies just pass the packets without
+ changes. Nevertheless, if a proxy supports this specification, it
+ may reassemble the data in order to examine and/or modify it.
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 5]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ A different approach to deal with RADIUS packets above the 4096-byte
+ limit is described in [RADIUS-Larger-Pkts], which proposes to extend
+ RADIUS over TCP by allowing the Length field in the RADIUS header to
+ take values up to 65535 bytes. This provides a simpler operation,
+ but it has the drawback of requiring every RADIUS proxy in the path
+ between the RADIUS Client and the RADIUS Server to implement the
+ extension as well.
+
+1.1. Requirements Language
+
+ 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].
+ When these words appear in lower case, they have their natural
+ language meaning.
+
+2. Status of This Document
+
+ This document is an Experimental RFC. It defines a proposal to allow
+ the sending and receiving of data exceeding the 4096-byte limit in
+ RADIUS packets imposed by [RFC2865], without requiring the
+ modification of intermediary proxies.
+
+ The experiment consists of verifying whether the approach is usable
+ in a large-scale environment, by observing the uptake, usability, and
+ operational behavior it shows in large-scale, real-life deployments.
+ In that sense, so far the main use case for this specification is the
+ transportation of large SAML statements defined within the ABFAB
+ architecture [ABFAB-Arch]. Hence, it can be tested wherever an ABFAB
+ deployment is being piloted.
+
+ Besides, this proposal defines some experimental features that will
+ need to be tested and verified before the document can be considered
+ for the Standards Track. The first one of them is the requirement of
+ updating [RFC2865] in order to relax the sentence defined in
+ Section 4.1 of that document that states that "An Access-Request MUST
+ contain either a User-Password or a CHAP-Password or a State." This
+ specification might generate Access-Request packets without any of
+ these attributes. Although all known implementations have chosen the
+ philosophy of "be liberal in what you accept," we need to gain more
+ operational experience to verify that unmodified proxies do not drop
+ these types of packets. More details on this aspect can be found in
+ Section 12.2.
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 6]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Another experimental feature of this specification is that it
+ requires proxies to base their routing decisions on the value of the
+ RADIUS User-Name attribute. Our experience is that this is the
+ common behavior; thus, no issues are expected. However, it needs to
+ be confirmed after using different implementations of intermediate
+ proxies. More details on this aspect can be found in Section 12.3.
+
+ Moreover, this document requires two minor updates to Standards Track
+ documents. First, it modifies the definition of the Reserved field
+ of the Long Extended Type attribute [RFC6929] by allocating an
+ additional flag called the T (Truncation) flag. No issues are
+ expected with this update, although some proxies might drop packets
+ that do not have the Reserved field set to 0. More details on this
+ aspect can be found in Section 12.1.
+
+ The other Standards Track document that requires a minor update is
+ [RFC6158]. It states that "attribute designers SHOULD NOT assume
+ that a RADIUS implementation can successfully process RADIUS packets
+ larger than 4096 bytes," something no longer true if this document
+ advances.
+
+ A proper "Updates" clause will be included for these modifications
+ when/if the experiment is successful and this document is reissued as
+ a Standards Track document.
+
+3. Scope of This Document
+
+ This specification describes how a RADIUS Client and a RADIUS Server
+ can exchange data exceeding the 4096-byte limit imposed by one
+ packet. However, the mechanism described in this specification
+ SHOULD NOT be used to exchange more than 100 kilobytes of data. Any
+ more than this may turn RADIUS into a generic transport protocol,
+ such as TCP or the Stream Control Transmission Protocol (SCTP), which
+ is undesirable. Experience shows that attempts to transport bulk
+ data across the Internet with UDP will inevitably fail, unless these
+ transport attempts reimplement all of the behavior of TCP. The
+ underlying design of RADIUS lacks the proper retransmission policies
+ or congestion control mechanisms that would make it a competitor
+ of TCP.
+
+ Therefore, RADIUS/UDP transport is by design unable to transport bulk
+ data. It is both undesirable and impossible to change the protocol
+ at this point in time. This specification is intended to allow the
+ transport of more than 4096 bytes of data through existing RADIUS/UDP
+ proxies. Other solutions such as RADIUS/TCP MUST be used when a
+ "green field" deployment requires the transport of bulk data.
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 7]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Section 7, below, describes in further detail what is considered to
+ be a reasonable amount of data and recommends that administrators
+ adjust limitations on data transfer according to the specific
+ capabilities of their existing systems in terms of memory and
+ processing power.
+
+ Moreover, its scope is limited to the exchange of authorization data,
+ as other exchanges do not require such a mechanism. In particular,
+ authentication exchanges have already been defined to overcome this
+ limitation (e.g., RADIUS-EAP). Moreover, as they represent the most
+ critical part of a RADIUS conversation, it is preferable to not
+ introduce into their operation any modification that may affect
+ existing equipment.
+
+ There is no need to fragment accounting packets either. While the
+ accounting process can send large amounts of data, that data is
+ typically composed of many small updates. That is, there is no
+ demonstrated need to send indivisible blocks of more than 4 kilobytes
+ of data. The need to send large amounts of data per user session
+ often originates from the need for flow-based accounting. In this
+ use case, the RADIUS Client may send accounting data for many
+ thousands of flows, where all those flows are tied to one user
+ session. The existing Acct-Multi-Session-Id attribute defined in
+ [RFC2866], Section 5.11 has been proven to work here.
+
+ Similarly, there is no need to fragment Change-of-Authorization (CoA)
+ [RFC5176] packets. Instead, according to [RFC5176], the CoA client
+ will send a CoA-Request packet containing session identification
+ attributes, along with Service-Type = Additional-Authorization, and a
+ State attribute. Implementations not supporting fragmentation will
+ respond with a CoA-NAK and an Error-Cause of Unsupported-Service.
+
+ The above requirement does not assume that the CoA client and the
+ RADIUS Server are co-located. They may, in fact, be run on separate
+ parts of the infrastructure, or even by separate administrators.
+ There is, however, a requirement that the two communicate. We can
+ see that the CoA client needs to send session identification
+ attributes in order to send CoA packets. These attributes cannot be
+ known a priori by the CoA client and can only come from the RADIUS
+ Server. Therefore, even when the two systems are not co-located,
+ they must be able to communicate in order to operate in unison. The
+ alternative is for the two systems to have differing views of the
+ users' authorization parameters; such a scenario would be a security
+ disaster.
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 8]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ This specification does not allow for fragmentation of CoA packets.
+ Allowing for fragmented CoA packets would involve changing multiple
+ parts of the RADIUS protocol; such changes introduce the risk of
+ implementation issues, mistakes, etc.
+
+ Where CoA clients (i.e., RADIUS Servers) need to send large amounts
+ of authorization data to a CoA server (i.e., RADIUS Client), they
+ need only send a minimal CoA-Request packet containing a Service-Type
+ of Authorize Only, as per [RFC5176], along with session
+ identification attributes. This CoA packet serves as a signal to the
+ RADIUS Client that the users' session requires re-authorization.
+ When the RADIUS Client re-authorizes the user via Access-Request, the
+ RADIUS Server can perform fragmentation and send large amounts of
+ authorization data to the RADIUS Client.
+
+ The assumption in the above scenario is that the CoA client and
+ RADIUS Server are co-located, or at least strongly coupled. That is,
+ the path from CoA client to CoA server SHOULD be the exact reverse of
+ the path from RADIUS Client to RADIUS Server. The following diagram
+ will hopefully clarify the roles:
+
+ +----------------+
+ | RADIUS CoA |
+ | Client Server |
+ +----------------+
+ | ^
+ Access-Request | | CoA-Request
+ v |
+ +----------------+
+ | RADIUS CoA |
+ | Server Client |
+ +----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 9]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Where there is a proxy involved:
+
+ +----------------+
+ | RADIUS CoA |
+ | Client Server |
+ +----------------+
+ | ^
+ Access-Request | | CoA-Request
+ v |
+ +----------------+
+ | RADIUS CoA |
+ | Proxy Proxy |
+ +----------------+
+ | ^
+ Access-Request | | CoA-Request
+ v |
+ +----------------+
+ | RADIUS CoA |
+ | Server Client |
+ +----------------+
+
+ That is, the RADIUS and CoA subsystems at each hop are strongly
+ connected. Where they are not strongly connected, it will be
+ impossible to use CoA-Request packets to transport large amounts of
+ authorization data.
+
+ This design is more complicated than allowing for fragmented CoA
+ packets. However, the CoA client and the RADIUS Server must
+ communicate even when not using this specification. We believe that
+ standardizing that communication and using one method for exchange of
+ large data are preferred to unspecified communication methods and
+ multiple ways of achieving the same result. If we were to allow
+ fragmentation of data over CoA packets, the size and complexity of
+ this specification would increase significantly.
+
+ The above requirement solves a number of issues. It clearly
+ separates session identification from authorization. Without this
+ separation, it is difficult to both identify a session and change its
+ authorization using the same attribute. It also ensures that the
+ authorization process is the same for initial authentication and
+ for CoA.
+
+4. Overview
+
+ Authorization exchanges can occur either before or after end-user
+ authentication has been completed. An authorization exchange before
+ authentication allows a RADIUS Client to provide the RADIUS Server
+ with information that MAY modify how the authentication process will
+
+
+
+Perez-Mendez, et al. Experimental [Page 10]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ be performed (e.g., it may affect the selection of the EAP method).
+ An authorization exchange after authentication allows the RADIUS
+ Server to provide the RADIUS Client with information about the end
+ user, the results of the authentication process, and/or obligations
+ to be enforced. In this specification, we refer to
+ "pre-authorization" as the exchange of authorization information
+ before the end-user authentication has started (from the RADIUS
+ Client to the RADIUS Server), whereas the term "post-authorization"
+ is used to refer to an authorization exchange happening after this
+ authentication process (from the RADIUS Server to the RADIUS Client).
+
+ In this specification, we refer to the "size limit" as the practical
+ limit on RADIUS packet sizes. This limit is the minimum between
+ 4096 bytes and the current PMTU. We define below a method that uses
+ Access-Request and Access-Accept in order to exchange fragmented
+ data. The RADIUS Client and Server exchange a series of
+ Access-Request / Access-Accept packets, until such time as all of the
+ fragmented data has been transported. Each packet contains a
+ Frag-Status attribute, which lets the other party know if
+ fragmentation is desired, ongoing, or finished. Each packet may also
+ contain the fragmented data or may instead be an "ACK" to a previous
+ fragment from the other party. Each Access-Request contains a
+ User-Name attribute, allowing the packet to be proxied if necessary
+ (see Section 11.1). Each Access-Request may also contain a State
+ attribute, which serves to tie it to a previous Access-Accept. Each
+ Access-Accept contains a State attribute, for use by the RADIUS
+ Client in a later Access-Request. Each Access-Accept contains a
+ Service-Type attribute with the "Additional-Authorization" value.
+ This indicates that the service being provided is part of a
+ fragmented exchange and that the Access-Accept should not be
+ interpreted as providing network access to the end user.
+
+ When a RADIUS Client or RADIUS Server needs to send data that exceeds
+ the size limit, the mechanism proposed in this document is used.
+ Instead of encoding one large RADIUS packet, a series of smaller
+ RADIUS packets of the same type are encoded. Each smaller packet is
+ called a "chunk" in this specification, in order to distinguish it
+ from traditional RADIUS packets. The encoding process is a simple
+ linear walk over the attributes to be encoded. This walk preserves
+ the order of the attributes of the same type, as required by
+ [RFC2865]. The number of attributes encoded in a particular chunk
+ depends on the size limit, the size of each attribute, the number of
+ proxies between the RADIUS Client and RADIUS Server, and the overhead
+ for fragmentation-signaling attributes. Specific details are given
+ in Section 6. A new attribute called Frag-Status (Section 10.1)
+ signals the fragmentation status.
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 11]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ After the first chunk is encoded, it is sent to the other party. The
+ packet is identified as a chunk via the Frag-Status attribute. The
+ other party then requests additional chunks, again using the
+ Frag-Status attribute. This process is repeated until all the
+ attributes have been sent from one party to the other. When all the
+ chunks have been received, the original list of attributes is
+ reconstructed and processed as if it had been received in one packet.
+
+ The reconstruction process is performed by simply appending all of
+ the chunks together. Unlike IPv4 fragmentation, there is no Fragment
+ Offset field. The chunks in this specification are explicitly
+ ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4.
+ That is, chunk N+1 cannot be sent until all of the chunks up to and
+ including N have been received and acknowledged.
+
+ When multiple chunks are sent, a special situation may occur for Long
+ Extended Type attributes as defined in [RFC6929]. The fragmentation
+ process may split a fragmented attribute across two or more chunks,
+ which is not permitted by that specification. We address this issue
+ by using the newly defined T flag in the Reserved field of the Long
+ Extended Type attribute format (see Section 9 for further details on
+ this flag).
+
+ This last situation is expected to be the most common occurrence in
+ chunks. Typically, packet fragmentation will occur as a consequence
+ of a desire to send one or more large (and therefore fragmented)
+ attributes. The large attribute will likely be split into two or
+ more pieces. Where chunking does not split a fragmented attribute,
+ no special treatment is necessary.
+
+ The setting of the T flag is the only case where the chunking process
+ affects the content of an attribute. Even then, the Value fields of
+ all attributes remain unchanged. Any per-packet security attributes,
+ such as Message-Authenticator, are calculated for each chunk
+ independently. Neither integrity checks nor security checks are
+ performed on the "original" packet.
+
+ Each RADIUS packet sent or received as part of the chunking process
+ MUST be a valid packet, subject to all format and security
+ requirements. This requirement ensures that a "transparent" proxy
+ not implementing this specification can receive and send compliant
+ packets. That is, a proxy that simply forwards packets without
+ detailed examination or any modification will be able to proxy
+ "chunks".
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 12]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+5. Fragmentation of Packets
+
+ When the RADIUS Client or the RADIUS Server desires to send a packet
+ that exceeds the size limit, it is split into chunks and sent via
+ multiple client/server exchanges. The exchange is indicated via the
+ Frag-Status attribute, which has value More-Data-Pending for all but
+ the last chunk of the series. The chunks are tied together via the
+ State attribute.
+
+ The delivery of a large fragmented RADIUS packet with authorization
+ data can happen before or after the end user has been authenticated
+ by the RADIUS Server. We can distinguish two phases, which can be
+ omitted if there is no authorization data to be sent:
+
+ 1. Pre-authorization. In this phase, the RADIUS Client MAY send a
+ large packet with authorization information to the RADIUS Server
+ before the end user is authenticated. Only the RADIUS Client is
+ allowed to send authorization data during this phase.
+
+ 2. Post-authorization. In this phase, the RADIUS Server MAY send a
+ large packet with authorization data to the RADIUS Client after
+ the end user has been authenticated. Only the RADIUS Server is
+ allowed to send authorization data during this phase.
+
+ The following subsections describe how to perform fragmentation for
+ packets for these two phases. We give the packet type, along with a
+ RADIUS Identifier, to indicate that requests and responses are
+ connected. We then give a list of attributes. We do not give values
+ for most attributes, as we wish to concentrate on the fragmentation
+ behavior rather than packet contents. Attribute values are given for
+ attributes relevant to the fragmentation process. Where "long
+ extended" attributes are used, we indicate the M (More) and T
+ (Truncation) flags as optional square brackets after the attribute
+ name. As no "long extended" attributes have yet been defined, we use
+ example attributes, named as "Example-Long-1", etc. For the sake of
+ simplicity, the maximum chunk size is established in terms of the
+ number of attributes (11).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 13]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+5.1. Pre-Authorization
+
+ When the RADIUS Client needs to send a large amount of data to the
+ RADIUS Server, the data to be sent is split into chunks and sent to
+ the RADIUS Server via multiple Access-Request / Access-Accept
+ exchanges. The example below shows this exchange.
+
+ The following is an Access-Request that the RADIUS Client intends to
+ send to a RADIUS Server. However, due to a combination of issues
+ (PMTU, large attributes, etc.), the content does not fit into one
+ Access-Request packet.
+
+ Access-Request
+ User-Name
+ NAS-Identifier
+ Calling-Station-Id
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1
+ Example-Long-2 [M]
+ Example-Long-2 [M]
+ Example-Long-2
+
+ Figure 1: Desired Access-Request
+
+ The RADIUS Client therefore must send the attributes listed above in
+ a series of chunks. The first chunk contains eight (8) attributes
+ from the original Access-Request, and a Frag-Status attribute. Since
+ the last attribute is "Example-Long-1" with the M flag set, the
+ chunking process also sets the T flag in that attribute. The
+ Access-Request is sent with a RADIUS Identifier field having
+ value 23. The Frag-Status attribute has value More-Data-Pending, to
+ indicate that the RADIUS Client wishes to send more data in a
+ subsequent Access-Request. The RADIUS Client also adds a
+ Service-Type attribute, which indicates that it is part of the
+ chunking process. The packet is signed with the
+ Message-Authenticator attribute, completing the maximum number of
+ attributes (11).
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 14]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Access-Request (ID = 23)
+ User-Name
+ NAS-Identifier
+ Calling-Station-Id
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [MT]
+ Frag-Status = More-Data-Pending
+ Service-Type = Additional-Authorization
+ Message-Authenticator
+
+ Figure 2: Access-Request (Chunk 1)
+
+ Compliant RADIUS Servers (i.e., servers implementing fragmentation)
+ receiving this packet will see the Frag-Status attribute and will
+ postpone all authorization and authentication handling until all of
+ the chunks have been received. This postponement also applies to the
+ verification that the Access-Request packet contains some kind of
+ authentication attribute (e.g., User-Password, CHAP-Password, State,
+ or other future attribute), as required by [RFC2865] (see
+ Section 12.2 for more information on this).
+
+ Non-compliant RADIUS Servers (i.e., servers not implementing
+ fragmentation) should also see the Service-Type requesting
+ provisioning for an unknown service and return Access-Reject. Other
+ non-compliant RADIUS Servers may return an Access-Reject or
+ Access-Challenge, or they may return an Access-Accept with a
+ particular Service-Type other than Additional-Authorization.
+ Compliant RADIUS Client implementations MUST treat these responses as
+ if they had received Access-Reject instead.
+
+ Compliant RADIUS Servers who wish to receive all of the chunks will
+ respond with the following packet. The value of the State here is
+ arbitrary and serves only as a unique token for example purposes. We
+ only note that it MUST be temporally unique to the RADIUS Server.
+
+ Access-Accept (ID = 23)
+ Frag-Status = More-Data-Request
+ Service-Type = Additional-Authorization
+ State = 0xabc00001
+ Message-Authenticator
+
+ Figure 3: Access-Accept (Chunk 1)
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 15]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ The RADIUS Client will see this response and use the RADIUS
+ Identifier field to associate it with an ongoing chunking session.
+ Compliant RADIUS Clients will then continue the chunking process.
+ Non-compliant RADIUS Clients will never see a response such as this,
+ as they will never send a Frag-Status attribute. The Service-Type
+ attribute is included in the Access-Accept in order to signal that
+ the response is part of the chunking process. This packet therefore
+ does not provision any network service for the end user.
+
+ The RADIUS Client continues the process by sending the next chunk,
+ which includes an additional six (6) attributes from the original
+ packet. It again includes the User-Name attribute, so that
+ non-compliant proxies can process the packet (see Section 11.1). It
+ sets the Frag-Status attribute to More-Data-Pending, as more data is
+ pending. It includes a Service-Type, for the reasons described
+ above. It includes the State attribute from the previous
+ Access-Accept. It signs the packet with Message-Authenticator, as
+ there are no authentication attributes in the packet. It uses a new
+ RADIUS Identifier field.
+
+ Access-Request (ID = 181)
+ User-Name
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1
+ Example-Long-2 [M]
+ Example-Long-2 [MT]
+ Frag-Status = More-Data-Pending
+ Service-Type = Additional-Authorization
+ State = 0xabc000001
+ Message-Authenticator
+
+ Figure 4: Access-Request (Chunk 2)
+
+ Compliant RADIUS Servers receiving this packet will see the
+ Frag-Status attribute and look for a State attribute. Since one
+ exists and it matches a State sent in an Access-Accept, this packet
+ is part of a chunking process. The RADIUS Server will associate the
+ attributes with the previous chunk. Since the Frag-Status attribute
+ has value More-Data-Request, the RADIUS Server will respond with an
+ Access-Accept as before. It MUST include a State attribute, with a
+ value different from the previous Access-Accept. This State MUST
+ again be globally and temporally unique.
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 16]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Access-Accept (ID = 181)
+ Frag-Status = More-Data-Request
+ Service-Type = Additional-Authorization
+ State = 0xdef00002
+ Message-Authenticator
+
+ Figure 5: Access-Accept (Chunk 2)
+
+ The RADIUS Client will see this response and use the RADIUS
+ Identifier field to associate it with an ongoing chunking session.
+ The RADIUS Client continues the chunking process by sending the next
+ chunk, with the final attribute(s) from the original packet, and
+ again includes the original User-Name attribute. The Frag-Status
+ attribute is not included in the next Access-Request, as no more
+ chunks are available for sending. The RADIUS Client includes the
+ State attribute from the previous Access-Accept. It signs the packet
+ with Message-Authenticator, as there are no authentication attributes
+ in the packet. It again uses a new RADIUS Identifier field.
+
+ Access-Request (ID = 241)
+ User-Name
+ Example-Long-2
+ State = 0xdef00002
+ Message-Authenticator
+
+ Figure 6: Access-Request (Chunk 3)
+
+ On reception of this last chunk, the RADIUS Server matches it with an
+ ongoing session via the State attribute and sees that there is no
+ Frag-Status attribute present. It then processes the received
+ attributes as if they had been sent in one RADIUS packet. See
+ Section 8.4 for further details on this process. It generates the
+ appropriate response, which can be either Access-Accept or
+ Access-Reject. In this example, we show an Access-Accept. The
+ RADIUS Server MUST send a State attribute, which allows linking the
+ received data with the authentication process.
+
+ Access-Accept (ID = 241)
+ State = 0x98700003
+ Message-Authenticator
+
+ Figure 7: Access-Accept (Chunk 3)
+
+ The above example shows in practice how the chunking process works.
+ We reiterate the implementation and security requirements here.
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 17]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Each chunk is a valid RADIUS packet (see Section 12.2 for some
+ considerations about this), and all RADIUS format and security
+ requirements MUST be followed before any chunking process is applied.
+
+ Every chunk except for the last one from a RADIUS Client MUST include
+ a Frag-Status attribute, with value More-Data-Pending. The last
+ chunk MUST NOT contain a Frag-Status attribute. Each chunk except
+ for the last one from a RADIUS Client MUST include a Service-Type
+ attribute, with value Additional-Authorization. Each chunk MUST
+ include a User-Name attribute, which MUST be identical in all chunks.
+ Each chunk except for the first one from a RADIUS Client MUST include
+ a State attribute, which MUST be copied from a previous
+ Access-Accept.
+
+ Each Access-Accept MUST include a State attribute. The value for
+ this attribute MUST change in every new Access-Accept and MUST be
+ globally and temporally unique.
+
+5.2. Post-Authorization
+
+ When the RADIUS Server wants to send a large amount of authorization
+ data to the RADIUS Client after authentication, the operation is very
+ similar to the pre-authorization process. The presence of a
+ Service-Type = Additional-Authorization attribute ensures that a
+ RADIUS Client not supporting this specification will treat that
+ unrecognized Service-Type as though an Access-Reject had been
+ received instead ([RFC2865], Section 5.6). If the original large
+ Access-Accept packet contained a Service-Type attribute, it will be
+ included with its original value in the last transmitted chunk, to
+ avoid confusion with the one used for fragmentation signaling. It is
+ RECOMMENDED that RADIUS Servers include a State attribute in their
+ original Access-Accept packets, even if fragmentation is not taking
+ place, to allow the RADIUS Client to send additional authorization
+ data in subsequent exchanges. This State attribute would be included
+ in the last transmitted chunk, to avoid confusion with the ones used
+ for fragmentation signaling.
+
+ Clients supporting this specification MUST include a Frag-Status =
+ Fragmentation-Supported attribute in the first Access-Request sent to
+ the RADIUS Server, in order to indicate that they would accept
+ fragmented data from the server. This is not required if the
+ pre-authorization process was carried out, as it is implicit.
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 18]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ The following is an Access-Accept that the RADIUS Server intends to
+ send to a RADIUS Client. However, due to a combination of issues
+ (PMTU, large attributes, etc.), the content does not fit into one
+ Access-Accept packet.
+
+ Access-Accept
+ User-Name
+ EAP-Message
+ Service-Type = Login
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1
+ Example-Long-2 [M]
+ Example-Long-2 [M]
+ Example-Long-2
+ State = 0xcba00003
+
+ Figure 8: Desired Access-Accept
+
+ The RADIUS Server therefore must send the attributes listed above in
+ a series of chunks. The first chunk contains seven (7) attributes
+ from the original Access-Accept, and a Frag-Status attribute. Since
+ the last attribute is "Example-Long-1" with the M flag set, the
+ chunking process also sets the T flag in that attribute. The
+ Access-Accept is sent with a RADIUS Identifier field having value 30,
+ corresponding to a previous Access-Request not depicted. The
+ Frag-Status attribute has value More-Data-Pending, to indicate that
+ the RADIUS Server wishes to send more data in a subsequent
+ Access-Accept. The RADIUS Server also adds a Service-Type attribute
+ with value Additional-Authorization, which indicates that it is part
+ of the chunking process. Note that the original Service-Type is not
+ included in this chunk. Finally, a State attribute is included to
+ allow matching subsequent requests with this conversation, and the
+ packet is signed with the Message-Authenticator attribute, completing
+ the maximum number of attributes (11).
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 19]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Access-Accept (ID = 30)
+ User-Name
+ EAP-Message
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [MT]
+ Frag-Status = More-Data-Pending
+ Service-Type = Additional-Authorization
+ State = 0xcba00004
+ Message-Authenticator
+
+ Figure 9: Access-Accept (Chunk 1)
+
+ Compliant RADIUS Clients receiving this packet will see the
+ Frag-Status attribute and suspend all authorization handling until
+ all of the chunks have been received. Non-compliant RADIUS Clients
+ should also see the Service-Type indicating the provisioning for an
+ unknown service and will treat it as an Access-Reject.
+
+ RADIUS Clients who wish to receive all of the chunks will respond
+ with the following packet, where the value of the State attribute is
+ taken from the received Access-Accept. They will also include the
+ User-Name attribute so that non-compliant proxies can process the
+ packet (Section 11.1).
+
+ Access-Request (ID = 131)
+ User-Name
+ Frag-Status = More-Data-Request
+ Service-Type = Additional-Authorization
+ State = 0xcba00004
+ Message-Authenticator
+
+ Figure 10: Access-Request (Chunk 1)
+
+ The RADIUS Server receives this request and uses the State attribute
+ to associate it with an ongoing chunking session. Compliant RADIUS
+ Servers will then continue the chunking process. Non-compliant
+ RADIUS Servers will never see a response such as this, as they will
+ never send a Frag-Status attribute.
+
+ The RADIUS Server continues the chunking process by sending the next
+ chunk, with the final attribute(s) from the original packet. The
+ value of the Identifier field is taken from the received
+ Access-Request. A Frag-Status attribute is not included in the next
+ Access-Accept, as no more chunks are available for sending. The
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 20]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ RADIUS Server includes the original State attribute to allow the
+ RADIUS Client to send additional authorization data. The original
+ Service-Type attribute is included as well.
+
+ Access-Accept (ID = 131)
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1 [M]
+ Example-Long-1
+ Example-Long-2 [M]
+ Example-Long-2 [M]
+ Example-Long-2
+ Service-Type = Login
+ State = 0xfda000003
+ Message-Authenticator
+
+ Figure 11: Access-Accept (Chunk 2)
+
+ On reception of this last chunk, the RADIUS Client matches it with an
+ ongoing session via the Identifier field and sees that there is no
+ Frag-Status attribute present. It then processes the received
+ attributes as if they had been sent in one RADIUS packet. See
+ Section 8.4 for further details on this process.
+
+6. Chunk Size
+
+ In an ideal scenario, each intermediate chunk would be exactly the
+ size limit in length. In this way, the number of round trips
+ required to send a large packet would be optimal. However, this is
+ not possible for several reasons.
+
+ 1. RADIUS attributes have a variable length and must be included
+ completely in a chunk. Thus, it is possible that, even if there
+ is some free space in the chunk, it is not enough to include the
+ next attribute. This can generate up to 254 bytes of spare space
+ in every chunk.
+
+ 2. RADIUS fragmentation requires the introduction of some extra
+ attributes for signaling. Specifically, a Frag-Status attribute
+ (7 bytes) is included in every chunk of a packet, except the last
+ one. A RADIUS State attribute (from 3 to 255 bytes) is also
+ included in most chunks, to allow the RADIUS Server to bind an
+ Access-Request with a previous Access-Challenge. User-Name
+ attributes (from 3 to 255 bytes) are included in every chunk the
+ RADIUS Client sends, as they are required by the proxies to route
+ the packet to its destination. Together, these attributes can
+ generate from up to 13 to 517 bytes of signaling data, reducing
+ the amount of payload information that can be sent in each chunk.
+
+
+
+Perez-Mendez, et al. Experimental [Page 21]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network
+ MTU. Otherwise, IP fragmentation may occur, with undesirable
+ consequences. Hence, maximum chunk size would be decreased from
+ 4096 to the actual MTU of the network.
+
+ 4. The inclusion of Proxy-State attributes by intermediary proxies
+ can decrease the availability of usable space in the chunk. This
+ is described in further detail in Section 8.1.
+
+7. Allowed Large Packet Size
+
+ There are no provisions for signaling how much data is to be sent via
+ the fragmentation process as a whole. It is difficult to define what
+ is meant by the "length" of any fragmented data. That data can be
+ multiple attributes and can include RADIUS attribute header fields,
+ or it can be one or more "large" attributes (more than 256 bytes in
+ length). Proxies can also filter these attributes, to modify, add,
+ or delete them and their contents. These proxies act on a "packet by
+ packet" basis and cannot know what kind of filtering actions they
+ will take on future packets. As a result, it is impossible to signal
+ any meaningful value for the total amount of additional data.
+
+ Unauthenticated end users are permitted to trigger the exchange of
+ large amounts of fragmented data between the RADIUS Client and the
+ RADIUS Server, having the potential to allow denial-of-service (DoS)
+ attacks. An attacker could initiate a large number of connections,
+ each of which requests the RADIUS Server to store a large amount of
+ data. This data could cause memory exhaustion on the RADIUS Server
+ and result in authentic users being denied access. It is worth
+ noting that authentication mechanisms are already designed to avoid
+ exceeding the size limit.
+
+ Hence, implementations of this specification MUST limit the total
+ amount of data they send and/or receive via this specification. Its
+ default value SHOULD be 100 kilobytes. Any more than this may turn
+ RADIUS into a generic transport protocol, which is undesirable. This
+ limit SHOULD be configurable, so that it can be changed if necessary.
+
+ Implementations of this specification MUST limit the total number of
+ round trips used during the fragmentation process. Its default value
+ SHOULD be 25. Any more than this may indicate an implementation
+ error, misconfiguration, or DoS attack. This limit SHOULD be
+ configurable, so that it can be changed if necessary.
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 22]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ For instance, let's imagine that the RADIUS Server wants to transport
+ a SAML assertion that is 15000 bytes long to the RADIUS Client. In
+ this hypothetical scenario, we assume that there are three
+ intermediate proxies, each one inserting a Proxy-State attribute of
+ 20 bytes. Also, we assume that the State attributes generated by the
+ RADIUS Server have a size of 6 bytes and the User-Name attribute
+ takes 50 bytes. Therefore, the amount of free space in a chunk for
+ the transport of the SAML assertion attributes is as follows:
+ Total (4096 bytes) - RADIUS header (20 bytes) - User-Name (50 bytes)
+ - Frag-Status (7 bytes) - Service-Type (6 bytes) - State (6 bytes) -
+ Proxy-State (20 bytes) - Proxy-State (20 bytes) - Proxy-State
+ (20 bytes) - Message-Authenticator (18 bytes), resulting in a total
+ of 3929 bytes. This amount of free space allows the transmission of
+ up to 15 attributes of 255 bytes each.
+
+ According to [RFC6929], a Long-Extended-Type provides a payload of
+ 251 bytes. Therefore, the SAML assertion described above would
+ result in 60 attributes, requiring four round trips to be completely
+ transmitted.
+
+8. Handling Special Attributes
+
+8.1. Proxy-State Attribute
+
+ RADIUS proxies may introduce Proxy-State attributes into any
+ Access-Request packet they forward. If they are unable to add this
+ information to the packet, they may silently discard it rather than
+ forward it to its destination; this would lead to DoS situations.
+ Moreover, any Proxy-State attribute received by a RADIUS Server in an
+ Access-Request packet MUST be copied into the corresponding reply
+ packet. For these reasons, Proxy-State attributes require special
+ treatment within the packet fragmentation mechanism.
+
+ When the RADIUS Server replies to an Access-Request packet as part of
+ a conversation involving a fragmentation (either a chunk or a request
+ for chunks), it MUST include every Proxy-State attribute received in
+ the reply packet. This means that the RADIUS Server MUST take into
+ account the size of these Proxy-State attributes in order to
+ calculate the size of the next chunk to be sent.
+
+ However, while a RADIUS Server will always know how much space MUST
+ be left in each reply packet for Proxy-State attributes (as they are
+ directly included by the RADIUS Server), a RADIUS Client cannot know
+ this information, as Proxy-State attributes are removed from the
+ reply packet by their respective proxies before forwarding them back.
+ Hence, RADIUS Clients need a mechanism to discover the amount of
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 23]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ space required by proxies to introduce their Proxy-State attributes.
+ In the following paragraphs, we describe a new mechanism to perform
+ such a discovery:
+
+ 1. When a RADIUS Client does not know how much space will be
+ required by intermediate proxies for including their Proxy-State
+ attributes, it SHOULD start using a conservative value (e.g.,
+ 1024 bytes) as the chunk size.
+
+ 2. When the RADIUS Server receives a chunk from the RADIUS Client,
+ it can calculate the total size of the Proxy-State attributes
+ that have been introduced by intermediary proxies along the path.
+ This information MUST be returned to the RADIUS Client in the
+ next reply packet, encoded into a new attribute called
+ Proxy-State-Length. The RADIUS Server MAY artificially increase
+ this quantity in order to handle situations where proxies behave
+ inconsistently (e.g., they generate Proxy-State attributes with a
+ different size for each packet) or where intermediary proxies
+ remove Proxy-State attributes generated by other proxies.
+ Increasing this value would make the RADIUS Client leave some
+ free space for these situations.
+
+ 3. The RADIUS Client SHOULD respond to the reception of this
+ attribute by adjusting the maximum size for the next chunk
+ accordingly. However, as the Proxy-State-Length offers just an
+ estimation of the space required by the proxies, the RADIUS
+ Client MAY select a smaller amount in environments known to be
+ problematic.
+
+8.2. State Attribute
+
+ This RADIUS fragmentation mechanism makes use of the State attribute
+ to link all the chunks belonging to the same fragmented packet.
+ However, some considerations are required when the RADIUS Server is
+ fragmenting a packet that already contains a State attribute for
+ other purposes not related to the fragmentation. If the procedure
+ described in Section 5 is followed, two different State attributes
+ could be included in a single chunk. This is something explicitly
+ forbidden in [RFC2865].
+
+ A straightforward solution consists of making the RADIUS Server send
+ the original State attribute in the last chunk of the sequence
+ (attributes can be reordered as specified in [RFC2865]). As the last
+ chunk (when generated by the RADIUS Server) does not contain any
+ State attribute due to the fragmentation mechanism, both situations
+ described above are avoided.
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 24]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Something similar happens when the RADIUS Client has to send a
+ fragmented packet that contains a State attribute in it. The RADIUS
+ Client MUST ensure that this original State is included in the first
+ chunk sent to the RADIUS Server (as this one never contains any State
+ attribute due to fragmentation).
+
+8.3. Service-Type Attribute
+
+ This RADIUS fragmentation mechanism makes use of the Service-Type
+ attribute to indicate that an Access-Accept packet is not granting
+ access to the service yet, since an additional authorization exchange
+ needs to be performed. Similarly to the State attribute, the RADIUS
+ Server has to send the original Service-Type attribute in the last
+ Access-Accept of the RADIUS conversation to avoid ambiguity.
+
+8.4. Rebuilding the Original Large Packet
+
+ The RADIUS Client stores the RADIUS attributes received in each chunk
+ in a list, in order to be able to rebuild the original large packet
+ after receiving the last chunk. However, some of these received
+ attributes MUST NOT be stored in that list, as they have been
+ introduced as part of the fragmentation signaling and hence are not
+ part of the original packet.
+
+ o State (except the one in the last chunk, if present)
+
+ o Service-Type = Additional-Authorization
+
+ o Frag-Status
+
+ o Proxy-State-Length
+
+ Similarly, the RADIUS Server MUST NOT store the following attributes
+ as part of the original large packet:
+
+ o State (except the one in the first chunk, if present)
+
+ o Service-Type = Additional-Authorization
+
+ o Frag-Status
+
+ o Proxy-State (except the ones in the last chunk)
+
+ o User-Name (except the one in the first chunk)
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 25]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+9. New T Flag for the Long Extended Type Attribute Definition
+
+ This document defines a new field in the Long Extended Type attribute
+ format. This field is one bit in size and is called "T" for
+ Truncation. It indicates that the attribute is intentionally
+ truncated in this chunk and is to be continued in the next chunk of
+ the sequence. The combination of the M flag and the T flag indicates
+ that the attribute is fragmented (M flag) but that all the fragments
+ are not available in this chunk (T flag). Proxies implementing
+ [RFC6929] will see these attributes as invalid (they will not be able
+ to reconstruct them), but they will still forward them, as
+ Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown
+ attributes anyway.
+
+ As a consequence of this addition, the Reserved field is now 6 bits
+ long (see Section 12.1 for some considerations). The following
+ figure represents the new attribute format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Extended-Type |M|T| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: Updated Long Extended Type Attribute Format
+
+10. New Attribute Definition
+
+ This document proposes the definition of two new extended type
+ attributes, called Frag-Status and Proxy-State-Length. The format of
+ these attributes follows the indications for an Extended Type
+ attribute defined in [RFC6929].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 26]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+10.1. Frag-Status Attribute
+
+ This attribute is used for fragmentation signaling, and its meaning
+ depends on the code value transported within it. The following
+ figure represents the format of the Frag-Status attribute:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Extended-Type | Code
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Code (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: Frag-Status Format
+
+ Type
+
+ 241
+
+ Length
+
+ 7
+
+ Extended-Type
+
+ 1
+
+ Code
+
+ 4 bytes. Integer indicating the code. The values defined in this
+ specification are:
+
+ 0 - Reserved
+
+ 1 - Fragmentation-Supported
+
+ 2 - More-Data-Pending
+
+ 3 - More-Data-Request
+
+ This attribute MAY be present in Access-Request, Access-Challenge,
+ and Access-Accept packets. It MUST NOT be included in Access-Reject
+ packets. RADIUS Clients supporting this specification MUST include a
+ Frag-Status = Fragmentation-Supported attribute in the first
+ Access-Request sent to the RADIUS Server, in order to indicate that
+ they would accept fragmented data from the server.
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 27]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+10.2. Proxy-State-Length Attribute
+
+ This attribute indicates to the RADIUS Client the length of the
+ Proxy-State attributes received by the RADIUS Server. This
+ information is useful for adjusting the length of the chunks sent by
+ the RADIUS Client. The format of this Proxy-State-Length attribute
+ is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Extended-Type | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: Proxy-State-Length Format
+
+ Type
+
+ 241
+
+ Length
+
+ 7
+
+ Extended-Type
+
+ 2
+
+ Value
+
+ 4 bytes. Total length (in bytes) of received Proxy-State
+ attributes (including headers). As the RADIUS Length field cannot
+ take values over 4096 bytes, values of Proxy-State-Length MUST be
+ less than that maximum length.
+
+ This attribute MAY be present in Access-Challenge and Access-Accept
+ packets. It MUST NOT be included in Access-Request or Access-Reject
+ packets.
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 28]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+10.3. Table of Attributes
+
+ The following table shows the different attributes defined in this
+ document, along with the types of RADIUS packets in which they can be
+ present.
+
+ | Type of Packet |
+ +-----+-----+-----+-----+
+ Attribute Name | Req | Acc | Rej | Cha |
+ ----------------------+-----+-----+-----+-----+
+ Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
+ ----------------------+-----+-----+-----+-----+
+ Proxy-State-Length | 0 | 0-1 | 0 | 0-1 |
+ ----------------------+-----+-----+-----+-----+
+
+11. Operation with Proxies
+
+ The fragmentation mechanism defined above is designed to be
+ transparent to legacy proxies, as long as they do not want to modify
+ any fragmented attribute. Nevertheless, updated proxies supporting
+ this specification can even modify fragmented attributes.
+
+11.1. Legacy Proxies
+
+ As every chunk is indeed a RADIUS packet, legacy proxies treat them
+ as they would the rest of the packets, routing them to their
+ destination. Proxies can introduce Proxy-State attributes into
+ Access-Request packets, even if they are indeed chunks. This will
+ not affect how fragmentation is managed. The RADIUS Server will
+ include all the received Proxy-State attributes in the generated
+ response, as described in [RFC2865]. Hence, proxies do not
+ distinguish between a regular RADIUS packet and a chunk.
+
+11.2. Updated Proxies
+
+ Updated proxies can interact with RADIUS Clients and Servers in order
+ to obtain the complete large packet before starting to forward it.
+ In this way, proxies can manipulate (modify and/or remove) any
+ attribute of the packet or introduce new attributes, without worrying
+ about crossing the boundaries of the chunk size. Once the
+ manipulated packet is ready, it is sent to the original destination
+ using the fragmentation mechanism (if required). The example in
+ Figure 15 shows how an updated proxy interacts with the RADIUS Client
+ to (1) obtain a large Access-Request packet and (2) modify an
+ attribute, resulting in an even larger packet. The proxy then
+ interacts with the RADIUS Server to complete the transmission of the
+ modified packet, as shown in Figure 16.
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 29]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ +-+-+-+-+-+ +-+-+-+-+-+
+ | RADIUS | | RADIUS |
+ | Client | | Proxy |
+ +-+-+-+-+-+ +-+-+-+-+-+
+ | |
+ | Access-Request(1){User-Name,Calling-Station-Id, |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[MT],Frag-Status(MDP)} |
+ |--------------------------------------------------->|
+ | |
+ | Access-Challenge(1){User-Name, |
+ | Frag-Status(MDR),State1} |
+ |<---------------------------------------------------|
+ | |
+ | Access-Request(2){User-Name,State1, |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[M],Example-Long-1} |
+ |--------------------------------------------------->|
+
+ Proxy Modifies Attribute Data, Increasing Its
+ Size from 9 Fragments to 11 Fragments
+
+ Figure 15: Updated Proxy Interacts with RADIUS Client
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 30]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ +-+-+-+-+-+ +-+-+-+-+-+
+ | RADIUS | | RADIUS |
+ | Proxy | | Server |
+ +-+-+-+-+-+ +-+-+-+-+-+
+ | |
+ | Access-Request(3){User-Name,Calling-Station-Id, |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[MT],Frag-Status(MDP)} |
+ |--------------------------------------------------->|
+ | |
+ | Access-Challenge(1){User-Name, |
+ | Frag-Status(MDR),State2} |
+ |<---------------------------------------------------|
+ | |
+ | Access-Request(4){User-Name,State2, |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[M],Example-Long-1[M], |
+ | Example-Long-1[MT],Frag-Status(MDP)} |
+ |--------------------------------------------------->|
+ | |
+ | Access-Challenge(1){User-Name, |
+ | Frag-Status(MDR),State3} |
+ |<---------------------------------------------------|
+ | |
+ | Access-Request(5){User-Name,State3,Example-Long-1} |
+ |--------------------------------------------------->|
+
+ Figure 16: Updated Proxy Interacts with RADIUS Server
+
+12. General Considerations
+
+12.1. T Flag
+
+ As described in Section 9, this document modifies the definition of
+ the Reserved field of the Long Extended Type attribute [RFC6929] by
+ allocating an additional flag called the T flag. The meaning and
+ position of this flag are defined in this document, and nowhere else.
+ This might cause an issue if subsequent specifications want to
+ allocate a new flag as well, as there would be no direct way for them
+ to know which parts of the Reserved field have already been defined.
+
+ An immediate and reasonable solution for this issue would be
+ declaring that this RFC updates [RFC6929]. In this way, [RFC6929]
+ would include an "Updated by" clause that will point readers to this
+ document. Another alternative would be creating an IANA registry for
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 31]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ the Reserved field. However, the RADIUS Extensions (RADEXT) working
+ group thinks that would be overkill, as a large number of
+ specifications extending that field are not expected.
+
+ In the end, the proposed solution is that this experimental RFC
+ should not update RFC 6929. Instead, we rely on the collective mind
+ of the working group to remember that this T flag is being used as
+ specified by this Experimental document. If the experiment is
+ successful, the T flag will be properly assigned.
+
+12.2. Violation of RFC 2865
+
+ Section 5.1 indicates that all authorization and authentication
+ handling will be postponed until all the chunks have been received.
+ This postponement also applies to the verification that the
+ Access-Request packet contains some kind of authentication attribute
+ (e.g., User-Password, CHAP-Password, State, or other future
+ attribute), as required by [RFC2865]. This checking will therefore
+ be delayed until the original large packet has been rebuilt, as some
+ of the chunks may not contain any of them.
+
+ The authors acknowledge that this specification violates the "MUST"
+ requirement of [RFC2865], Section 4.1 that states that "An
+ Access-Request MUST contain either a User-Password or a CHAP-Password
+ or a State." We note that a proxy that enforces that requirement
+ would be unable to support future RADIUS authentication extensions.
+ Extensions to the protocol would therefore be impossible to deploy.
+ All known implementations have chosen the philosophy of "be liberal
+ in what you accept." That is, they accept traffic that violates the
+ requirement of [RFC2865], Section 4.1. We therefore expect to see no
+ operational issues with this specification. After we gain more
+ operational experience with this specification, it can be reissued as
+ a Standards Track document and can update [RFC2865].
+
+12.3. Proxying Based on User-Name
+
+ This proposal assumes that legacy proxies base their routing
+ decisions on the value of the User-Name attribute. For this reason,
+ every packet sent from the RADIUS Client to the RADIUS Server (either
+ chunks or requests for more chunks) MUST contain a User-Name
+ attribute.
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 32]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+12.4. Transport Behavior
+
+ This proposal does not modify the way RADIUS interacts with the
+ underlying transport (UDP). That is, RADIUS keeps following a
+ lock-step behavior that requires receiving an explicit
+ acknowledgement for each chunk sent. Hence, bursts of traffic
+ that could congest links between peers are not an issue.
+
+ Another benefit of the lock-step nature of RADIUS is that there are
+ no security issues with overlapping fragments. Each chunk simply has
+ a length, with no Fragment Offset field as with IPv4. The order of
+ the fragments is determined by the order in which they are received.
+ There is no ambiguity about the size or placement of each chunk, and
+ therefore no security issues associated with overlapping chunks.
+
+13. Security Considerations
+
+ As noted in many earlier specifications ([RFC5080], [RFC6158], etc.),
+ RADIUS security is problematic. This specification changes nothing
+ related to the security of the RADIUS protocol. It requires that all
+ Access-Request packets associated with fragmentation are
+ authenticated using the existing Message-Authenticator attribute.
+ This signature prevents forging and replay, to the limits of the
+ existing security.
+
+ The ability to send bulk data from one party to another creates new
+ security considerations. RADIUS Clients and Servers may have to
+ store large amounts of data per session. The amount of this data can
+ be significant, leading to the potential for resource exhaustion. We
+ therefore suggest that implementations limit the amount of bulk data
+ stored per session. The exact method for this limitation is
+ implementation-specific. Section 7 gives some indications of what
+ could be reasonable limits.
+
+ The bulk data can often be pushed off to storage methods other than
+ the memory of the RADIUS implementation. For example, it can be
+ stored in an external database or in files. This approach mitigates
+ the resource exhaustion issue, as RADIUS Servers today already store
+ large amounts of accounting data.
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 33]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+14. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has registered the
+ Attribute Types and Attribute Values defined in this document in the
+ RADIUS namespaces as described in the "IANA Considerations" section
+ of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS
+ packets, attributes, and registries created by this document, IANA
+ has updated <http://www.iana.org/assignments/radius-types>
+ accordingly.
+
+ In particular, this document defines two new RADIUS attributes,
+ entitled "Frag-Status" (value 241.1) and "Proxy-State-Length"
+ (value 241.2), which have been allocated from the short extended
+ space as described in [RFC6929]:
+
+ Type Name Length Meaning
+ ---- ---- ------ -------
+ 241.1 Frag-Status 7 Signals fragmentation
+ 241.2 Proxy-State-Length 7 Indicates the length of the
+ received Proxy-State attributes
+
+ The Frag-Status attribute also defines an 8-bit "Code" field, for
+ which IANA has created and now maintains a new sub-registry entitled
+ "Code Values for RADIUS Attribute 241.1, Frag-Status". Initial
+ values for the RADIUS Frag-Status "Code" registry are given below;
+ future assignments are to be made through "RFC Required" [RFC5226].
+ Assignments consist of a Frag-Status "Code" name and its associated
+ value.
+
+ Value Frag-Status Code Name Definition
+ ---- ------------------------ ----------
+ 0 Reserved See Section 10.1
+ 1 Fragmentation-Supported See Section 10.1
+ 2 More-Data-Pending See Section 10.1
+ 3 More-Data-Request See Section 10.1
+ 4-255 Unassigned
+
+ Additionally, IANA has allocated a new Service-Type value for
+ "Additional-Authorization".
+
+ Value Service Type Value Definition
+ ---- ------------------------ ----------
+ 19 Additional-Authorization See Section 5.1
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 34]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+15. References
+
+15.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000, <http://www.rfc-editor.org/
+ info/rfc2865>.
+
+ [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
+ Authentication Dial In User Service)", RFC 3575,
+ July 2003, <http://www.rfc-editor.org/info/rfc3575>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
+ BCP 158, RFC 6158, March 2011,
+ <http://www.rfc-editor.org/info/rfc6158>.
+
+ [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
+ Service (RADIUS) Protocol Extensions", RFC 6929,
+ April 2013, <http://www.rfc-editor.org/info/rfc6929>.
+
+15.2. Informative References
+
+ [ABFAB-Arch]
+ Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
+ Schaad, "Application Bridging for Federated Access Beyond
+ Web (ABFAB) Architecture", Work in Progress,
+ draft-ietf-abfab-arch-13, July 2014.
+
+ [RADIUS-Larger-Pkts]
+ Hartman, S., "Larger Packets for RADIUS over TCP", Work in
+ Progress, draft-ietf-radext-bigger-packets-03, March 2015.
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
+ <http://www.rfc-editor.org/info/rfc2866>.
+
+ [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+ Dial In User Service) Support For Extensible
+ Authentication Protocol (EAP)", RFC 3579, September 2003,
+ <http://www.rfc-editor.org/info/rfc3579>.
+
+
+
+Perez-Mendez, et al. Experimental [Page 35]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
+ Rule Attribute", RFC 4849, April 2007,
+ <http://www.rfc-editor.org/info/rfc4849>.
+
+ [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
+ Dial In User Service (RADIUS) Implementation Issues and
+ Suggested Fixes", RFC 5080, December 2007,
+ <http://www.rfc-editor.org/info/rfc5080>.
+
+ [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
+ Aboba, "Dynamic Authorization Extensions to Remote
+ Authentication Dial In User Service (RADIUS)", RFC 5176,
+ January 2008, <http://www.rfc-editor.org/info/rfc5176>.
+
+ [SAML-RADIUS]
+ Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
+ RADIUS Attribute, Binding, Profiles, Name Identifier
+ Format, and Confirmation Methods for SAML", Work in
+ Progress, draft-ietf-abfab-aaa-saml-10, February 2015.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 36]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+Acknowledgements
+
+ The authors would like to thank the members of the RADEXT working
+ group who have contributed to the development of this specification
+ by either participating in the discussions on the mailing lists or
+ sending comments about our RFC.
+
+ The authors also thank David Cuenca (University of Murcia) for
+ implementing a proof-of-concept implementation of this RFC that has
+ been useful to improve the quality of the specification.
+
+ This work has been partly funded by the GEANT GN3+ SA5 and CLASSe
+ (<http://www.um.es/classe/>) projects.
+
+Authors' Addresses
+
+ Alejandro Perez-Mendez (editor)
+ University of Murcia
+ Campus de Espinardo S/N, Faculty of Computer Science
+ Murcia 30100
+ Spain
+
+ Phone: +34 868 88 46 44
+ EMail: alex@um.es
+
+
+ Rafa Marin-Lopez
+ University of Murcia
+ Campus de Espinardo S/N, Faculty of Computer Science
+ Murcia 30100
+ Spain
+
+ Phone: +34 868 88 85 01
+ EMail: rafa@um.es
+
+
+ Fernando Pereniguez-Garcia
+ University of Murcia
+ Campus de Espinardo S/N, Faculty of Computer Science
+ Murcia 30100
+ Spain
+
+ Phone: +34 868 88 78 82
+ EMail: pereniguez@um.es
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 37]
+\f
+RFC 7499 Fragmentation of RADIUS Packets April 2015
+
+
+ Gabriel Lopez-Millan
+ University of Murcia
+ Campus de Espinardo S/N, Faculty of Computer Science
+ Murcia 30100
+ Spain
+
+ Phone: +34 868 88 85 04
+ EMail: gabilm@um.es
+
+
+ Diego R. Lopez
+ Telefonica I+D
+ Don Ramon de la Cruz, 84
+ Madrid 28006
+ Spain
+
+ Phone: +34 913 129 041
+ EMail: diego@tid.es
+
+
+ Alan DeKok
+ Network RADIUS SARL
+ 57bis Boulevard des Alpes
+ Meylan 38240
+ France
+
+ EMail: aland@networkradius.com
+ URI: http://networkradius.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al. Experimental [Page 38]
+\f
+++ /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
