From: Alan T. DeKok <aland@freeradius.org>
Date: Wed, 16 Apr 2025 11:31:12 +0000 (-0400)
Subject: use correct RFC
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=78ecdc2c26fabb76dd1a1ca2a4e936a98d1f3e34;p=thirdparty%2Ffreeradius-server.git

use correct RFC
---

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