DHC L. Yeh, Ed.
Internet-Draft T. Tsou
Intended status: Standards Track Huawei Technologies
Expires: April 28, 2011 J. Hu
Q. Sun
China Telecom
October 25, 2010
Prefix Pool Option for DHCPv6 Relay Agent
draft-yeh-dhc-dhcpv6-prefix-pool-opt-01
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
before.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Yeh, et al. Expires April 28, 2011 [Page 1]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Language . . . . . . . . . . . . . . . . . . . 4
3. Scenario and Network architecture . . . . . . . . . . . . . . . 4
4. Prefix Pool option . . . . . . . . . . . . . . . . . . . . . . 5
5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Yeh, et al. Expires April 28, 2011 [Page 2]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
1. Introduction
DHCPv6 Relay Agents [RFC3315] are deployed to relay messages between
clients and servers when they are not on the same link, and are often
implemented along with a routing function on the provider edge (PE)
routers [BBF WT-177]. Meanwhile, the PE router always employ the
DHCPv6 Prefix Delegation [RFC3633] as the mechanism for the automated
delegation of IPv6 prefix to the customer network.
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) when the PE
router acts as DHCPv6 Relay Agent [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 supposed to advertise 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 to the customer networks, which are associated
to the same client-facing link of the PE. On the other hand, the
information of the prefix pools associated to each client-facing
interface of PEs is always maintained on the DHCPv6 server.
When the PE router acts as the DHCPv6 Server, the aggregation routes
(eg. black-hole routes) can be generated by the information of the
prefix pools directly, but when the PE router acts as the DHCPv6
Relay Agent, a new mechanism to transfer the information of the
prefix pools from the server to the relay agent for each client-
facing interface of the PE is requested.
After the PE got the information of the prefix pools associated to
its client-facing interfaces, the aggregation route entries pointing
to each of the prefix pools can be added or withdrawed in the routing
table of PE. When the routing protocol is enabled on PE's network-
facing interface, the above aggregation route pointing to all of the
customer networks attached on the same link of the PE's client-facing
interface will be advertised to the whole ISP network.
Yeh, et al. Expires April 28, 2011 [Page 3]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
2. Terminology and Language
This document describes new DHCPv6 options of prefix pool and the
associated mechanism for the configuration on the Relay Agent. This
document should be read in conjunction with the DHCPv6 specification,
RFC 3315 and RFC 3633, for a complete mechanism. Definitions for
terms and acronyms not specifically defined in this document are
defined in RFC 3315, RFC 3633 and RFC 3769 [RFC3769].
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 figure illustrates a typical ISP-Customer network
architecture.
Yeh, et al. Expires April 28, 2011 [Page 4]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
+------+------+
| DHCPv6 | DHCPv6-PD Delegating Router
| Server | (eg. binding entry:
+------+------+ pe#1_cfi#2 < - > 3ffe:ffff:0::/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 1: An example of ISP-Customer network architecture
4. Prefix Pool option
The format of the Prefix Pool option is:
Yeh, et al. Expires April 28, 2011 [Page 5]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
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
5. Relay Agent Behavior
The Relay Agent who needs the information of prefix pools from the
server, shall 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 particular client-facing
interface of the Relay Agent where receiving the message from
clients. The Relay Agent may include the 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 should includes Interface ID option
(OPTION_INTERFACE_ID, 18) for the server to identify the associated
interface on which the prefix pool is configured, 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 clients are located.
Yeh, et al. Expires April 28, 2011 [Page 6]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
After received the Prefix Pool option for that particular client-
facing interface in the relay-reply message (13) message 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 he
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.
6. Server Behavior
Per RFC3633, if the prefix of the customer network associated to the
IA_PD option in relay-forward message of SOLICIT , REQUEST, RENEW,
REBIND is indicated to be valid on the Server, the Server (delegating
router) will delegate the prefix of the customer network with the
relevant parameters to the client (requesting router, customer
router) in the relay-reply message of REPLY.
The Server shall use the Interface ID included in the relay-forward
message by the relay agent to identify the client-facing interface of
the relay agent on which the associated prefix pool will be
configured. Per RFC3315, the Server may include the same Interface
ID option in the relay-reply message.
After receives the ORO in the relay-forward message, the Server must
include Prefix Pool option with the status indicated for the
associated client-facing interface of the relay agent in the relay-
reply message of REPLY.
The status of 'Valid' in the Prefix Pool option can be used to set up
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 configuration of the prefix pool and the
associated aggregation route on the relay agent.
On the other hand, if the prefix of the customer network associated
to the IA_PD option in the relay-forward message of RELEASE is the
last releasing prefix within the associated prefix pool, the Server
(delegating router) shall turn the status of the associated prefix
pool to be 'Released'. After receives the ORO in the relay-forward
message, the Server must include Prefix Pool option with the status
of 'Released' for the associated client-facing interface of the relay
Yeh, et al. Expires April 28, 2011 [Page 7]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
agent in the relay-reply message of REPLY.
Note that multiple prefix pools may associate with the same client-
facing interface of the PE router implementing Relay Agent in the
binding table on the Server, and the status of the prefix pools
associated to each of client-facing interface of the PE router
implementing Relay Agent in the binding table can be reset by the
administrator of the Server.
When the status of prefix pool is reset by manual configuration, the
Server shall initiate the relay-reply message of RECONFIGURE (10), if
there is at least one prefix indicated to be valid within the
associated prefix pool on the Server.
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 (http://www.iana.org/
assignments/dhcpv6-parameters/dhcpv6-parameters.xml).
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 April 28, 2011 [Page 8]
Internet-Draft DHCPv6 Prefix Pool Option October 2010
9.2. Informative References
[BBF WT-177]
Broadband Forum, "IPv6 in the context of TR-101, Rev.16,
Straw Ballot", September 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 April 28, 2011 [Page 9]