Internet DRAFT - draft-bhandari-dhc-class-based-prefix

draft-bhandari-dhc-class-based-prefix







Internet Engineering Task Force                              S. Bhandari
Internet-Draft                                               G. Halwasia
Intended status: Standards Track                           S. Gundavelli
Expires: January 16, 2014                                  Cisco Systems
                                                                 H. Deng
                                                            China Mobile
                                                             L. Thiebaut
                                                          Alcatel-Lucent
                                                             J. Korhonen
                                                          Renesas Mobile
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                           July 15, 2013


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

Abstract

   This document introduces options to communicate property and
   associate meta data with prefixes.  It extends DHCPv6 prefix
   delegation and address allocation using the meta data for selection
   of prefixes and addresses.

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 January 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Bhandari, et al.        Expires January 16, 2014                [Page 1]

Internet-Draft          DHCPv6 class based prefix              July 2013


   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.  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.1.1.  Mobile networks . . . . . . . . . . . . . . . . . . .   4
       1.1.2.  Home networks . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Prefix Property and Class Options . . . . . . . . . . . .   5
     2.2.  Consideration for different DHCPv6 entities . . . . . . .   6
       2.2.1.  Requesting Router Behavior for IA_PD allocation . . .   7
       2.2.2.  Delegating Router Behavior for IA_PD allocation . . .   8
       2.2.3.  DHCPv6 Client Behavior for IA_NA allocation . . . . .   9
       2.2.4.  DHCPv6 Server Behavior for IA_NA allocation . . . . .   9
     2.3.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       2.3.1.  Class based prefix and IA_NA allocation . . . . . . .  10
       2.3.2.  Class based prefix and IA_PD allocation . . . . . . .  10
       2.3.3.  Class based prefix and SLAAC  . . . . . . . . . . . .  10
       2.3.4.  Class based prefix and applications . . . . . . . . .  11
   3.  Example Application . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Mobile gateway example  . . . . . . . . . . . . . . . . .  11
       3.1.1.  Class based prefix delegation . . . . . . . . . . . .  13
       3.1.2.  IPv6 address assignment from class based prefix . . .  13
     3.2.  Homenet Example . . . . . . . . . . . . . . . . . . . . .  14
       3.2.1.  Class based prefix delegation to the HGW  . . . . . .  15
       3.2.2.  IPv6 Assignment to Homenet hosts using stateful
               DHCPv6  . . . . . . . . . . . . . . . . . . . . . . .  16
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  OPTION_PREFIX_PROPERTY values . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  Change History (to be removed prior to publication as an RFC)  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20



Bhandari, et al.        Expires January 16, 2014                [Page 2]

Internet-Draft          DHCPv6 class based prefix              July 2013


1.  Introduction

   In IPv6 a network interface can acquire multiple addresses from the
   same scope.  In such a multi-prefix network each of the multiple
   prefixes can have a specific property and purpose associated with it.
   Example: In a mobile network a mobile device can be assigned a prefix
   from its home network and another from the visiting network that it
   is attached to.  Another example is a prefix may provide free
   Internet access without offering any quality of service guarantees
   while another prefix may be charged along with providing quality of
   service guarantees for network service access.  A prefix can have
   well defined properties that is universal and have a meta data
   associated with it that communicates its local significance.  The
   properties and meta data of prefix will be relevant for prefix
   delegation, source address selection as elaborated in the subsequent
   sections.

   This document defines OPTION_PREFIX_PROPERTY option that communicates
   property of the prefix that is universally understood.  This document
   defines OPTION_PREFIX_CLASS option to communicate meta data of the
   prefix that communicates the prefix's local significance.

   This document discusses usage of OPTION_PREFIX_CLASS to request and
   select prefixes with specific meta data via IA_PD and IA_NA as
   defined in [RFC3633] and[RFC3315] respectively.  This document
   defines the behavior of the DHCPv6 server, the DHCPv6 prefix
   requesting router and the DHCPv6 client to use OPTION_PREFIX_CLASS
   option for requesting and selecting prefixes and addresses.

   The network address can be configured via DHCPv6 as defined in
   [RFC3315] or via Stateless Address Autoconfiguration (SLAAC) as
   defined in [RFC4862], additional information of a prefix can be
   provided via DHCPv6 or via IPv6 Router Advertisement (RA).  The
   information provided in the options defined in this document
   OPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS can be used for source
   address selection.  Communicated property and meta data information
   about the prefix via IPv6 Router Advertisement (RA) will be dealt
   with in separate document [I-D.korhonen-6man-prefix-properties].

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 and home networks.  The
   property information attached to a delegated prefix helps to
   distinguish a delegated IPv6 prefix and selection of the prefix by
   different applications using it.




Bhandari, et al.        Expires January 16, 2014                [Page 3]

Internet-Draft          DHCPv6 class based prefix              July 2013


1.1.1.  Mobile networks

   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
   meta data 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 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.  Neither is a
   mobile device able to learn about the property of the prefix assigned
   to influence source address selection.  Example to determine if the
   prefix is a home address or care of address.

1.1.2.  Home networks

   In a fixed network environment, the homenet CPE may also function as
   both a DHCPv6 client (requesting the IA_PD(s)) and a DHCPv6 server
   allocating prefixes from delegated prefix(es) to downstream home
   network hosts.  Some service providers may wish to delegate multiple
   prefixes to the CPE for use by different services classes and traffic
   types.

   Motivations for this include:

   o  Using source prefix to identify the service class / traffic type
      that is being transported.  The source prefix may then reliably be
      used as a parameter for differentiated services or other purposes.
      E.g. [I-D.jiang-v6ops-semantic-prefix]





Bhandari, et al.        Expires January 16, 2014                [Page 4]

Internet-Draft          DHCPv6 class based prefix              July 2013


   o  Using the specific source prefix as a host identifier for other
      services.  E.g. as an input parameter to a DHCPv4 over IPv6 server
      [I-D.ietf-dhc-dhcpv4-over-ipv6]

   To meet these requirements, when the CPE (functioning as a DHCPv6
   server) receives an IA_NA or IA_TA request from a homenet host, a
   mechanism is required so that the correct prefix for requested
   service class can be selected for allocation.  Likewise for DHCPv6
   clients located in the homenet, a mechanism is necessary so that the
   intended service class for a requested prefix can be signalled to the
   DHCPv6 server.

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 property and prefix class options in
   IA_PD and IA_NA.  This section defines the behavior of the delegating
   router, the requesting router and the DHCPv6 client.  It discusses
   these options in the context of a DHCPv6 information request from a
   DHCPv6 client to a DHCPv6 server.

2.1.  Prefix Property and Class Options

   The format of the DHCPv6 prefix property and prefix class options are
   shown below.
















Bhandari, et al.        Expires January 16, 2014                [Page 5]

Internet-Draft          DHCPv6 class based prefix              July 2013


      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_PROPERTY   |         option-length(2)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Properties        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code:       OPTION_PREFIX_PROPERTY (TBD1)
      option-length:     2
      Properties:        16 bits  maintained as
                         OPTION_PREFIX_PROPERTY in
                         IANA registered namespace.
                         Each value in the registry represents a property.
                         Multiple properties can be represented by bitwise
                         ORing of the individual property values in this
                         field.



                          Prefix Property Option

   The individual property are maintained in OPTION_PREFIX_PROPERTY
   values enumeration explained in Section Section 6.1.

   Along with the OPTION_PREFIX_PROPERTY a meta data associated with the
   prefix that is of local relevance is communicated using
   OPTION_PREFIX_CLASS defined 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           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code:          OPTION_PREFIX_CLASS (TBD2)
      option-length:        2
      Prefix Class:         16 bit integer with the integer value
                            of local significance.


                            Prefix Class Option

2.2.  Consideration for different DHCPv6 entities





Bhandari, et al.        Expires January 16, 2014                [Page 6]

Internet-Draft          DHCPv6 class based prefix              July 2013


   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_PREFIX_CLASS option
   received in IA_NA request or any of the other method as described in
   Section 2.3.1.

2.2.1.  Requesting Router Behavior for IA_PD allocation

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

   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.  The class of prefix it
      requests is learnt via configuration or any other out of band
      mechanism not defined in this document.

   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.








Bhandari, et al.        Expires January 16, 2014                [Page 7]

Internet-Draft          DHCPv6 class based prefix              July 2013


   The requesting router parses the OPTION_PREFIX_CLASS option in the
   OPTION_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.

   The requesting router parses and stores OPTION_PREFIX_PROPERTY if
   received with the prefix.

2.2.2.  Delegating Router Behavior for IA_PD allocation

   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 classes.
   Along with including the IA_PD prefix options in the IA_PD option, it
   MAY include the OPTION_PREFIX_CLASS option in the OPTION_IAPREFIX
   option area of the corresponding IA_PD prefix option with the class
   information of the prefix.

   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
   router MUST in this case also fall back to the behavior specified in
   [RFC3633].









Bhandari, et al.        Expires January 16, 2014                [Page 8]

Internet-Draft          DHCPv6 class based prefix              July 2013


   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.

   In addition if the delegating router has additional property
   associated with the prefix it will be provided in
   OPTION_PREFIX_PROPERTY option.

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 class indicated in that option.  The class information to
      be requested can be learnt via configuration or any other out of
      band mechanism not described in this document.

   If DHCPv6 client receives OPTION_PREFIX_CLASS, OPTION_PREFIX_PROPERTY
   options in the IAaddr-options area of the corresponding IA_NA but
   does not support one or both of these options, it SHOULD ignore the
   received option(s).

2.2.4.  DHCPv6 Server Behavior for IA_NA allocation

   The DHCPv6 server parses OPTION_PREFIX_CLASS option received and when
   it supports allocation within the requested OPTION_PREFIX_CLASS
   responds with an ADVERTISE message after populating the IA_NA option
   with address information from the requested prefix class.  Along with
   including the IA Address options in the IA_NA option, it also
   includes the OPTION_PREFIX_CLASS option in the corresponding IAaddr-
   options area.

   Even though the IA_NA option in the SOLICIT message does not include
   the OPTION_PREFIX_CLASS option, based on local policies, the DHCP
   server MAY select a default OPTION_PREFIX_CLASS value for the client
   and then SHOULD include the OPTION_PREFIX_CLASS option in the IAaddr-
   options area of the corresponding IA_NA it sends to the client.  If
   both DHCP client and server support class based address allocation,
   but the DHCP server cannot offer addresses in the specified Usage
   class then the DHCP server MUST include the status code NoAddrsAvail
   (as defined in [RFC3315]) in the response message.  If the DHCP
   server cannot offer addresses for any other reason, it MUST respond
   to client with appropriate status code as specified in [RFC3315].  In



Bhandari, et al.        Expires January 16, 2014                [Page 9]

Internet-Draft          DHCPv6 class based prefix              July 2013


   addition if the server has additional property associated with the
   prefix by means of configuration or learnt from DHCPv6 prefix
   delegation or derived via any other means it MUST be sent as
   OPTION_PREFIX_PROPERTY option.

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.  Prefix property and
   class can be used for source address selection by applications using
   the prefix for communication.

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" (1), "guest"(2), "voice" (3) 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 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"(1), "guest"(2), "voice"(3) 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





Bhandari, et al.        Expires January 16, 2014               [Page 10]

Internet-Draft          DHCPv6 class based prefix              July 2013


   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, it is specified in
   [I-D.korhonen-6man-prefix-properties].

2.3.4.  Class based prefix and applications

   Applications within a host can do source address selection based on
   the class of the prefix learnt in OPTION_PREFIX_PROPERTY and
   OPTION_PREFIX_CLASS using rules defined in [RFC6724].  The internal
   data structure and interface for source address selection used by
   application to choose source prefix with specific property and class
   in a host is beyond the scope of this document.

3.  Example Application

3.1.  Mobile gateway example

   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.

   Access Router (AR) An IP router residing in an access network and
   connected to one or more Access 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 January 16, 2014               [Page 11]

Internet-Draft          DHCPv6 class based prefix              July 2013


          _----_           _----_           _----_
        _(      )_       _(      )_       _(      )_
       (Operator-1)     (Operator-2)     (Operator-3)
        (_      _)       (_      _)       (_      _)
           -+--             -+--            '-+--'
       +--------+       +--------+       +--------+
       | Mobile |       | Mobile |       | Mobile |
       |gateway |       |gateway |       |gateway |
       +--------+       +--------+       +--------+
            |                |                |
            +-------------.  |  .-------------+
                          |  |  |
                          |  |  |
                          |  |  |P1:"global-anchor"(1)
                          |  |  |
                        +--------+                        _----_
     +---+              |        |P2:"local-breakout"(2)_(      )_
     |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: Example mobile network









Bhandari, et al.        Expires January 16, 2014               [Page 12]

Internet-Draft          DHCPv6 class based prefix              July 2013


3.1.1.  Class based prefix delegation

   The Access Aggregation Gateway requests for Prefix delegation from
   Mobile gateway and associates the prefix received with class "global-
   anchor"(1).  The Access Aggregation Gateway is preconfigured to
   provide prefixes from the following classes: "global-anchor" (1),
   "local-breakout"(2), "guest"(3).  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"(1)

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

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

   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.1.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"(1).  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"(3) 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
   requesting IA_NA from MNs through WLC and it has a preconfigured



Bhandari, et al.        Expires January 16, 2014               [Page 13]

Internet-Draft          DHCPv6 class based prefix              July 2013


   profile to provide both local-breakout Internet access and global-
   anchor, it offers an IPv6 address from the class "local-breakout" (2)
   and "global-anchor"(1).  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 attached to the prefix based on source address selection
   policy.

   The prefixes that are globally anchored and hence have mobility can
   be advertised with OPTION_PREFIX_PROPERTY set to 0x0002 to convey
   that the prefix provides network based mobility as listed in
   Section 6.1.  If the prefix also provides security guarantees
   OPTION_PREFIX_PROPERTY can be set to 0x000A to indicate mobility and
   security guarantees by bitwise ORing of both the properties.

3.2.  Homenet Example

   The following sub-section describes an example of class based prefix
   delegation in a home network environment.  The network consists of
   the following elements:

   o  Home Gateway (HGW) device: a routing device located in the
      customer's premises that provides connectivity between the
      customer and the service provider.  In this example, the HGW is
      functioning as both a DHCP client towards the service provider's
      DHCP infrastructure and a DHCP server towards hosts located in the
      home network.

   o  IPv6 Set Top Box (STB): A dedicated, IPv6 attached, video on
      demand device.

   o  IPv6 PC: An IPv6 attached personal computer

   o  Delegating Router: The router in the ISPs network acting as a DHCP
      server for the IA_PD request.

   o  ISP Video On Demand (ISP-VOD) service: An ISP provided service
      offering unicast based streaming video content to subscribers.

   o  Video On Demand (VOD) service: A server providing unicast based
      streaming video content to subscribers

   o  On demand Video Application: Application hosted on the IPv6 PC

   o  Application Central: Application server hosted in the Internet
      that the On demand Video Application communicates with to access
      VOD service



Bhandari, et al.        Expires January 16, 2014               [Page 14]

Internet-Draft          DHCPv6 class based prefix              July 2013


    +-----------+    _----+----_      +----------+
    |Application|  _(           )_    | Video on |
    |central    |-(   Internet    )---|  Demand  |
    |           |  (_           _)    |  Service |
    +-----------+    '----+----'      +----------+
                          |
                     _----+----_     +----------+       \
                   _(           )_   |ISP Video |        \
                 (Service Provider)--| on Demand|         \
                   (_  Network  _)   | Service  |         |  ISP
                     '----+----'     +----------+         |  Network
                          |                               |
                   +------+-----+                         |
                   | Delegating |                         |
                   |   Router   |                         |
                   +------+-----+                         |
                          |                               |
                          | Customer                      |
                          | Internet connection           /
                          |                              /
                          |                             /
                   +------+--------+  ^                 \
                   |     IPv6      |  | DHCPv6 Client    \
                   | Home gateway  |                      \
                   |  Device (CPE) |  | DHCPv6 Server     |
                   +------+--------+  v                   |  Home
                          |                               |  Network
             Home Network |                               |
                    +-----+-------+                       |
                    |             |                       |
               +----+-----+ +-----+----+                  |
               |IPv6 Host | |IPv6 Host |                  |
               | (Set top | |   (PC)   |  DHCPv6 Clients  /
               |    box)  | |          |                 /
               +----------+ +----------+                /


              Simple home network with Data and Video devices

3.2.1.  Class based prefix delegation to the HGW

   In this example, three different services are being run on the same
   network.  The service provider wishes that traffic is sourced from
   different prefixes by the home network clients
   [I-D.jiang-v6ops-semantic-prefix].  The HGW (requesting router) has
   been configured to request prefix delegation from the ISPs delegating
   router with the usage classes "video" (1) and "internet"(2) and
   "video-app" (3) the meaning of these being of relevance to the ISP



Bhandari, et al.        Expires January 16, 2014               [Page 15]

Internet-Draft          DHCPv6 class based prefix              July 2013


   operating this and application that are configured out of band to
   utilize it.

   The delegating router is preconfigured to advertise prefixes with
   these service classes.  The HGW sends three IA_PD options within the
   SOLICIT message, one with OPTION_PREFIX_CLASS "video" (1), the second
   with "internet" (2) and a third with "video-app" (3).  The HGW
   receives an advertise with the following prefixes in the IA_PD
   option:

   1.  P1: IA_PD Prefix option with a prefix 3001:5::/56 containing
   OPTION_PREFIX_CLASS set to "video" (1) with OPTION_PREFIX_PROPERTY
   set to 0x0001 indicating there is no internet reach

   2.  P2: IP_PD Prefix option with a prefix 3001:6::/56 containing
   OPTION_PREFIX_CLASS set to "internet" (2)

   3.  P3: IP_PD Prefix option with a prefix 3001:7::/56 containing
   OPTION_PREFIX_CLASS set to "video-app" (3) with property set to
   0x0040 indicating the prefix provides Internet service SLA

   It sends a REQUEST message with all of the above prefixes and
   receives a REPLY message with prefixes allocated for each of the
   requested classes.  The HGW then configures a /64 prefix from each of
   the delegated prefixes on its LAN interface [RFC6204] and sends out
   router advertisements (RAs) with the "M" and "O" bits set.

3.2.2.  IPv6 Assignment to Homenet hosts using stateful DHCPv6

   1.  STB sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS
       option set to "video" (1) within the IA_NA.  The HGW checks the
       requested prefix class against the available prefixes it has been
       delegated and advertises 3001:5::1 to the STB.  The STB then
       configures this address on its LAN interface and uses it for
       sourcing requests to the VOD service.

   2.  The PC sends a DHCPv6 SOLICIT message requesting for IA_NA with
       the OPTION_PREFIX_CLASS option in ORO indicating support for
       prefix class.  The HGW checks the available prefixes it has been
       delegated and advertises IA_NA from P1 (3001:5:2 with property
       set to 0x0001) , P2 (3001;6::1) and P3 (3001:7::1) to the PC or
       in absence of OPTION_PREFIX_CLASS in the solicit HGW is
       preconfigured to assign from the "internet"(2) class as the
       default.  The PC then configures these addresses on its LAN
       interface and uses it for sourcing requests to the Internet.

   3.  The On demand Video Application on the PC communicates with its
       well known Application Central using the "internet" prefix and is



Bhandari, et al.        Expires January 16, 2014               [Page 16]

Internet-Draft          DHCPv6 class based prefix              July 2013


       directed to use "video-app" prefix if available based on
       agreement between service provider and on demand video
       application service provider.  The On demand Video Application
       then connects using the address assigned from P3 that will offer
       better experience based on the SLA between the providers.

   4.  If the homenet hosts use SLAAC prefix delegation with the class
       will use the options and procedure defined in
       [I-D.korhonen-6man-prefix-properties]

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, Maciek
   Konstantynowicz

5.  Contributors

   Authors would like to thank contributions to use cases and text for
   various sections received from Sindhura Bandi.

6.  IANA Considerations

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

6.1.  OPTION_PREFIX_PROPERTY values

   IANA is requested to reserve and maintain registry of
   OPTION_PREFIX_PROPERTY values and manage allocation of values as per
   as per policy defined in [RFC5226] with IETF assigned values
   requiring IETF consensus, RFC Required policy, any other values other
   than the ones listed below are not valid.

   1.   0x0001 The prefix cannot be used to reach the Internet

   2.   0x0002 The prefix provides network based mobility

   3.   0x0004 The prefix requires authentication

   4.   0x0008 The prefix is assigned on an interface that provides
        security guarantees

   5.   0x0010 Usage is charged




Bhandari, et al.        Expires January 16, 2014               [Page 17]

Internet-Draft          DHCPv6 class based prefix              July 2013


   6.   0x0020 The prefix provides multi-homed redundancy

   7.   0x0040 The prefix provides Internet service SLA, based on
        associated OPTION_PREFIX_CLASS

   8.   0x0080 Unassigned

   9.   0x0100 Unassigned

   10.  0x0200 Unassigned

   11.  0x0400 Unassigned

   12.  0x0800 Unassigned

   13.  0x1000 Unassigned

   14.  0x2000 Unassigned

   15.  0x4000 Unassigned

   16.  0x8000 Unassigned

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

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

   Changes from -01 to -02

   a.  Modified option format to be enumerated values

   b.  Added IANA section to request managing of registry for the
       enumerated values

   c.  Added initial values for the class





Bhandari, et al.        Expires January 16, 2014               [Page 18]

Internet-Draft          DHCPv6 class based prefix              July 2013


   d.  Added section for applications to select address with a specific
       property

   Changes from -02 to -03

   a.  Added server behaviour for IA_NA and IA_PD allocation

   b.  Added Class based Information-Request usage

   Changes from -03 to -04

   a.  Added homenet use case

   b.  Split usage class into a fixed IANA maintained properties
       registry and a prefix class

   Changes from -04 to -05

   a.  Added on demand video application use case and modified the
       example section

   b.  Added additional properties and reference for SLAAC/ND procedure

9.  References

9.1.  Normative References

   [I-D.ietf-dhc-dhcpv4-over-ipv6]
              Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
              Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in
              progress), March 2013.

   [I-D.jiang-v6ops-semantic-prefix]
              Jiang, S., Sun, Q., Farrer, I., and Y. Bo, "A Framework
              for Semantic IPv6 Prefix", draft-jiang-v6ops-semantic-
              prefix-03 (work in progress), May 2013.

   [I-D.korhonen-6man-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
              Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix-
              properties-02 (work in progress), July 2013.

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

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




Bhandari, et al.        Expires January 16, 2014               [Page 19]

Internet-Draft          DHCPv6 class based prefix              July 2013


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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", RFC 6204, April 2011.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

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

   Email: shwethab@cisco.com



Bhandari, et al.        Expires January 16, 2014               [Page 20]

Internet-Draft          DHCPv6 class based prefix              July 2013


   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


   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


   Laurent Thiebaut
   Alcatel-Lucent
   France

   Email: laurent.thiebaut@alcatel-lucent.com


   Jouni Korhonen
   Renesas Mobile
   Linnoitustie 6
   FIN-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com









Bhandari, et al.        Expires January 16, 2014               [Page 21]

Internet-Draft          DHCPv6 class based prefix              July 2013


   Ian Farrer
   Deutsche Telekom AG
   GTN-FM4, Landgrabenweg 151
   Bonn 53227
   Bonn 53227

   Email: ian.farrer@telekom.de












































Bhandari, et al.        Expires January 16, 2014               [Page 22]