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

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-dhc-dhcpv6-prefix-pool-opt

DHC                                                          L. Yeh, Ed.
Internet-Draft                                                   T. Tsou
Intended status: Standards Track                     Huawei Technologies
Expires: August 13, 2011                                           J. Hu
                                                                  Q. Sun
                                                           China Telecom
                                                        February 9, 2011


               Prefix Pool Option for DHCPv6 Relay Agent
                draft-yeh-dhc-dhcpv6-prefix-pool-opt-02

Abstract

   The Prefix Pool option provides an automatic mechanism for the
   messages exchange between DHCPv6 server and DHCPv6 relay agent.  The
   information about prefix pools maintained on DHCPv6 server can be
   transferred from server to relay agent through this DHCPv6 option to
   support the necessary route aggregation on the provide edge router,
   which has a huge number of routes pointing to the customer networks.

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 August 13, 2011.

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



Yeh, et al.              Expires August 13, 2011                [Page 1]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Language . . . . . . . . . . . . . . . . . . .  4
   3.  Scenario and Network architecture  . . . . . . . . . . . . . .  4
   4.  Prefix Pool option . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . .  7
   6.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. Changes Log  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12





























Yeh, et al.              Expires August 13, 2011                [Page 2]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


1.  Introduction

   The DHCPv6 [RFC3315] protocol specifies a mechanism for the
   assignment of IPv6 address and configuration information to IPv6
   nodes.  IPv6 Prefix Delegation (PD) of DHCPv6 [RFC3633] specifies a
   mechanism for the delegation of IPv6 prefixes and configuration
   information to the Requesting Router (DHCPv6 Client).  The DHCPv6
   servers (Delegating Router) always maintain authoritative information
   related to their operations including, but not limited to, binding
   data of the delegated IPv6 prefixes, lease data of the delegated IPv6
   prefixes, and binding data of their prefix pools.

   The provider edge (PE) routers can act as a DHCPv6 relay agents when
   the DHCPv6 Server (Delegating Router) and the DHCPv6 Client
   (Requesting Router) are not on the same link.  In order to make the
   customer network to be reachable in the IPv6 network, the PE routers
   always need to add or remove the route entry directing to each
   customer network in its routing table per the messages between DHCPv6
   Server (Delegation Router) and Customer router (CPE, DHCPv6 Client,
   DHCPv6 Requesting Router) relayed by the PE (Section 6.2 of BBF TR-
   177) [BBF WT-177].

   When the routing protocol is enabled on the network-facing interface
   of the PE router, all the routes directing to the customer networks
   are advertised in the ISP core network.  This will make the number of
   entries in the routing table on the ISP core router to be
   unacceptable huge, so that it is necessary to aggregate the routes
   directing to the customer networks on the PE router.

   Because the prefixes of the customer networks can not guarantee
   always to be valid and continuous, the routing protocol on the PE
   router can not make one aggregation route automatically to cover all
   the prefixes delegated.  The PE router (Relay) here requires a new
   mean to transfer the information of the prefix pools from the server
   to the relay agent.  This document will address a new Prefix Pool
   option for this purpose.  After the PE got the information of prefix
   pools, the aggregation route entries (eg. black-hole routes) pointing
   to each of the prefix pools can be added or withdrawed in the routing
   table of PE.  The aggregation routes will then be advertised to the
   whole ISP network through the routing protocol enabled on the PE's
   network-facing interface.

   The DHCPv6 Bulk Leasequery [RFC5460] protocol specifies a mechanism
   for bulk transfer of the binding data of each delegated prefix from
   the server to the Requestor (DHCPv6 Relay), to support the
   replacement or reboot event of Relay.  In this document, the
   capabilty of DHCPv6 Bulk Leasequery will be extended to support the
   bulk transfer of the binding data of prefix pool for the route



Yeh, et al.              Expires August 13, 2011                [Page 3]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   aggregation.


2.  Terminology and Language

   This document describes new DHCPv6 options of prefix pool and the
   associated mechanism on the relay agent and server.  This document
   should be read in conjunction with the DHCPv6 specification, RFC3315,
   RFC3633, RFC5007 and RFC5460 for a complete mechanism.  Definitions
   for terms and acronyms not specifically defined in this document are
   defined in RFC 3315, RFC 3633, RFC 3769 [RFC3769], RFC5007 [RFC5007]
   and RFC5460.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].


3.  Scenario and Network architecture

   The following figures illustrates some typical cases of ISP-Customer
   network architectures.




























Yeh, et al.              Expires August 13, 2011                [Page 4]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


             +------+------+
             |    DHCPv6   |  DHCPv6-PD Delegating Router
             |    Server   |  (eg. binding entry:
             +------+------+       pe#1 - 3ffe:ffff:1200::/40
           _________|_________     extract pe_id=pe#1
          /                   \    from the interface_id=pe#1_cfi#2)
         |  ISP Core Network   |
          \___________________/
                    |
                    |  Network-facing interface
             +------+------+
             |             |  Provider Edge Router
             |     PE      |  DHCPv6 Relay Agent
             |             |  (eg. pe_id=pe#1;
             +------+------+       prefix pool=3ffe:ffff:1200::/40)
                    |  Client-facing interface (Interface ID)
                    |  (eg. interface_id=pe#1_cfi#2)
                    |
             +------+------+  Customer Router
             |     CPE     |  DHCPv6 Client
             |             |  DHCPv6-PD Requesting Router
             +------+------+  (eg. customer network
                    |              =3ffe:ffff:1234:5600:/56)
           _________|_________
          /                   \
         |  Customer Network   |
          \___________________/

      Figure 1: Use case of ISP-Customer network where CE is directly
                              connected to PE





















Yeh, et al.              Expires August 13, 2011                [Page 5]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


             +------+------+
             |    DHCPv6   |  DHCPv6-PD Delegating Router
             |    Server   |  (eg. binding entry:
             +------+------+       pe#1_cfi#2 - 3ffe:ffff:1200::/40)
           _________|_________
          /                   \
         |  ISP Core Network   |
          \___________________/
                    |
                    |  Network-facing interface
             +------+------+
             |      PE     |  Provider Edge Router
             |             |  DHCPv6 Relay Agent
             +------+------+
                    |  Client-facing interface (Interface ID)
                    |  (eg. interface_id=pe#1_cfi#2;
                    |       prefix pool=3ffe:ffff:1200::/40)
           _________|_________
          /                   \
         |   Access Network    |
          \___________________/
                    |
             +------+------+  Customer Router
             |     CPE     |  DHCPv6 Client
             |             |  DHCPv6-PD Requesting Router
             +------+------+  (eg. customer network
                    |              =3ffe:ffff:1234:5600::/56)
           _________|_________
          /                   \
         |  Customer Network   |
          \___________________/


    Figure 2: Use case of ISP-Customer network where CE is connected to
                         PE through access network


4.  Prefix Pool option

   The format of the Prefix Pool option is:











Yeh, et al.              Expires August 13, 2011                [Page 6]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


    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_POOL     |           option-length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  pfx-pool-len |                                               |
   +-+-+-+-+-+-+-+-+           ipv6-prefix                         +
   |                           (16 octets)                         |
   |                                                               |
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |     status    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code:    OPTION_PREFIX_POOL (TBD)
   option-length:  18
   pfx-pool-len:   Length for the prefix pool in bits
   ipv6-prefix:    IPv6 prefix of the prefix pool
   status:         Status of the prefix pool

   The status field in the Prefix Pool option indicates the availability
   of the prefix pool maintained on the server.  The code of the status
   is defined in the following table.

   Name      Code
   Valid     0
   Released  1
   Reserved  2~255

   The status of 'Valid' in the Prefix Pool option can be used to add
   the prefix pool and the associated aggregation route on the relay
   agent; while the status of 'Released' in the Prefix Pool option can
   be used to withdraw the prefix pool and the associated aggregation
   route on the relay agent.

   If the adminstrative policy on the server permit and support the
   route aggregation on the relay agent, the status of prefix pool can
   be determined by the delegated prefixes within the associated prefix
   pool.  If there is one delegated prefix within the pool that has
   valid lease, the status of prefix pool will be 'Valid'.  Otherwise,
   the status of prefix pool is 'Released'.  If the adminstrative policy
   on the server don't permit or support the route aggregation on the
   relay agent, the status of prefix pool will always be 'Released'.


5.  Relay Agent Behavior

   The relay agent who needs the information of prefix pools, must



Yeh, et al.              Expires August 13, 2011                [Page 7]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   includes Option Request option (OPTION_ORO, 6) to request Prefix Pool
   option from the server, who maintains the status of the prefix pools
   associated to the relay agent itself (Figure 1) or its particular
   client-facing interface (Figure 2) where receiving the DHCPv6-PD
   message from clients.  The relay agent can include this ORO for
   Prefix Pool option in the relay-forward (12) message of SOLICIT (1),
   REQUEST (3), RENEW(5), REBIND (6) and RELEASE (8).  The relay agent
   may also include Prefix Pool option with the field values of pfx-
   pool-len and IPv6-prefix as its preference which the relay agent
   would like the server return.

   The relay agent should include Interface ID option
   (OPTION_INTERFACE_ID, 18) for the server to identify the relay agent
   itself or its particular client-facing interface where the prefix
   pool is associated, if the server would not like to use link-address
   specified in the DHCPv6 message encapsulation of relay-forward
   message to identify the interface of the link on which the clients
   are located.

   After received the Prefix Pool option for the relay agent itself or
   its particular client-facing interface in the relay-reply message
   (13) of REPLY (7) from the server, the relay agent shall add or
   remove the aggregation route entry per the status of the prefix pool.
   If the status of the prefix pool got from the server is 'Valid', the
   relay agent shall add an aggregation route entry in its routing
   table, if the same entry has not been added in.  If the status of the
   prefix pool got from the server is 'Released', the relay agent shall
   withdraw the associated aggregation route entry in its routing table.

   The relay agent advertises its routing table including the entries of
   the aggregation routes based on the information of prefix pools when
   the routing protocol is enabled on its network-facing interface.

   The Relay Agent (Requestor) can use DHCPv6 Bulk Leasequery [RFC5460]
   protocol to query the binding data of prefix pools in the !(R)Valid'
   status from the server.  After estblished a TCP connetion with the
   DHCPv6 server, the relay agent must include Query option
   (OPTION_LQ_QUERY, 44) and set the proper query-type
   (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link-
   address and query-options in the LEASEQUERY (14) message.  The query
   options must include Option Request option (OPTION_ORO, 6) to request
   Prefix Pool option from the server.


6.  Server Behavior

   Per RFC3633, if the prefix of the customer network requested in
   relay-forward message of SOLICIT , REQUEST, RENEW, REBIND by the



Yeh, et al.              Expires August 13, 2011                [Page 8]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   Client (requesting router) has valid lease, the Server (delegating
   router) will delegate the prefix with the relevant parameters in the
   relay-reply message of REPLY.  In order to give a meaningful reply,
   the server has to be able to maintains the binding data of the
   delegated IPv6 prefixes with the identification of the client.  When
   Interface ID (OPTION_INTERFACE_ID, 18) included or nested in the
   relay-forward message is used to identify the client, it can support
   both of the typical use cases (Figure 1 and Figure 2) dicussed in
   section 3.

   After received the ORO (OPTION_ORO, 6) to request Prefix Pool option
   in the relay-forward message of PD, the server must include Prefix
   Pool option with the status indicated for the associated relay agent
   (Figure 1) or its client-facing interface (Figure 2) in the relay-
   reply message of PD if the relay-forward message of PD received is
   valid per RFC3633.

   The server may use the link-address specified in relay-forward
   message to identify the relay agent itself or its particular client-
   facing interface where the prefix pool is associated, but the server
   has to maintain the binding data of prefix pools in asscociation with
   these link-addresses.  To be more readable, the server can
   alternatively use the Interface ID (OPTION_INTERFACE_ID, 18) included
   in the relay-forward message by the relay agent, to identify the
   relay agent itself (Figure 1) or its particular client-facing
   interface (Figure 2) where the prefix pool is associated.  In order
   to give a meaningful reply, the server has to maintain the binding
   data of prefix pools in asscociation with the Interface ID.  In the
   case that the CE is directly connected to PE (Figure 1), the server
   can extract explicitly the ID of relay agent (PE) from the interface
   ID.

   Per RFC3315, the server shall copy the same Interface ID option got
   from the relay-forward message into the relay-reply message.  If the
   prefix pool is associated with the relay agent itself, the Interface
   ID option replied in the relay-reply message only include the ID of
   the relay agent; if the preix pool is associated with the particular
   client-facing interface of the relay agent, the Interface ID option
   replies the whole ID of this interface.

   If the server is set to support the route aggregation on the relay
   agent for the particular prefix pool, the status of this prefix pool
   can be determined by the delegated prefixes within the associated
   prefix pool.  If at least one of delegated prefix in the associated
   prefix pool has valid lease, the server shall turn the status of the
   prefix pool to be 'Valid'.  If the lease of each delegated prefix
   within the associated prefix pool got expired, or if the delegated
   prefix in the relay-forward message of RELEASE is the last prefix



Yeh, et al.              Expires August 13, 2011                [Page 9]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   releasing in the associated prefix pool, the server shall turn the
   status of the associated prefix pool to be 'Released'.  If the server
   is set to not support the route aggregation on the relay agent for
   the particular prefix pool, the status of prefix pool will always be
   'Released'.

   Once received the ORO to request Prefix Pool option in the relay-
   forward message, the server must include Prefix Pool option with its
   status in the relay-reply message of REPLY.

   When the administrator of the server changes the setting to support
   the route aggregation on the relay agent for the particular prefix
   pool or not, the server may initiates the relay-reply message of
   RECONFIGURE (10) including Prefix Pool option to add or withdraw the
   prefix pool and the associated aggregation route on the relay agent
   if at least one delegated prefix within the prefix pool still has the
   valid lease. .

   Note that multiple prefix pools may associate with the same PE router
   implementing relay agent (Figure 1) or its client-facing interface
   (Figure 2) in the binding table on the server, and one delegated
   prefix is only from one prefix pool.

   After received the LEASEQUERY (14) message from the relay agent with
   the Query option (OPTION_LQ_QUERY, 44) including Option Request
   option (OPTION_ORO, 6) to request Prefix Pool option, the server must
   include the Client Data options (OPTION_CLIENT_DATA, 45) in the
   LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (16) message to convey the
   binding data of the associated prefix pools with the 'Valid' status
   throught the established TCP connection per RFC5460.  Each Client
   Data option shall contain Prefix Pool option, and might contain the
   Interface ID option.  In order to be able to give the meaningful
   replies to different type of query, the server has to be able to
   maintain the relevant association of prefix pools with the RELAY_ID,
   link addresses or Remote_ID of the relay agent in its binding
   database.


7.  Security Considerations

   Security issues related DHCPv6 are described in section 23 of RFC
   3315.


8.  IANA Considerations

   IANA is requested to assign an option code to Option_Prefix_Pool from
   the "DHCPv6 and DHCPv6 options" registry



Yeh, et al.              Expires August 13, 2011               [Page 10]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-
   parameters.xml).


9.  Acknowledgements

   Thanks to the DHC working group members, Bernie Volz, Eliot Lear, Ole
   Troan, Roberta Maglione, Ted Lemon, for the disussion in the mailing
   list.  Thanks to Christian Jacquenet for pointing out the draft
   should cover one more of ISP-Customer network where CE is connected
   to PE through access network.  Thanks to Sven OOghe and Shrinivas
   Ashok Joshi for the discussion during IETF79, and pointing out the
   mechanism introduced in this draft should cover the case of reboot.


10.  Changes Log

   If this document is accepted for publication as an RFC, this change
   log is to be removed before publication.

   Rev. -02

   a.  Add one more use case of ISP network architecture where CE is
       directly connected to PE.

   b.  A bit of revisions on the usage of the 'status' field in Prefix
       Pool option.

   c.  Extend DHCPv6 Bulk Leasequery (RFC5460) for the new usage.


11.  References

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

   [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
              Delegation", RFC 3769, June 2004.



Yeh, et al.              Expires August 13, 2011               [Page 11]


Internet-Draft          DHCPv6 Prefix Pool Option          February 2011


   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              February 2009.

11.2.  Informative References

   [BBF WT-177]
              Broadband Forum, "IPv6 in the context of TR-101, Issue 1",
              November 2010.


Authors' Addresses

   Leaf Y. Yeh (editor)
   Huawei Technologies
   Area F, Huawei Park, Bantian,
   Longgang District, Shenzhen  518129
   P.R.China

   Phone: +86-755-28971871
   Email: leaf.y.yeh@huawei.com


   Tina Tsou
   Huawei Technologies

   Email: tena@huawei.com


   Jie Hu
   China Telecom
   No.118, Xi Zhi Men-Nei Da Jie,
   Xicheng District, Beijing  100035
   P.R.China

   Phone: +86-10-58552808
   Email: huj@ctbri.com.cn


   Qiong Sun
   China Telecom

   Email: sunqiong@ctbri.com.cn






Yeh, et al.              Expires August 13, 2011               [Page 12]


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