Skip to main content

DHCPv6 class based prefix
draft-bhandari-dhc-class-based-prefix-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Shwetha Bhandari , Gaurav Halwasia , Sindhura Bandi , Sri Gundavelli , DENG Hui
Last updated 2012-03-12
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bhandari-dhc-class-based-prefix-01
Internet Engineering Task Force                              S. Bhandari
Internet-Draft                                               G. Halwasia
Intended status: Standards Track                                S. Bandi
Expires: September 13, 2012                                S. Gundavelli
                                                           Cisco Systems
                                                                 H. Deng
                                                            China Mobile
                                                          March 12, 2012

                       DHCPv6 class based prefix
                draft-bhandari-dhc-class-based-prefix-01

Abstract

   DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6
   addresses.  This document extends DHCPv6 prefix delegation with class
   based prefix allocation.  It defines a new prefix class option to
   classify a prefix.  It defines the behavior of a DHCPv6 client
   requesting a prefix to include the class of the prefix to be
   allocated and the DHCPv6 server behavior to select and offer a prefix
   from a given class.  It discusses how IA_NA can be requested and
   assigned from a specific prefix class.

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 September 13, 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

Bhandari, et al.       Expires September 13, 2012               [Page 1]
Internet-Draft          DHCPv6 class based prefix             March 2012

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Prefix Class Option in IA_PD . . . . . . . . . . . . . . .  4
     2.2.  Consideration for different DHCPv6 entities  . . . . . . .  5
       2.2.1.  Requesting Router Behavior . . . . . . . . . . . . . .  5
       2.2.2.  Delegating Router Behavior . . . . . . . . . . . . . .  6
       2.2.3.  DHCPv6 Client Behavior for IA_NA allocation  . . . . .  7
     2.3.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.1.  Class based prefix and IA_NA allocation  . . . . . . .  7
       2.3.2.  Class based prefix and IA_PD allocation  . . . . . . .  8
       2.3.3.  Class based prefix and SLAAC . . . . . . . . . . . . .  8
   3.  Example Application  . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Class based prefix delegation  . . . . . . . . . . . . . . 11
     3.2.  IPv6 address assignment from class based prefix  . . . . . 11
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Change History (to be removed prior to publication as an
       RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Bhandari, et al.       Expires September 13, 2012               [Page 2]
Internet-Draft          DHCPv6 class based prefix             March 2012

1.  Introduction

   DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism
   for the delegation of IPv6 prefixes using DHCPv6 options.  Through
   these options, a delegating router can delegate prefixes to
   authorized requesting routers.  If the requesting router has to
   function as a DHCPv6 server there needs to be additional information
   in the delegated prefix that helps the requesting router to select
   the address allocation for the DHCPv6 client it serves, from one of
   the available delegated prefixes.

   One way to select an address or longer prefix (from a delegated
   prefix) to be allocated by a requesting router playing the role of a
   DHCPv6 server is by introducing additional options in IA_PD to be
   matched with options for address selection in the DHCPv6 SOLICIT
   message.  [RFC3315] defines the OPTION_USER_CLASS option which is
   used for selecting address for assignment.  This document introduces
   OPTION_PREFIX_CLASS option in IA_PD option for the purpose of
   selecting a prefix for further delegation either via IA_NA or IA_PD
   DHCPv6 request.  It defines the behavior of the DHCPv6 server, the
   DHCPv6 prefix requesting router and the DHCPv6 client to use this
   option.

1.1.  Motivation

   In this section motivation for class based prefix delegation that
   qualifies the delegated prefix with additional class information is
   described in the context of mobile networks.  The class information
   attached to a delegated prefix helps to distinguish property of a
   delegated IPv6 prefix and selection of the prefix by different
   applications using it.

   In the mobile network architecture, there is a mobile router which
   functions as a IP network gateway and provides IP connectivity to
   mobile nodes.  Mobile router can be the requesting router requesting
   delegated IPv6 prefix using DHCPv6.  Mobile router can assume the
   role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to
   it.  A mobile node in mobile network architecture can be associated
   with multiple IPv6 prefixes belonging to different domains for e.g.
   home address prefix, care of address prefix as specified in
   [RFC3775].

   The delegated prefixes when seen from the mobile router perspective
   appear to be like any other prefix, but each prefixes have different
   properties referred to as "Prefix Color" in the mobile networks.
   Some delegated prefixes may be topologically local and some may be
   remote prefixes anchored on a global anchor, but available to the
   local anchor by means of tunnel setup in the network between the

Bhandari, et al.       Expires September 13, 2012               [Page 3]
Internet-Draft          DHCPv6 class based prefix             March 2012

   local and global anchor.  Some may be local with low latency
   characteristics suitable for voice call break-out, some may have
   global mobility support.  So, the prefixes have different properties
   and it is required for the application using the prefix to learn
   about this property in order to use it intelligently.  There is
   currently no semantics in DHCPv6 prefix delegation that can carry
   this information to specify properties of a delegated prefix.  In
   this scenario, the mobile router is unable to further delegate a
   longer prefix intelligently based on properties of the prefix learnt.

1.2.  Terminology

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

1.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Overview

   This section defines Prefix Class option in IA_PD and IA_NA to aid
   class based prefix delegation and address assignment.  This section
   defines the behavior of the delegating router, the requesting router
   and the DHCPv6 client.

2.1.  Prefix Class Option in IA_PD

Bhandari, et al.       Expires September 13, 2012               [Page 4]
Internet-Draft          DHCPv6 class based prefix             March 2012

   The format of the DHCPv6 Prefix Class option is shown below.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        OPTION_PREFIX_CLASS        |          option-length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        prefix-class                           |
      |                    (variable length)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code:    OPTION_PREFIX_CLASS (TBD)
      option-length:  length of prefix-class
      prefix-class:   Prefix class (binary string).

2.2.  Consideration for different DHCPv6 entities

   The model of operation of communicating prefixes to be used by a
   DHCPv6 server is as follows.  A requesting router requests prefix(es)
   from the delegating router, as described in Section 2.2.1.  A
   delegating router is provided IPv6 prefixes to be delegated to the
   requesting router.  Examples of ways in which the delegating router
   is provided these prefixes are:

   o  Configuration

   o  Prefix delegated via a DHCPv6 request to another DHCPv6 server

   o  Using a Authentication Authorization Accounting (AAA) protocol
      like RADIUS [RFC2865]

   The delegating router chooses prefix(es) for delegation, and responds
   with prefix(es) to the requesting router along with additional
   options in the allocated prefix as described in Section 2.2.2.  The
   requesting router is then responsible for the delegated prefix(es)
   after the DHCPv6 REQUEST message exchange.  For example, the
   requesting router may create DHCPv6 server configuration pools from
   the delegated prefix, and function as a DHCPv6 Server.  When the
   requesting router then receives a DHCPv6 IA_NA requests it can select
   the address to be allocated based on the OPTION_USER_CLASS or
   OPTION_PREFIX_CLASS options received in IA_NA request or any of the
   other methods as described in Section 2.3.1.

2.2.1.  Requesting Router Behavior

   DHCPv6 requesting router can request for prefixes in the following
   ways:

Bhandari, et al.       Expires September 13, 2012               [Page 5]
Internet-Draft          DHCPv6 class based prefix             March 2012

   o  In the SOLICIT message within the IA_PD Prefix option, it MAY
      include OPTION_PREFIX_CLASS requesting prefix delegation for the
      specific class indicated in the OPTION_PREFIX_CLASS option.  It
      can include multiple IA_PD Prefix options to indicate it's
      preference for more than one prefix class.

   o  In the SOLICIT message include an OPTION_ORO option with the
      OPTION_PREFIX_CLASS option code to request prefixes from all the
      classes that the DHCPv6 server can provide to this requesting
      Router.

   The requesting router parses the OPTION_PREFIX_CLASS option in
   theOPTION_IAPREFIX option area of the corresponding IA_PD Prefix
   option in the ADVERTISE message.  The Requesting router MUST then
   include all or subset of the received class based prefix(es) in the
   REQUEST message so that it will be responsible for the prefixes
   selected.

2.2.2.  Delegating Router Behavior

   If the Delegating router supports class based prefix allocation by
   supporting the OPTION_PREFIX_CLASS option and it is configured to
   assign prefixes from different classes, it selects prefixes for class
   based prefix allocation in the following way:

   o  If requesting router includes OPTION_PREFIX_CLASS within the IA_PD
      Prefix option, it selects prefixes to be offered from that
      specific class.

   o  If requesting router includes OPTION_PREFIX_CLASS within
      OPTION_ORO, then based on its configuration and policy it MAY
      offer prefixes from multiple classes available.

   The delegating router responds with an ADVERTISE message after
   populating the IP_PD option with prefixes from different prefix
   classes.  Along with including the IA_PD prefix options in the IA_PD
   option, it also includes the OPTION_PREFIX_CLASS option in the
   OPTION_IAPREFIX option area of the corresponding IA_PD prefix option.

   If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message
   include the OPTION_PREFIX_CLASS option, then the delegating router
   MAY allocate the prefix as specified in [RFC3633] without including
   the class option in the IA_PD prefix option in the response.

   If OPTION_ORO option in the Solicit message includes the
   OPTION_PREFIX_CLASS option code but the delegating router does not
   support the solution described in this specification, then the
   delegating router acts as specified in [RFC3633].  The requesting

Bhandari, et al.       Expires September 13, 2012               [Page 6]
Internet-Draft          DHCPv6 class based prefix             March 2012

   router MUST in this case also fall back to the behavior specified in
   [RFC3633].

   If both delegating and requesting routers support class-based prefix
   allocation, but the delegating router cannot offer prefixes for any
   other reason, it MUST respond to requesting router with appropriate
   status code as specified in [RFC3633].  For e.g., if no prefixes are
   available in the specified class then the delegating router MUST
   include the status code NoPrefixAvail in the response message.

2.2.3.  DHCPv6 Client Behavior for IA_NA allocation

   DHCPv6 client MAY request for an IA_NA address allocation from a
   specific prefix class in the following way:

   o  In the SOLICIT message within the IA_NA option, it MAY include the
      OPTION_PREFIX_CLASS requesting address to be allocated from a
      specific prefix class indicated in that option.

   The DHCPv6 server parses OPTION_PREFIX_CLASS option received and
   includes it in option area of corresponding OPTION_IA_NA in ADVERTISE
   message.

2.3.  Usage

   Class based prefix delegation can be used by the requesting router to
   configure itself as a DHCPv6 server to serve its DHCPv6 clients.  It
   can allocate longer prefixes from a delegated shorter prefix it
   received, for serving IA_NA and IA_PD requests.

2.3.1.  Class based prefix and IA_NA allocation

   The requesting router can use the delegated prefix(es) from different
   classes (for example "video", "guest", "voice" etc), for assigning
   the IPv6 addresses to the end hosts through DHCPv6 IA_NA based on a
   preconfigured mapping with OPTION_PREFIX_CLASS option, the following
   conditions MAY be observed:

   o  It MAY have a pre-configured mapping between the prefix class and
      OPTION_USER_CLASS option received in IA_NA.

   o  It MAY match the OPTION_PREFIX_CLASS if the IA_NA request received
      contains OPTION_PREFIX_CLASS.

   o  It MAY map OPTION_PREFIX_CLASS option to the OPTION_USER_CLASS
      option by string matching of both these option values.

Bhandari, et al.       Expires September 13, 2012               [Page 7]
Internet-Draft          DHCPv6 class based prefix             March 2012

   o  It MAY have a pre-configured mapping between the prefix class and
      the client DUID received in DHCPv6 message.

   o  It MAY have a pre-configured mapping between the prefix class and
      its network interface on which the IA_NA request was received.

   The requesting router playing the role of a DHCPv6 server can
   ADVERTISE IA_NA from a class of prefix(es) thus selected.

2.3.2.  Class based prefix and IA_PD allocation

   If the requesting router, receives prefix(es) for different classes
   (for example "video", "guest", "voice" etc), it can use these
   prefix(es) for assigning the longer IPv6 prefixes to requesting
   routers it serves through DHCPv6 IA_PD by assuming the role of
   delegating router, its behavior is explained in Section 2.2.2.

2.3.3.  Class based prefix and SLAAC

   DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as
   defined in [RFC4862]) are two ways by IPv6 addresses can be
   dynamically assigned to end hosts.  Making SLAAC class aware is
   outside the scope of this document.

3.  Example Application

   The following sub-sections provide examples of class based prefix
   delegation and how it is used in a mobile network.  Each of the
   examples will refer to the below network:

   The example network consists of :

   Mobile Gateway It is network entity anchoring IP traffic in the
   mobile core network.  This entity allocates an IP address which is
   topologically valid in the mobile network and may act as a mobility
   anchor if handover between mobile and Wi-Fi is supported.

   Mobile Nodes (MN) A host or router that changes its point of
   attachment from one network or subnetwork to another.  A mobile node
   may change its location without changing its IP address; it may
   continue to communicate with other Internet nodes at any location
   using its (constant) IP address, assuming link-layer connectivity to
   a point of attachment is available.

   Access Point (AP) A wireless access point, identified by a MAC
   address, providing service to the wired network for wireless nodes.

Bhandari, et al.       Expires September 13, 2012               [Page 8]
Internet-Draft          DHCPv6 class based prefix             March 2012

   Access Router (AR) An IP router residing in an access network and
   connected to one or more Acess Point(AP)s.  An AR offers IP
   connectivity to MNs.

   WLAN controller (WLC) The entity that provides the centralized
   forwarding, routing function for the user traffic.

Bhandari, et al.       Expires September 13, 2012               [Page 9]
Internet-Draft          DHCPv6 class based prefix             March 2012

   Example mobile network
          _----_           _----_           _----_
        _(      )_       _(      )_       _(      )_
       (Operator-1)     (Operator-2)     (Operator-3)
        (_      _)       (_      _)       (_      _)
           -+--             -+--            '-+--'
       +--------+       +--------+       +--------+
       | Mobile |       | Mobile |       | Mobile |
       |gateway |       |gateway |       |gateway |
       +--------+       +--------+       +--------+
            |                |                |
            +-------------.  |  .-------------+
                          |  |  |
                          |  |  |
                          |  |  |P1:"global-anchor"
                          |  |  |
                        +--------+                     _----_
     +---+              |        |P2:"local-breakout"_(      )_
     |AAA|. . . . . . . | Access |------------------( Internet )
     +---+              | Aggreg |-----------+       (_      _)
                        | Gateway| P3:"guest"|         '----'
                        +--------+           |
                            |   |             +----- Guest Access
                            |   |                      Network
                            |   +-------------+
                            |                 |
                            |              +-----+
                            |              | AR  |
                         +-----+           +-----+
                         | WLC |        * ---------*
                         |     |        (    LAN    )
                         +-----+        * ---------*
                         /    \             /    \
                      +----+  +----+     +----+  +----+
                      |WiFi|  |WiFi|     |WiFi|  |WiFi|
                      | AP |  | AP |     | AP |  | AP |
                      +----+  +----+     +----+  +----+
                        .                  .
                       / \                / \
                     MN1 MN2            MN3 MN4(guest)

                                 Figure 1

Bhandari, et al.       Expires September 13, 2012              [Page 10]
Internet-Draft          DHCPv6 class based prefix             March 2012

3.1.  Class based prefix delegation

   The Access Aggregation Gateway requests for Prefix delegation from
   Mobile gateway and associates the prefix received with prefix class
   "global-anchor".  The Access Aggregation Gateway is preconfigured to
   provide prefixes from the following classes: "global-anchor", "local-
   breakout", "guest".  It has a preconfigured policy to advertise
   prefixes to requesting routers and mobile nodes based on the service
   class supported by the service provider for the requesting device.
   In the example mobile network, the Access Router(AR) requests class
   based prefix allocation by sending a DHCPv6 SOLICIT message and
   include OPTION_PREFIX_CLASS in the OPTION_ORO.

   The Access Router (AR) receives an advertise with following prefixes
   in the IA_PD option:

   1.  P1: IA_PD Prefix option with a prefix 3001::1::/64 containing
       OPTION_PREFIX_CLASS set to "global-anchor"

   2.  P2: IA_PD Prefix option with a prefix 3001::2::/64 containing
       OPTION_PREFIX_CLASS set to "local-breakout"

   3.  P3: IA_PD Prefix option with a prefix 3001::3::/64 containing
       OPTION_PREFIX_CLASS set to "guest"

   It sends a REQUEST message with all of above prefixes and receives a
   REPLY message with prefixes allocated for each of the requested
   class.

3.2.  IPv6 address assignment from class based prefix

   When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA
   from the mobile node that has mobility service enabled, it offers an
   IPv6 address from the prefix class "global-anchor".  For MN3 it
   advertises 3001::1::1 as the IPv6 address in OPTION_IAADDR in
   response to the IA_NA request.

   The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message
   requesting IA_NA address assignment with OPTION_USER_CLASS option
   containing the value "guest" towards the CPE.  The Access Router(AR)
   assumes the role of the DHCPv6 server and sends an ADVERTISE to the
   MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from
   the "guest" prefix class.  The IPv6 address in the OPTION_IAADDR is
   set to 3001::3::1.  The "guest" class can also be distinguished based
   on a preconfigured interface or SSID advertised for MNs connecting to
   it.

   When the Access Aggregation Gateway receives a DHCPv6 SOLICIT

Bhandari, et al.       Expires September 13, 2012              [Page 11]
Internet-Draft          DHCPv6 class based prefix             March 2012

   requesting IA_NA from MNs through WLC and it has a preconfigured
   profile to provide both local-breakout internet access and global-
   anchor, it offers an IPv6 address from the prefix class "local-
   breakout" and "global-anchor".  For MN1 it advertises 3001::2::1 and
   3001::1::2 as the IPv6 address in OPTION_IAADDR in response to the
   IA_NA request.  Applications within MN1 can choose to use the
   appropriate prefix based on the mobility enabled or local-breakout
   property.

4.  Acknowledgements

   The authors would like to acknowledge review and guidance received
   from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark,
   Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz

5.  IANA Considerations

   IANA is requested to assign an option code to OPTION_PREFIX_CLASS
   from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/
   assignments/dhcpv6-parameters/dhcpv6-parameters.xml).

6.  Security Considerations

   Security issues related to DHCPv6 which are described in section 23
   of [RFC3315] and [RFC3633] apply for scenarios mentioned in this
   draft as well.

7.  Change History (to be removed prior to publication as an RFC)

   Changes from -00 to -01

   a.  Modified motivation section to focus on mobile networks

   b.  Modified example with a mobile network and class based prefix
       delegation in it

8.  References

8.1.  Normative References

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

Bhandari, et al.       Expires September 13, 2012              [Page 12]
Internet-Draft          DHCPv6 class based prefix             March 2012

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

8.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

Authors' Addresses

   Shwetha Bhandari
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone:
   Email: shwethab@cisco.com

Bhandari, et al.       Expires September 13, 2012              [Page 13]
Internet-Draft          DHCPv6 class based prefix             March 2012

   Gaurav Halwasia
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 1321
   Email: ghalwasi@cisco.com

   Sindhura Bandi
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 2347
   Email: sinb@cisco.com

   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

   Hui Deng
   China Mobile
   53A, Xibianmennei Ave., Xuanwu District
   Beijing  100053
   China

   Email: denghui02@gmail.com

Bhandari, et al.       Expires September 13, 2012              [Page 14]