[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6653

Network Working Group                                        B. Sarikaya
Internet-Draft                                                    F. Xia
Intended status: BCP                                          Huawei USA
Expires: April 15, 2011                                 October 12, 2010


   DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks
            <draft-sarikaya-v6ops-prefix-delegation-02.txt>

Abstract

   As interest on IPv6 deployment is increasing in cellular networks
   several migration issues are being raised and IPv6 prefix management
   is the one addressed in this document.  Based on the idea that DHCPv6
   servers can manage prefixes, we address prefix management issues such
   as the access router offloading delegation and release tasks of the
   prefixes to a DHCPv6 server using DHCPv6 PD.  The access router first
   requests a prefix for an incoming mobile node from the DHCPv6 server.
   The access router may next 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 servers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 15, 2011.

Copyright Notice

   Copyright (c) 2010 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



Sarikaya & Xia           Expires April 15, 2011                 [Page 1]


Internet-Draft              Prefix Delegation               October 2010


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   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.  Prefix Release Procedure . . . . . . . . . . . . . . . . .  8
     3.4.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.4.1.  Renumbering Through Renew Message  . . . . . . . . . .  9
       3.4.2.  Server Initiated Reconfiguration . . . . . . . . . . .  9
     3.5.  Miscellaneous Considerations . . . . . . . . . . . . . . .  9
       3.5.1.  Triggers for an AR to Initiate Prefix Request
               Procedure  . . . . . . . . . . . . . . . . . . . . . .  9
       3.5.2.  How to Generate IAID . . . . . . . . . . . . . . . . . 10
       3.5.3.  Policy to Delegate Prefixes  . . . . . . . . . . . . . 10
   4.  Prefix Delegation Using RADIUS and Diameter  . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Protocol Variables . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
















Sarikaya & Xia           Expires April 15, 2011                 [Page 2]


Internet-Draft              Prefix Delegation               October 2010


1.  Introduction

   Figure 1 illustrates the key elements of a typical cellular access
   network.  In a Long Term Evolution (LTE) network, access router is
   the packet data network (PDN) gateway [23.401].

                                         +-----------------------+
                                         |             +------+  |
                                         |             |DHCP  |  |
 +-----+   +-----+   +------+  +------+  |             |Server|  | +--------+
 | UE  |---| BS  |---+Access+--+Access+--+             +------+  +-+ Border |
 +-----+   +-----+   |  GW  |  |Router|  |    IP Network(s)      | | Router +-Internet
                     +--+---+  +--+---+  |                       | +--------+
                        |         |      +-----------------------+
 +-----+   +-----+      |         |    +------+
 | UE  |---| BS  |------+         |    |AAA   |
 +-----+   +-----+                +--- |Server|
                                       +------+

           Figure 1: Key elements of a typical cellular network

   User equipment (UE) attaches to a base station (BS) through LTE air
   interface.  A BS manages connectivity of UEs and extends connections
   to an Access Gateway (GW), e.g. the serving gateway (S-GW) in an LTE
   network.  The access gateway and the Access router are connected with
   an IP network.  The access router is the first hop router of UEs and
   it is in charge of address/prefix management.

   Access router is connected to an IP network which is owned by the
   operator which 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 DHCP
   server [I-D.ietf-v6ops-v6-in-mobile-networks].

   As to IPv6 addressing, there are two models, shared prefix and Per-MN
   interface prefix.  In the shared prefix model, an IPv6 prefix is
   shared by multiple MNs.  While in the Per-MN interface prefix model,
   a prefix is only assigned to one interface of the MN.  Different MNs
   can't share a prefix, and an interface can have multiple prefixes.

   [RFC4968] briefly compares the two models.  Per-MN interface prefix
   model has some advantages, such as, no complicated duplicate address
   detection (DAD), fit naturally to the point-to-point links and so on.
   In Per-MN interface prefix model, prefix management is an issue.

   When an MN attaches an AR, the AR requests one or more prefixes for
   the MN.  When the MN detaches the AR, the prefixes should be
   released.  When the MN becomes idle, the AR should hold the prefixes



Sarikaya & Xia           Expires April 15, 2011                 [Page 3]


Internet-Draft              Prefix Delegation               October 2010


   allocated.  When an operator wants to renumber its network, prefixes
   with different lifetime are advertised to the MN.

   This document describes how to use DHCPv6 Prefix Delegation in mobile
   networks such as networks based on standards developed by 3GPP or
   WiMAX Forum.  The use of prefix delegation for stateless and stateful
   address configuration is described in Section 3, and Section 4 is on
   the use of AAA protocols in prefix delegation.











































Sarikaya & Xia           Expires April 15, 2011                 [Page 4]


Internet-Draft              Prefix Delegation               October 2010


2.  Terminology

   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 BCP 14 [RFC2119].

   This document uses the terminology defined in [RFC3315], [RFC3633]
   and [23.401].


3.  Prefix Delegation Using DHCPv6

   Access router refers to the cellular network entity that has DHCP
   Client.  According to [23.401] DHCP Client is located in PDN Gateway.
   So AR is the PDN Gateway in LTE architecture.

3.1.  Prefix Request Procedure for Stateless Address Configuration

   There are two function modules in the AR, DHCP Client and DHCP Relay.
   DHCP messages should be relayed if the AR and a DHCP server are not
   connected directly, otherwise DHCP relay function in the AR is not
   necessary.  Figure 2 illustrates the scenario that the AR and the
   DHCP Server aren't connected directly:




























Sarikaya & Xia           Expires April 15, 2011                 [Page 5]


Internet-Draft              Prefix Delegation               October 2010


       +-------+               +----------------------+    +-----------+
       |  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 |
           |                   |Repl             <---------------|
           |                   |<--------                        |
           |6  PDP Context     |                                 |
           | Established (Opt.)|                                 |
           |<----------------->|                                 |
           |7 Router           |                                 |
           |  Advertisement    |                                 |
           |<------------------|                                 |
           | 8 MLD Join        |                                 |
           |------------------>|                                 |
           |                   |                                 |
           | 9 DAD Procedure   |                                 |
           |<----------------->|                                 |

                         Figure 2: Prefix request

   1.  An MN (UE) performs initial network entry and authentication
       procedures, a.k.a. attach procedure.
   2.  On successful completion of Step 1, the AR initiates DHCP Solicit
       procedure to request prefixes for the MN.  The DHCP Client in 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 AR that
       supports DHCPv6 Prefix Delegation [RFC3633] creates an IA_PD and
       assigns it an IAID.  The Client MUST include the IA_PD option in
       the Solicit message.  Next, the Relay Agent in AR sends Relay-
       Forward message to the DHCP Server encapsulating Solicit message.
   3.  The DHCP server sends an Advertise message to the AR in the same
       way as described in section 17.2.2, "Creation and transmission of
       Advertise messages" of [RFC3315].  This message is received



Sarikaya & Xia           Expires April 15, 2011                 [Page 6]


Internet-Draft              Prefix Delegation               October 2010


       encapsulated in Relay-Reply message by the Relay Agent in AR and
       sent as Solicit message to the DHCP Client in AR.
   4.  The AR (DHCP Client and Relay Agent) uses the same message
       exchanges as described in section 18, "DHCP Client-Initiated
       Configuration Exchange" of [RFC3315] and [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.
   5.  AR stores the prefix information it received in the Reply
       message.
   6.  A connection between MN and AR is established and the link
       becomes active.  This step (called PDP Context Activation
       Procedure in UMTS networks) is optional and it is performed
       during the initial attach of Step 1 in LTE networks.
   7.  The AR advertises the prefixes received in IA_PD option to MN
       with router advertisement (RA) once the virtual link is active.
   8.  The MN constructs a solicited node multicast address for the
       corresponding Link Local Address and sends MLD Join request for
       the solicited node multicast address.
   9.  The MN starts verifying address uniqueness by sending a DAD NS on
       the virtual link.  AR can check the address uniqueness within the
       virtual link scope.

   4-way exchange between AR as requesting router (RR) and DHCP server
   as delegating router (DR) in Figure 2 MAY be reduced into a two
   message exchange using the Rapid Commit option [RFC3315].  DHCP
   Client in AR acting as RR includes a Rapid Commit option in the
   Solicit message.  DR then sends a Reply message containing one or
   more prefixes.

3.2.  Prefix Request Procedure for Stateful Address Configuration

   After the initial attach is completed, a connection to the AR is
   established for the MN.  DHCP Client and Relay follow the procedure
   shown in Figure 2 to get the new prefix for this interface of MN.

   DHCPv6 client at the MN sends DHCP Request to DHCP Relay function at
   AR.  AR MUST make sure that DHCP server assigns MN address from this
   prefix.  AR as DHCP Relay forwards DHCP Request message in DHCP Relay
   Option and adds IA_PD option defined in [RFC3633] to the message.
   IA_PD option MUST contain the prefix.  DHCP server MUST process IA_PD
   Option and MUST assign an address to MN using the prefix in IA_PD
   Option.  DHCP server replies with Relay reply message.  DHCP Relay
   sends DHCP Reply message to MN containing IA address option (IAADDR).
   Figure 3 shows the message sequence.

   MN configures its interface with the address assigned by DHCP server



Sarikaya & Xia           Expires April 15, 2011                 [Page 7]


Internet-Draft              Prefix Delegation               October 2010


   in DHCP Reply message.

       +-------+               +-------+             +-----------+
       |  MN   |               |  AR   |             |DHCP Server|
       +-------+               +-------+             +-----------+
           |   Solicit             |                       |
           |---------------------->|                       |
           |                       |  Relay-forward        |
           |                       |---------------------> |
           |                       |  Relay-reply          |
           |    Advertise          |<--------------------- |
           |<----------------------|                       |
           |    Request            |                       |
           |---------------------->|                       |
           |                       |  Relay-forward (IA_PD)|
           |                       |---------------------> |
           |                       |  Relay-reply (IAADDR) |
           |    Reply              |<--------------------- |
           |<--------------------- |                       |


           Figure 3: Stateful Address Configuration Following PD

3.3.  Prefix Release Procedure

   Prefixes can be released in two ways, prefix aging or DHCP release
   procedure.  In the former way, 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
   through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information
   option [RFC4861].  Figure 4 illustrates how the AR releases prefixes
   to an DHCP Server which isn't connected directly:

   1.  An MN detachment signaling, such as switch-off or handover,
       triggers prefix release procedure.
   2.  The AR initiates a Release message to give back the prefixes to
       the DHCP server.
   3.  The server responds with a Reply message, and then the prefixes
       can be reused by other MNs.












Sarikaya & Xia           Expires April 15, 2011                 [Page 8]


Internet-Draft              Prefix Delegation               October 2010


       +-------+               +-------+             +-----------+
       |  MN   |               |  AR   |             |DHCP Server|
       +-------+               +-------+             +-----------+
           |                       |                       |
           |  1 De-registration    |                       |
           |  Handover, or others  |                       |
           |<--------------------->|                       |
           |                       |2 Relay-forward/Release|
           |                       |---------------------->|
           |                       |                       |
           |                       |3 Relay-reply/Reply    |
           |                       |<--------------------- |
           |                       |                       |
           |                       |                       |

                         Figure 4: Prefix Release

3.4.  Renumbering

3.4.1.  Renumbering Through Renew Message

   To extend the valid and preferred lifetimes for the prefixes
   associated with an MN, the AR sends a Renew message to the DHCP
   server.  The server determines new lifetimes for the prefixes and
   returns the prefix to AR in a Reply message.  The DHCP server MAY add
   new prefixes to the MN for renumbering in its Reply message.  For a
   more detailed description of these message, refer to [RFC3633] and of
   renumbering, refer to [RFC4192].

3.4.2.  Server Initiated Reconfiguration

   DHCP server initiates a configuration message exchange with the AR by
   sending a Reconfigure message.  The reconfigure message triggers the
   AR to send Renew message as described in Section 3.4.1.

3.5.  Miscellaneous Considerations

3.5.1.  Triggers for an AR to Initiate Prefix Request Procedure

   There are some other triggers for an AR to initiate prefix request
   procedure besides network entry and authentication, such as, when an
   AR receives handover initiate (HI) message in FMIPv6 [RFC5568], or
   other handover signaling.  After getting an incoming MN's necessary
   information (such as MAC address), the AR SHOULD initiate prefix
   request procedure as soon as possible.






Sarikaya & Xia           Expires April 15, 2011                 [Page 9]


Internet-Draft              Prefix Delegation               October 2010


3.5.2.  How to Generate IAID

   IAID is 4 bytes in length and should be unique in an AR scope.
   Prefix table SHOULD be maintained.  Prefix table contains IAID, MAC
   address and the prefix(es) assigned to MN.  In LTE networks,
   International Mobile Subscriber Identity (IMNI) corrsponds to the MAC
   address.  MAC address of the interface SHOULD be stored in the prefix
   table and this field is used as the key for searching the table.

   IAID SHOULD be set to Start_IAID, an integer of 4 octets.  The
   following IAID generation algorithm is used:

   1.  Set this IAID value in IA_PD Prefix Option.  Request prefix for
       this MN as in Section 3.1 or Section 3.2.
   2.  Store IAID, MAC address and the prefix(es) received in the next
       entry of the prefix table.
   3.  Increment IAID.

   Prefix table entry for an MN that handsover to another AR MUST be
   removed.  IAID value is released to be reused.

3.5.3.  Policy to Delegate Prefixes

   AR should broadcast the prefix(es) dynamically upstream as the route
   information of all the MNs connected to this AR.  In point-to-point
   links, this causes high routing protocol traffic (IGMP, OSPF, etc.)
   due to Per-MN interface prefixes.  To solve the problem, route
   aggregation SHOULD be used.  For example, each AR can be assigned a
   /48 or /32 prefix (aggregate prefix, aka service provider common
   prefix) while each interface of MN can be assigned a /64 prefix.  The
   /64 prefix is an extension of /48 one, for example, an AR's /48
   prefix is 3FFE:FFFF:0::/48, an interface of MN is assigned 3FFE:FFFF:
   0:2::/64 prefix.  The AR only broadcasts it's /48 or /32 prefix
   information to Internet.

   This policy can be enforced as follows: DHCP Relay MUST set the IPv6
   Prefix field in IA_PD Prefix option in IA_PD option in the Relay
   Forward message to the aggregate prefix (/48, /32, or /16 prefix
   assigned to the AR).


4.  Prefix Delegation Using RADIUS and Diameter

   In the initial network entry procedure Figure 2, AR as RADIUS client
   sends Access-Request message with MN information to RADIUS server.
   If the MN passes the authentication, the RADIUS server may send
   Access-Accept message with prefix information to the AR using Framed-
   IPv6-Prefix attribute.  AAA server also provides routing information



Sarikaya & Xia           Expires April 15, 2011                [Page 10]


Internet-Draft              Prefix Delegation               October 2010


   to be configured for MN on the AR using Framed-IPv6-Route attribute.
   Using such a process AR can handle initial prefix assignments to MNs
   but managing lifetime of the prefixes is totally left to the AR.
   Framed-IPv6-Prefix is not designed to support delegation of IPv6
   prefixes.  For this Delegated-IPv6-Prefix attribute can be used which
   is discussed next.

   [RFC4818] defines a RADIUS attribute Delegated-IPv6-Prefix that
   carries an IPv6 prefix to be delegated.  This attribute is usable
   within either RADIUS or Diameter.  [RFC4818] recommends the
   delegating router to use AAA server to receive the prefixes to be
   delegated using Delegated-IPv6-Prefix attribute/AVP.

   DHCP server as the delegating router in Figure 2 MAY send an Access-
   Request packet containing Delegated-IPv6-Prefix attribute to the
   RADIUS server to request prefixes.  In the Access-Request message,
   the delegating router MAY provide a hint that it would prefer a
   prefix, for example, a /48 prefix.  The RADIUS server MAY delegate a
   /64 prefix which is an extension of the /48 prefix in an Access-
   Accept message containing Delegated-IPv6-Prefix attribute.  The
   attribute can appear multiple times when RADIUS server delegates
   multiple prefixes to the delegating router.  The delegating router
   sends the prefixes to the requesting router using IA_PD Option and AR
   as RR uses them for MN's as described in .

   When Diameter is used, DHCP server as the delegating router in
   Figure 2 sends AA-Request message.  AA-Request message MAY contain
   Delegated-IPv6-Prefix AVP.  Diameter server replies with AA-Answer
   message.  AA-Answer message MAY contain Delegated-IPv6-Prefix AVP.
   The AVP can appear multiple times when Diameter server assigns
   multiple prefixes to MN.  The Delegated-IPv6-Prefix AVP MAY appear in
   an AA-Request packet as a hint by the AR to the Diameter server that
   it would prefer a prefix, for example, a /48 prefix.  Diameter server
   MAY delegate in an AA-Answer message with a /64 prefix which is an
   extension of the /48 prefix.  As in the case of RADIUS, the
   delegating router sends the prefixes to the requesting router using
   IA_PD Option and AR as RR uses them for MN's as described in .


5.  Security Considerations

   This draft introduces no additional messages.  Comparing to
   [RFC3633], [RFC2865] and [RFC3588] there is no additional threats to
   be introduced.  DHCPv6, RADIUS and Diameter security procedures
   apply.






Sarikaya & Xia           Expires April 15, 2011                [Page 11]


Internet-Draft              Prefix Delegation               October 2010


6.  Protocol Variables

   Start_IAID 4 octet integer value.

   It can be initialized to ZERO.


7.  IANA Considerations

   None.


8.  Acknowledgements

   We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao and
   others who provided in depth reviews of this document that have led
   to several imrpovements.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [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.

   [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,



Sarikaya & Xia           Expires April 15, 2011                [Page 12]


Internet-Draft              Prefix Delegation               October 2010


              December 2003.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [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.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

9.2.  Informative References

   [23.401]   "3GPP TS 23.401 V9.3.0, General Packet Radio Service
              (GPRS) enhancements for Evolved Universal Terrestrial
              Radio Access Network  (E-UTRAN) access (Release 9).",
              2009.

   [23.812]   "3GPP TR 23.812 V9.0.0, Feasibility Study on the Security
              Aspects of Remote Provisioning and Change of Subscription
              for M2M Equipment; (Release 9).", 2009.

   [I-D.ietf-v6ops-v6-in-mobile-networks]
              Koodli, R., "Mobile Networks Considerations for IPv6
              Deployment", draft-ietf-v6ops-v6-in-mobile-networks-01
              (work in progress), July 2010.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4968]  Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
              Based Networks", RFC 4968, August 2007.







Sarikaya & Xia           Expires April 15, 2011                [Page 13]


Internet-Draft              Prefix Delegation               October 2010


Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Email: sarikaya@ieee.org


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


































Sarikaya & Xia           Expires April 15, 2011                [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/