    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]