📄 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
字号:
DHC Working Group O. TroanInternet-Draft R. DromsExpires: August 11, 2003 Cisco Systems February 10, 2003 IPv6 Prefix Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txtStatus of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 11, 2003.Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.Troan & Droms Expires August 11, 2003 [Page 1] Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Model and Applicability . . . . . . . . . . . . . . . . . . 4 5. Identity Association for Prefix Delegation . . . . . . . . . 6 6. Overview of DHCP with Prefix Delegation . . . . . . . . . . 7 7. Interface Selection . . . . . . . . . . . . . . . . . . . . 7 8. Identity Association for Prefix Delegation Option . . . . . 8 9. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 9 10. Delegating Router Solicitation . . . . . . . . . . . . . . . 11 10.1 Requesting router behaviour . . . . . . . . . . . . . . . . 11 10.2 Delegating router behaviour . . . . . . . . . . . . . . . . 11 11. Requesting router initiated prefix delegation . . . . . . . 12 11.1 Requesting router behaviour . . . . . . . . . . . . . . . . 13 11.2 Delegating Router behaviour . . . . . . . . . . . . . . . . 14 12. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15 12.1 Delegating Router behaviour . . . . . . . . . . . . . . . . 15 12.2 Requesting Router behaviour . . . . . . . . . . . . . . . . 15 13. Relay agent behaviour . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . 15 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 17. Changes since revision-01 . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18Troan & Droms Expires August 11, 2003 [Page 2] Internet-Draft IPv6 Prefix Options for DHCPv6 February 20031. Introduction This document describes new options for DHCP, which provide a mechanism for the delegation of IPv6 prefixes. Through these options, a delegating router can delegate prefixes to authorised requesting routers. The prefix delegation mechanism described in this document is intended for simple delegation of prefixes from a delegating router to requesting routers. It is appropriate for situations in which the delegating router does not have knowledge about the topology of the networks to which the requesting router is attached, and the delegating router does not require other information aside from the identity of the requesting router to choose a prefix for delegation. For example, these options would be used by a service provider to assign a prefix to a CPE device acting as a router between the subscriber's internal network and the service provider's core network. Many applications expect stable addresses. Even though this mechanism makes automatic renumbering easier, it is expected that prefixes have a long lifespan. During renumbering it is expected that the old and the new prefix co-exist for some time.2. Terminology This document uses the terminology defined in RFC2460 [2] and the DHCP specification [6]. In addition, this document uses the following terms: requesting router The router that acts as a DHCP client and is requesting prefix(es) to be assigned. delegating router The router that acts as a DHCP server, and is responding to the prefix request. Identity Association for Prefix Delegation (IA_PD) A collection of prefixes assigned to the requesting router. Each IA_PD has an associated IAID. A requesting router may have more than one IA_PD assigned to it; for example, one for each of its interfaces.3. Requirements 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 RFC 2119 [1].Troan & Droms Expires August 11, 2003 [Page 3] Internet-Draft IPv6 Prefix Options for DHCPv6 February 20034. Model and Applicability The model of operation for prefix delegation is as follows. A delegating router is provided DHCPv6 prefixes to be delegated to requesting routers. Examples of ways in which the delegating router may be provided these prefixes are given in Section 11.2. A requesting router requests prefix(es) from the delegating router, as described in Section 11.1. The delegating router chooses prefix(es) for delegation, and returns the prefix(es) to the requesting router. The requesting router is then responsible for the delegated prefix(es). For example, the requesting router might assign a subnet from a delegated prefix to one of its interfaces, and begin sending router advertisements for the prefix on that link. Each prefix has an associated valid and preferred lifetime, which constitutes an agreement about the length of time over which the requesting router is allowed to use the prefix. A requesting router can request an extension of the lifetimes on a delegated prefix and is required to terminate the use of a delegated prefix if the valid lifetime of the prefix expires. This prefix delegation mechanism would be appropriate for use by an ISP to delegate a prefix to a subscriber, where the delegated prefix would possibly be subnetted and assigned to the links within the subscriber's network.Troan & Droms Expires August 11, 2003 [Page 4] Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 Figure 1 illustrates a network architecture in which prefix delegation would be used. +--------+ \ | AAA | \ | server | \ +---+----+ | ___|__________________ | / \ | | ISP core network | | \__________ ___________/ | | | ISP +-------+-------+ | network | Aggregation | | | device | | | (delegating | | | router) | | +-------+-------+ | | / |DSL to subscriber / |premises / | +------+------+ \ | CPE | \ | (requesting | \ | router) | | +----+---+----+ | | | | Subscriber ---+-------------+-----+- -+-----+-------------+--- | network | | | | | +----+-----+ +-----+----+ +----+-----+ +-----+----+ | |Subscriber| |Subscriber| |Subscriber| |Subscriber| / | PC | | PC | | PC | | PC | / +----------+ +----------+ +----------+ +----------+ / Figure 1: An example of prefix delegation. In this example an AAA server is configured with a prefix assigned to the customer at the time of subscription to the ISP service. The prefix delegation process begins when the requesting router requests configuration information through DHCP. The DHCP messages from the requesting router are received by the delegating router in the aggregation device. When the delegating router receives the request, it consults the AAA server to authenticate and authorise the requesting router. The AAA server returns the subscriber's prefix(es) in a Framed-IPv6-Prefix attribute as described in RFC 3162 [7], and the delegating router returns them to the requesting router.Troan & Droms Expires August 11, 2003 [Page 5] Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003 The requesting router assigns longer prefixes from the delegated prefix for assignment to links in the subscriber's network. In a typical scenario based on the network shown in Figure 1, the requesting router subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network. The prefix delegation options can be used in conjunction with other DHCP options carrying other configuration information to the requesting router. The requesting router may, in turn, then provide DHCP service to hosts attached to the internal network. For example, the requesting router may obtain the addresses of DNS and NTP servers from the ISP delegating router, and then pass that configuration information on to the subscriber hosts through a DHCP server in the requesting router.5. Identity Association for Prefix Delegation An IA_PD is a construct through which a delegating router and a requesting router can identify, group and manage a set of related IPv6 prefixes. Each IA_PD consists of an IAID and associated configuration information. An IA_PD for prefixes is the equivalent of an IA (described in DHCPv6 specification [6]) for addresses. An IA_PD is different from an IA, in that it does not need to be associated with exactly one interface. One IA_PD can be associated with the requesting router, with a set of interfaces or with exactly one interface. A requesting router must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the delegating router. The IAID uniquely identifies the IA_PD and must be chosen to be unique among the IA_PD IDs on the requesting router. The IAID is chosen by the requesting router. For any given use of an IA_PD by the requesting router, the IAID for that IA_PD MUST be consistent across restarts of the requesting router. The requesting router may maintain consistency either by storing the IAID in non-volatile storage or by using an algorithm that will consistently produce the same IAID as long as the configuration of the requesting router has not changed. If the requesting router uses only one IAID, it can use a well-known value, e.g zero. The configuration information in an IA_PD consists of one or more IPv6 prefixes along with the times T1 and T2 for the IA_PD. See section Section 8 for the representation of an IA_PD in a DHCP message.Troan & Droms Expires August 11, 2003 [Page 6] Internet-Draft IPv6 Prefix Options for DHCPv6 February 2003⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -