doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6653.txt b/doc/rfc/rfc6653.txt
new file mode 100644
index 0000000..65492bc
--- /dev/null
+++ b/doc/rfc/rfc6653.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Independent Submission                                       B. Sarikaya
+Request for Comments: 6653                                        F. Xia
+Category: Informational                                       Huawei USA
+ISSN: 2070-1721                                                 T. Lemon
+                                                                 Nominum
+                                                               July 2012
+
+
+     DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
+
+Abstract
+
+   As interest in IPv6 deployment in cellular networks increases,
+   several migration issues have been being raised; IPv6 prefix
+   management is the issue addressed in this document.  Based on the
+   idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix
+   Delegation to address such prefix management issues as an access
+   router offloading delegation of prefixes and release tasks to a
+   DHCPv6 server.  The access router first requests a prefix for an
+   incoming mobile node from the DHCPv6 server.  The access router may
+   next do stateless or stateful address allocation to the mobile node,
+   e.g., with a Router Advertisement or using DHCP.  We also describe
+   prefix management using Authentication, Authorization, and Accounting
+   (AAA) servers.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not 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/rfc6653.
+
+
+
+
+
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 1]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology and Acronyms ........................................4
+   3. Prefix Delegation Using DHCPv6 ..................................5
+      3.1. Prefix Request Procedure for Stateless Address
+           Configuration ..............................................5
+      3.2. Prefix Request Procedure for Stateful Address
+           Configuration ..............................................7
+      3.3. The MN as Requesting Router in Prefix Delegation ...........8
+      3.4. Prefix Release Procedure ...................................9
+      3.5. Miscellaneous Considerations ...............................9
+           3.5.1. How to Generate an IAID .............................9
+           3.5.2. Policy to Delegate Prefixes ........................10
+   4. Prefix Delegation Using RADIUS and Diameter ....................10
+   5. Security Considerations ........................................11
+   6. Acknowledgements ...............................................12
+   7. Informative References .........................................12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 2]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+1.  Introduction
+
+   Figure 1 illustrates the key elements of a typical cellular access
+   network.  In a Long-Term Evolution (LTE) network, the Access Router
+   (AR) is the Packet Data Network (PDN) Gateway [3GPP-23401].
+
+                                      +-------------+
+                                      |   +------+  |
+                                      |   |DHCP  |  |
+ +-----+  +-----+  +------+  +------+ |   |Server|  | +------+
+ | MN  |--| BS  |--+Access+--+Access+-+   +------+  +-+Border|
+ +-----+  +-----+  |  GW  |  |Router| |IP Network(s)| |Router+-Internet
+                   +--+---+  +--+---+ |             | +------+
+                      |         |     +-------------+
+ +-----+  +-----+     |         |    +------+
+ | MN  |--| BS  |-----+         |    |AAA   |
+ +-----+  +-----+               +--- |Server|
+                                     +------+
+
+           Figure 1: Key Elements of a Typical Cellular Network
+
+   The Mobile Node (MN) attaches to a Base Station (BS) through an LTE
+   air interface.  A BS manages connectivity of User Equipment (UE) and
+   extends connections to an Access Gateway (GW), e.g., the Serving
+   Gateway (S-GW) in an LTE network.  The access GW and the AR are
+   connected via an IP network.  The AR is the first-hop router of the
+   MNs and is in charge of address/prefix management.
+
+   The AR is connected to an IP network that is owned by the operator;
+   this network is connected to the public Internet via a border router.
+   The network contains servers for subscriber management, including
+   Quality of Service, billing, and accounting, as well as a Dynamic
+   Host Configuration Protocol (DHCP) server [RFC6342].
+
+   With IPv6 addressing, because mobile network links are point-to-point
+   (P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316].
+   In the per-MN interface prefix model, prefix management is an issue.
+
+   When an MN attaches to an AR, the AR requests one or more prefixes
+   for the MN.  When the MN detaches from the AR, the prefixes should be
+   released.  When the MN becomes idle, the AR should keep (i.e., not
+   release) the allocated prefixes.
+
+   This document describes how to use DHCPv6 Prefix Delegation
+   (DHCPv6-PD) in mobile networks, such as networks based on standards
+   developed by the 3rd Generation Partnership Project (3GPP) and it
+   could easily be adopted by the Worldwide Interoperability for
+   Microwave Access (WiMAX) Forum as well.  In view of migration to
+
+
+
+Sarikaya, et al.              Informational                     [Page 3]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   IPv6, the number of MNs connected to the network at a given time may
+   become very high.  Traditional techniques such as prefix pools are
+   not scalable.  In such cases, DHCPv6-PD becomes the viable approach
+   to take.
+
+   The techniques described in this document have not been approved by
+   the IETF or the 3GPP, except for those techniques described below in
+   Section 3.3.  This document is not a Standard or Best Current
+   Practice.  This document is published only for possible consideration
+   by operators.
+
+   This document is useful when address space needs to be managed by
+   DHCPv6-PD.  There are obviously other means of managing address
+   space, including having the AR track internally what address space is
+   used by what mobile.
+
+2.  Terminology and Acronyms
+
+   3GPP - 3rd Generation Partnership Project
+
+   AAA - Authentication, Authorization, and Accounting
+
+   AR - Access Router
+
+   BS - Base Station
+
+   DHCP - Dynamic Host Configuration Protocol
+
+   E-UTRAN - Evolved Universal Terrestrial Radio Access Network
+
+   GPRS - General Packet Radio Service
+
+   LTE - Long-Term Evolution
+
+   MN - Mobile Node
+
+   P2P - Point-to-Point
+
+   PD - Prefix Delegation
+
+   PDN - Packet Data Network
+
+   S-GW - Serving Gateway
+
+   WiMAX - Worldwide Interoperability for Microwave Access
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 4]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+3.  Prefix Delegation Using DHCPv6
+
+   "Access router" refers to the cellular network entity that has a DHCP
+   client.  According to [3GPP-23401], the DHCP client is located in the
+   PDN Gateway, and so the AR is the PDN Gateway in the LTE
+   architecture.
+
+3.1.  Prefix Request Procedure for Stateless Address Configuration
+
+   There are two function modules in the AR: the DHCP client and the
+   DHCP relay.  DHCP messages should be relayed if the AR and a DHCP
+   server are not directly connected; otherwise, the DHCP relay function
+   in the AR is not necessary.  Figure 2 illustrates a scenario in which
+   the AR and the DHCP server aren't directly connected:
+
+     +-------+               +----------------------+    +-----------+
+     |  MN   |               |       AR             |    |DHCP Server|
+     +-------+               |DHCP     |  Relay     |    +-----------+
+         |                   |Client   |  Agent     |          |
+         |                   +----------------------+          |
+         |1 Initial NW entry |                                 |
+         |or attach procedure|                                 |
+         |<----------------->|                                 |
+         |                   |2 Solicit                        |
+         |                   |--------->         Relay-forward |
+         |                   |                 --------------->|
+         |                   |                   3 Relay-reply |
+         |                   |Advertise        <---------------|
+         |                   |<--------                        |
+         |                   |4 Request                        |
+         |                   |--------->         Relay-forward |
+         |                   |                 --------------->|
+         |                   |                   5 Relay-reply |
+         |                   |Reply            <---------------|
+         |                   |<--------                        |
+         |6  Attach          |                                 |
+         | Completed         |                                 |
+         |<----------------->|                                 |
+         |7 Router           |                                 |
+         |  Solicitation     |                                 |
+         |------------------>|                                 |
+         | 8 Router          |                                 |
+         |  Advertisement    |                                 |
+         |<------------------|                                 |
+
+                         Figure 2: Prefix Request
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 5]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   1.  An MN (also referred to as UE, or User Equipment, by the 3GPP)
+       performs initial network entry and authentication procedures,
+       a.k.a. the attach procedure.
+
+   2.  On successful completion of Step 1, the AR initiates the DHCP
+       Solicit procedure to request prefixes for the MN.  The DHCP
+       client in the AR creates and transmits a Solicit message as
+       described in Sections 17.1.1 ("Creation of Solicit Messages") and
+       17.1.2 ("Transmission of Solicit Messages") of [RFC3315].  The
+       DHCP client in an AR that supports DHCPv6 Prefix Delegation
+       [RFC3633] creates an Identity Association for Prefix Delegation
+       (IA_PD) and assigns it an Identity Association IDentifier (IAID).
+       The client must include the IA_PD option in the Solicit message.
+       The DHCP client as Requesting Router (RR) must set the
+       prefix-length field to a value less than, e.g., 48 or equal to 64
+       to request a /64 prefix.  Next, the relay agent in the AR sends
+       to the DHCP server a Relay-forward message in which a Solicit
+       message is encapsulated.
+
+   3.  The DHCP server sends an Advertise message to the AR in the same
+       way as that described in Section 17.2.2 ("Creation and
+       Transmission of Advertise Messages") of [RFC3315].  An Advertise
+       message with the IA_PD shows that the DHCP server is capable of
+       delegating prefixes.  This message is received encapsulated in a
+       Relay-reply message by the relay agent in the AR and is sent as
+       an Advertise message to the DHCP client in the AR.
+
+   4.  The AR (DHCP client and relay agent) uses the same message
+       exchanges as those described in Section 18 ("DHCP Client-
+       Initiated Configuration Exchange") of [RFC3315] and in [RFC3633]
+       to obtain or update prefixes from the DHCP server.  The AR (DHCP
+       client and relay agent) and the DHCP server use the IA_PD Prefix
+       option to exchange information about prefixes in much the same
+       way as IA Address options are used for assigned addresses.  This
+       is accomplished by the AR sending a DHCP Request message and the
+       DHCP server sending a DHCP Reply message.
+
+   5.  The AR stores the prefix information it received in the Reply
+       message.
+
+   6.  A connection between the MN and AR is established, and the link
+       becomes active.  This step completes the Packet Data Protocol
+       (PDP) Context Activation Procedure in Universal Mobile
+       Telecommunications System (UMTS) and PDN connection establishment
+       in LTE networks.
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 6]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   7.  The MN may send a Router Solicitation message to solicit the AR
+       to send a Router Advertisement (RA) message.
+
+   8.  The AR advertises the prefixes received in the IA_PD option to
+       the MN via an RA once the PDP Context/PDN connection is
+       established, or in response to a Router Solicitation message sent
+       from the MN.
+
+   The 4-way exchange between the AR as RR and the DHCP server as
+   Delegating Router (DR), as shown in Figure 2, may be reduced to a
+   two-message exchange by using the Rapid Commit option [RFC3315].  The
+   DHCP client in the AR acting as RR includes a Rapid Commit option in
+   the Solicit message.  The DR then sends a Reply message containing
+   one or more prefixes.
+
+3.2.  Prefix Request Procedure for Stateful Address Configuration
+
+   Stateful address configuration requires a different architecture than
+   that shown in Figure 2; in this type of configuration, there are two
+   function modules in the AR: the DHCP server and the DHCP client.
+
+   After the initial attach is completed, a connection to the AR is
+   established for the MN.  The DHCP client function at the AR as RR and
+   the DHCP server as DR follow Steps 2 through 5 of the procedure shown
+   in Figure 2 to get the new prefix for this interface of the MN from
+   the IA_PD option exchange defined in [RFC3633].
+
+   The DHCPv6 client at the MN sends the DHCP Request to the AR.  The
+   DHCP server function at the AR must use the IA_PD option received in
+   the DHCPv6-PD exchange to assign an address to the MN.  The IA_PD
+   option must contain the prefix.  The AR sends to the MN a DHCP Reply
+   message containing the IA address option (IAADDR).  Figure 3 shows
+   the message sequence.
+
+   The MN configures its interface with the address assigned by the DHCP
+   server in the DHCP Reply message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 7]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   In Figure 3, the AR may be the home gateway of a fixed network to
+   which the MN gets connected during the MN's handover.
+
+    +----------+             +--------------+             +-----------+
+    |  MN      |             |    AR        |             |DHCP Server|
+    |   |DHCP  |             | DHCP |DHCP   |             +-----------+
+    |   |Client|             |Server|Client |
+    +----------+             +--------------+
+        |  Initial NW entry     |                           |
+        |or attach procedure    |                           |
+        |<----------------->    |                           |
+        |                       |      DHCPv6-PD exchange   |
+        |                       |      similar to Steps 2-5 |
+        |   Solicit             |      of Figure 2 (IA_PD)  |
+        |---------------------->|                           |
+        |   Advertise           |                           |
+        |<----------------------|                           |
+        |    Request            |                           |
+        |---------------------->|                           |
+        |                       |                           |
+        |                       |                           |
+        |                       | Use prefix in IA_PD       |
+        |    Reply              | to assign IAADDR          |
+        |<--------------------- |                           |
+
+           Figure 3: Stateful Address Configuration Following PD
+
+3.3.  The MN as Requesting Router in Prefix Delegation
+
+   The AR may use a DHCPv6 Prefix Delegation exchange to get a delegated
+   prefix shorter than /64 by setting the prefix-length field to a value
+   less than 64, e.g., 56 to get a /56 prefix.  Each newly attaching MN
+   first goes through the steps in Figure 2, in which the AR requests a
+   shorter prefix to establish a default connection with the MN.
+
+   The MN may next request additional prefixes (/64 or shorter) from the
+   AR using DHCPv6 Prefix Delegation, where the MN is the RR and the AR
+   is the DR (see [RFC6459] and Section 5.3.1.2.6 of [3GPP-23401]).  In
+   this case, the call flow is similar to that shown in Figure 3.  The
+   Solicit message must include the IA_PD option with the prefix-length
+   field set to 64.  The MN may request more than one /64 prefix.  The
+   AR as DR must delegate these prefixes, excluding the prefix assigned
+   to the default connection.
+
+
+
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 8]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+3.4.  Prefix Release Procedure
+
+   Prefixes can be released in two ways: via prefix aging, or via the
+   DHCP release procedure.  In prefix aging, a prefix should not be used
+   by an MN when the prefix ages, and the DHCP server can delegate it to
+   another MN.  A prefix lifetime is delivered from the DHCPv6 server to
+   the MN via the DHCP IA_PD Prefix option [RFC3633] and the RA Prefix
+   Information option [RFC4861].  Figure 4 illustrates how the AR
+   releases prefixes to a DHCP server that isn't directly connected to
+   the AR:
+
+   1.  A signal that an MN has detached, such as switch-off or handover,
+       triggers the prefix release procedure.
+
+   2.  The AR initiates a Release message to give the prefixes back to
+       the DHCP server.
+
+   3.  The server responds with a Reply message.  The prefixes can then
+       be reused by other MNs.
+
+       +-------+               +-------+             +-----------+
+       |  MN   |               |  AR   |             |DHCP Server|
+       +-------+               +-------+             +-----------+
+           |                       |                       |
+           |  1 De-registration    |                       |
+           |  handover, or other   |                       |
+           |<--------------------->|                       |
+           |                       |2 Relay-forward/Release|
+           |                       |---------------------->|
+           |                       |                       |
+           |                       |3 Relay-reply/Reply    |
+           |                       |<--------------------- |
+           |                       |                       |
+           |                       |                       |
+
+                         Figure 4: Prefix Release
+
+3.5.  Miscellaneous Considerations
+
+3.5.1.  How to Generate an IAID
+
+   The IAID is 4 bytes in length and should be unique in the scope of an
+   AR.  The prefix table should be maintained; this table contains the
+   IAID, the Media Access Control (MAC) address, and the prefix(es)
+   assigned to the MN.  In LTE networks, the International Mobile
+   Equipment Identity (IMEI) uniquely identifies the MN's interface and
+
+
+
+
+
+Sarikaya, et al.              Informational                     [Page 9]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   thus corresponds to the MAC address.  The MAC address of the
+   interface should be stored in the prefix table and is used as the key
+   for searching the table.
+
+   The IAID should be set to Start_IAID; Start_IAID is an integer of
+   4 octets.  The following algorithm is used to generate the IAID:
+
+   1.  Set this IAID value in the IA_PD Prefix option.  Request a prefix
+       for this MN as described in Section 3.1 or Section 3.2.
+
+   2.  Store the IAID, MAC address, and received prefix(es) in the next
+       entry of the prefix table.
+
+   3.  Increment the IAID.
+
+   A prefix table entry for an MN that hands over to another AR must be
+   removed.  The IAID value is released and can then be reused.
+
+3.5.2.  Policy to Delegate Prefixes
+
+   In P2P links, if /64 prefixes of all MNs connected to one or more ARs
+   are broadcast dynamically upstream as route information, high
+   routing-protocol traffic (IGP, OSPF, etc.) due to per-MN interface
+   prefixes will result.  There are two solutions to this problem.  One
+   solution is to use static configuration, which would be preferable in
+   many cases.  No routing protocols are needed, because each AR has a
+   known piece of address space.  If the DHCP servers also know that
+   address space, then they will assign to a particular AR a prefix from
+   that space.
+
+   The other solution is to use route aggregation.  For example, each AR
+   can be assigned a /48 or /32 prefix (an aggregate prefix, a.k.a
+   service provider common prefix), while each interface of an MN can be
+   assigned a /64 prefix.  The /64 prefix is an extension of the /48
+   prefix -- for example, an AR's /48 prefix is 2001:db8:0::/48 -- while
+   an interface of the MN is assigned a 2001:db8:0:2::/64 prefix.  The
+   border router in Figure 1 may be manually configured to broadcast
+   only an individual AR's /48 or /32 prefix information to the
+   Internet.
+
+4.  Prefix Delegation Using RADIUS and Diameter
+
+   In the initial network entry procedure shown in Figure 2, the AR as
+   Remote Authentication Dial In User Service (RADIUS) client sends an
+   Access-Request message with MN information to the RADIUS server.  If
+   the MN passes the authentication, the RADIUS server may send an
+   Access-Accept message with prefix information to the AR using the
+   Framed-IPv6-Prefix attribute.  The AAA server also provides routing
+
+
+
+Sarikaya, et al.              Informational                    [Page 10]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   information to be configured for the MN on the AR using the
+   Framed-IPv6-Route attribute.  Using such a process, the AR can handle
+   initial prefix assignments to MNs, but managing the lifetime of the
+   prefixes is totally left to the AR.  The Framed-IPv6-Prefix is not
+   designed to support delegation of IPv6 prefixes.  For this situation,
+   the Delegated-IPv6-Prefix attribute, which is discussed below, can be
+   used.
+
+   [RFC4818] defines a RADIUS attribute, Delegated-IPv6-Prefix, which
+   carries an IPv6 prefix to be delegated.  This attribute is usable
+   within either RADIUS or Diameter.  [RFC4818] recommends that the DR
+   use the AAA server to receive the prefixes to be delegated, by using
+   the Delegated-IPv6-Prefix attribute/Attribute-Value Pair (AVP).
+
+   The DHCP server as DR, as shown in Figure 2, may send an
+   Access-Request packet containing the Delegated-IPv6-Prefix attribute
+   to the RADIUS server to request prefixes.  In the Access-Request
+   message, the DR may provide a hint that it would prefer a prefix --
+   for example, a /48 prefix.  As the RADIUS server is not required to
+   honor the hint, the server may delegate a longer prefix -- e.g., /56
+   or /64 -- in an Access-Accept message containing the
+   Delegated-IPv6-Prefix attribute [RFC4818].  The attribute can appear
+   multiple times when the RADIUS server delegates multiple prefixes to
+   the DR.  The DR sends the prefixes to the RR using the IA_PD option,
+   and the AR as RR uses them for MNs, as described in Section 3.
+
+   When Diameter is used, the DHCP server as DR, as shown in Figure 2,
+   sends an AA-Request message.  The AA-Request message may contain a
+   Delegated-IPv6-Prefix AVP.  The Diameter server replies with an
+   AA-Answer message.  The AA-Answer message may contain a
+   Delegated-IPv6-Prefix AVP.  The AVP can appear multiple times when
+   the Diameter server assigns multiple prefixes to an MN.  The
+   Delegated-IPv6-Prefix AVP may appear in an AA-Request packet as a
+   hint from the AR to the Diameter server that it would prefer a
+   prefix -- for example, a /48 prefix.  The Diameter server may
+   delegate in the AA-Answer message a /64 prefix, which is an extension
+   of the /48 prefix.  As in the case of RADIUS, the DR sends the
+   prefixes to the RR using the IA_PD option, and the AR as RR uses them
+   for the MNs as described in Section 3.
+
+5.  Security Considerations
+
+   This document does not introduce any additional message types and
+   therefore does not introduce any additional threats.  The security
+   procedures for DHCPv6 [RFC3633], RADIUS [RFC2865], and Diameter
+   [RFC3588] apply.
+
+
+
+
+
+Sarikaya, et al.              Informational                    [Page 11]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+6.  Acknowledgements
+
+   We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole
+   Troan, Qin Wu, Jouni Korhonen, Cameron Byrne, Brian Carpenter, Jari
+   Arkko, and Jason Lin, whose in-depth reviews of this document led to
+   several improvements.
+
+7.  Informative References
+
+   [3GPP-23401]
+              3GPP, "General Packet Radio Service (GPRS) enhancements
+              for Evolved Universal Terrestrial Radio Access Network
+              (E-UTRAN) access (Release 11)", TS 23.401 V11.0.0,
+              December 2011.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, June 2000.
+
+   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
+              Generation Partnership Project (3GPP) Standards",
+              RFC 3314, September 2002.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
+              Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
+              Second and Third Generation Cellular Hosts", RFC 3316,
+              April 2003.
+
+   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+              Host Configuration Protocol (DHCP) version 6", RFC 3633,
+              December 2003.
+
+   [RFC4818]  Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
+              Attribute", RFC 4818, April 2007.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+
+
+
+
+
+Sarikaya, et al.              Informational                    [Page 12]
+
+RFC 6653                    Prefix Delegation                  July 2012
+
+
+   [RFC6342]  Koodli, R., "Mobile Networks Considerations for IPv6
+              Deployment", RFC 6342, August 2011.
+
+   [RFC6459]  Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
+              T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
+              Partnership Project (3GPP) Evolved Packet System (EPS)",
+              RFC 6459, January 2012.
+
+Authors' Addresses
+
+   Behcet Sarikaya
+   Huawei USA
+   5340 Legacy Dr.
+   Plano, TX  75074
+
+   EMail: sarikaya@ieee.org
+
+
+   Frank Xia
+   Huawei USA
+   1700 Alma Drive, Suite 500
+   Plano, TX  75075
+
+   Phone: +1 972-509-5599
+   EMail: xiayangsong@huawei.com
+
+
+   Ted Lemon
+   Nominum
+   2000 Seaport Blvd.
+   Redwood City, CA  94063
+
+   EMail: mellon@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarikaya, et al.              Informational                    [Page 13]
+