summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6653.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6653.txt')
-rw-r--r--doc/rfc/rfc6653.txt731
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]
+