Internet DRAFT - draft-ietf-dhc-pd-exclude

draft-ietf-dhc-pd-exclude






Dynamic Host Configuration (DHC)                        J. Korhonen, Ed.
Internet-Draft                                    Nokia Siemens Networks
Updates: 3633 (if approved)                                T. Savolainen
Intended status: Standards Track                                   Nokia
Expires: June 22, 2012                                       S. Krishnan
                                                                Ericsson
                                                                O. Troan
                                                      Cisco Systems, Inc
                                                       December 20, 2011


        Prefix Exclude Option for DHCPv6-based Prefix Delegation
                    draft-ietf-dhc-pd-exclude-04.txt

Abstract

   This specification defines an optional mechanism to allow exclusion
   of one specific prefix from a delegated prefix set when using DHCPv6-
   based prefix delegation.  The new mechanism updates RFC 3633.

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 June 22, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Korhonen, et al.          Expires June 22, 2012                 [Page 1]

Internet-Draft              PD Exclude Option              December 2011


   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.  Requirements and Terminology  . . . . . . . . . . . . . . . . . 3
   3.  Problem Background  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Prefix Delegation with Excluded Prefixes  . . . . . . . . . 4
     4.2.  Prefix Exclude Option . . . . . . . . . . . . . . . . . . . 4
   5.  Delegating Router Solicitation  . . . . . . . . . . . . . . . . 6
     5.1.  Requesting Router . . . . . . . . . . . . . . . . . . . . . 6
     5.2.  Delegating Router . . . . . . . . . . . . . . . . . . . . . 7
   6.  Requesting Router Initiated Prefix Delegation . . . . . . . . . 7
     6.1.  Requesting Router . . . . . . . . . . . . . . . . . . . . . 7
     6.2.  Delegating Router . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 9
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

























Korhonen, et al.          Expires June 22, 2012                 [Page 2]

Internet-Draft              PD Exclude Option              December 2011


1.  Introduction

   This specification defines an optional mechanism and the related
   DHCPv6 option to allow exclusion of one specific prefix from a
   delegated prefix set when using DHCPv6-based prefix delegation.

   The prefix exclusion mechanism is targeted to deployments where
   DHCPv6-based prefix delegation is used but a single aggregated route/
   prefix has to represent one customer, instead of using one prefix for
   the link between the delegating router and the requesting router and
   another prefix for the customer network.  The mechanism defined in
   this specification allows a delegating router to use a prefix out of
   the delegated prefix set on the link through which it exchanges
   DHCPv6 messages with the requesting router, and is intended for use
   in networks where each requesting router is on its own layer 2
   domain.


2.  Requirements and 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 [RFC2119].


3.  Problem Background

   DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
   limitation described in Section 12.1 of [RFC3633] that a prefix
   delegated to a requesting router cannot be used by the delegating
   router.  This restriction implies that the delegating router will
   have two (non aggregatable) routes towards a customer, one for the
   link between the requesting router and the delegating router, and one
   for the customer site behind the requesting router.

   There are architectures and link models, where a host (e.g. a mobile
   router, also acting as a requesting router) always has a single (/64)
   prefix configured on its uplink interface and the delegating router
   is also requesting router's first hop router.  Furthermore, it may be
   required that the prefix configured on the uplink interface has to be
   aggregatable with the delegated prefixes.  This introduces a problem
   in how to use DHCPv6-PD together with stateless [RFC4862] or stateful
   [RFC3315] address autoconfiguration on a link, where the /64
   advertised on the link is also part of the prefix delegated (e.g /56)
   to the requesting router.






Korhonen, et al.          Expires June 22, 2012                 [Page 3]

Internet-Draft              PD Exclude Option              December 2011


4.  Solution

4.1.  Prefix Delegation with Excluded Prefixes

   This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
   (TBD1), that is used to exclude exactly one prefix from a delegated
   prefix.  The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
   IAprefix-options field.  There can be at most one OPTION_PD_EXCLUDE
   option in one OPTION_IAPREFIX option.  The OPTION_PD_EXCLUDE option
   allows prefix delegation where a requesting router is delegated a
   prefix (e.g. /56) and the delegating router uses one prefix (e.g.
   /64) on the link through which it exchanges DHCPv6 messages with the
   requesting router with a prefix out of the same delegated prefix set.

   A requesting router includes an OPTION_ORO option with the
   OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind
   message to inform the delegating router about the support for the
   prefix delegation functionality defined in this specification.  A
   delegating router may include the OPTION_PD_EXCLUDE option code in an
   OPTION_ORO option in a Reconfigure message for indicating that the
   requesting router should request OPTION_PD_EXCLUDE from the
   delegating router.

   The delegating router includes the prefix in the OPTION_PD_EXCLUDE
   option that is excluded from the delegated prefix set.  The
   requesting router MUST NOT assign the excluded prefix to any of its
   downstream interfaces.

4.2.  Prefix Exclude Option


    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_PD_EXCLUDE       |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  prefix-len   | IPv6 subnet ID (1 to 16 octets)               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Prefix Exclude Option

   o  option-code: OPTION_PD_EXCLUDE (TBD1).

   o  option-len: 1 + length of IPv6 subnet ID in octets.  A valid
      option-len is between 2 and 17.

   o  prefix-len: The length of the excluded prefix in bits.  The
      prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and



Korhonen, et al.          Expires June 22, 2012                 [Page 4]

Internet-Draft              PD Exclude Option              December 2011


      128.

   o  IPv6 subnet ID: A variable length IPv6 subnet ID up to 128 bits.

   The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix-
   length' bits extracted from the excluded prefix starting from the bit
   position 'OPTION_IAPREFIX prefix-length'.  The extracted subnet ID
   MUST be left shifted to start from a full octet boundary, i.e. left
   shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits.  The subnet ID
   MUST be zero padded to the next full octet boundary.

   The encoding of the IPv6 subnet ID can be expressed in a C-like
   pseudo code as shown below:

     uint128_t p1;           // the delegated IPv6 prefix
     uint128_t p2;           // the excluded IPv6 prefix
     uint16_t a;             // the OPTION_IAPREFIX prefix-length
     uint8_t b;              // the excluded IPv6 prefix length
     uint8_t s;

     // sanity checks

     s = 128-a;              // size of non-prefix bits
     assert(b>a);            // b must be at least a+1
     assert(p1>>s == p2>>s); // p1 and p2 must share a common
                             // prefix of 'a' bits

     // calculate the option content

     uint16_t c = b-a-1;     // the IPv6_subnet_ID_length-1 in bits
     uint16_t d = (c/8)+1;   // the IPv6_subnet_ID_length in octets
     uint128_t p = p2<<a;    // p is the IPv6 subnet ID that has the
                             // common p1 prefix left shifted out to
                             // a full octet boundary (trailing bits
                             // are zeroed)

     // populate the option

     uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID;
     OPTION_PD_EXCLUDE.option_len = d+1;
     OPTION_PD_EXCLUDE.prefix_len = b;

     while (d-- > 0) {
       *id++ = p>>120;
       p <<= 8;
     }

   The OPTION_PD_EXCLUDE option MUST only be included in the



Korhonen, et al.          Expires June 22, 2012                 [Page 5]

Internet-Draft              PD Exclude Option              December 2011


   OPTION_IAPREFIX IAprefix-options [RFC3633] field.

   Any prefix excluded from the delegated prefix MUST be contained in
   OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.

   The prefix included in the OPTION_PD_EXCLUDE option share the same
   preferred-lifetime and valid-lifetime as the delegated prefix in the
   encapsulating OPTION_IAPREFIX option.

   The prefix in the OPTION_PD_EXCLUDE option MUST be part of the
   delegated prefix in the OPTION_IAPREFIX.  For example, the requesting
   router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by
   the delegating router, and the delegated prefix in the
   OPTION_IAPREFIX is 2001:db8:dead:bee0::/59.  In this case, 2001:db8:
   dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE
   option.  The OPTION_PD_EXCLUDE option would be encoded as follows:

    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_PD_EXCLUDE       |               2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       64      |0|1|1|1|1|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ^         ^
                   |         |
                   |         +- 3 zero padded bits follow
                   |
                   +- using C syntax: 0xef << (59 % 8)
                      Note: 59 mod 8 = 3


5.  Delegating Router Solicitation

   The requesting router locates and selects a delegating router in the
   same way as described in Section 11 [RFC3633].  This specification
   only describes the additional steps required by the use of
   OPTION_PD_EXCLUDE option.

5.1.  Requesting Router

   If the requesting router implements the solution described in
   Section 4.1 then the requesting router SHOULD include the
   OPTION_PD_EXCLUDE option code in the OPTION_ORO option in Solicit
   messages.

   Once receiving Advertise message, the requesting router uses the
   prefix(es) received in OPTION_PD_EXCLUDE in addition to the



Korhonen, et al.          Expires June 22, 2012                 [Page 6]

Internet-Draft              PD Exclude Option              December 2011


   advertised prefixes to choose the delegating router.  Requesting
   router MUST proceed to Prefix Delegation procedure described in
   Section 6.1.  If Advertise message did not include OPTION_PD_EXCLUDE
   option, then the requesting router MUST fall back to normal [RFC3633]
   Section 11.1 behavior.

5.2.  Delegating Router

   If the OPTION_ORO option in the Solicit message includes the
   OPTION_PD_EXCLUDE option code, then the delegating router knows that
   the requesting router supports the solution defined in this
   specification.  If the Solicit message also contains an IA_PD option,
   the delegating router can delegate to the requesting router a prefix
   which includes the prefix already assigned to the requesting router's
   uplink interface.  The delegating router includes the prefix
   originally or to be assigned to the requesting router in the
   OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option
   in the Advertise message.

   If the OPTION_ORO option in the Solicit message does not include the
   OPTION_PD_EXCLUDE option code, then the delegating router MUST fall
   back to normal [RFC3633] Section 11.2 behavior.

   If the OPTION_ORO option in the Solicit message includes the
   OPTION_PD_EXCLUDE 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 normal [RFC3633] behavior.


6.  Requesting Router Initiated Prefix Delegation

   The procedures described in the following sections are aligned with
   Section 12 of [RFC3633].  In this specification we only describe the
   additional steps required by the use of OPTION_PD_EXCLUDE option.

6.1.  Requesting Router

   The requesting router behavior regarding the use of the
   OPTION_PD_EXCLUDE option is more or less identical to step described
   in Section 5.1.  The only difference really is different used DHCPv6
   messages.  The requesting router SHOULD include the OPTION_PD_EXCLUDE
   option code in the OPTION_ORO option in DHCPv6 messages as described
   in Section 22.7 of [RFC3315].

   The requesting router uses a Release message to return the delegated
   prefix(es) to a delegating router.  The prefix(es) to be released
   MUST be included in the IA_PDs along with the excluded prefix



Korhonen, et al.          Expires June 22, 2012                 [Page 7]

Internet-Draft              PD Exclude Option              December 2011


   included in the OPTION_PD_EXCLUDE option.  The requesting router MUST
   NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded
   prefix in the Release message that it originally got a valid binding
   for.

   The requesting router must create sink routes for the delegated
   prefixes minus the excluded prefixes.  This may be done by creating
   sink routes for delegated prefixes and more specific routes for the
   excluded prefixes.

6.2.  Delegating Router

   The delegating router behavior regarding the use of the
   OPTION_PD_EXCLUDE option is more or less identical to step described
   in Section 5.2.  The only difference really is DHCPv6 messages used
   to carry the OPTION_PD_EXCLUDE option.

   The delegating router may mark any prefix(es) in IA_PD Prefix options
   in a Release message from a requesting router as 'available'
   excluding the prefix included in the OPTION_PD_EXCLUDE options.  If
   the Release message contains 'new' excluded prefix in any
   OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply
   message with Status Code set to NoBinding for that IA_PD option.


7.  Security Considerations

   Security considerations in DHCPv6 are described in Section 23 of
   [RFC3315], and for DHCPv6 Prefix Delegation in Section 12 of
   [RFC3633].


8.  IANA Considerations

   A new DHCPv6 Option Code is reserved from DHCPv6 registry for DHCP
   Option Codes.

       OPTION_PD_EXCLUDE   is set to TBD1


9.  Acknowledgements

   Authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon,
   Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael Abrahamsson,
   Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob, Hemant Singh,
   Gaurav Halwasia, Lorenzo Colitti and Tomasz Mrugalski for their
   valuable comments and discussions.




Korhonen, et al.          Expires June 22, 2012                 [Page 8]

Internet-Draft              PD Exclude Option              December 2011


10.  References

10.1.  Normative References

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

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

10.2.  Informative References

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


Authors' Addresses

   Jouni Korhonen (editor)
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com


   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   FI-33720 Tampere
   Finland

   Email: teemu.savolainen@nokia.com












Korhonen, et al.          Expires June 22, 2012                 [Page 9]

Internet-Draft              PD Exclude Option              December 2011


   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Email: suresh.krishnan@ericsson.com


   Ole Troan
   Cisco Systems, Inc
   Oslo
   Norway

   Email: ot@cisco.com




































Korhonen, et al.          Expires June 22, 2012                [Page 10]