Internet Draft Nathan Lutchansky <draft-lutchann-ipv6-delegate-option-00.txt> Cornell University Expires: August 2002 February 2002 IPv6 Router Advertisement Prefix Delegation Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This document defines the Prefix Delegation (PD) option used to delegate IPv6 address space to simple IPv6 sites. The PD option, which lists the global prefixes that a site may use to number its network, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a point-to-point link from a provider's router to a site's border router. This document defines the mechanism by which a site router processes the PD option and configures each of its attached links allowing hosts within the site to obtain global addresses using address autoconfiguration. 1. Introduction This specification defines the Prefix Delegation (PD) option for the Neighbor Discovery protocol of IPv6. The PD option extends the functionality of Router Advertisement messages [DISCOVERY] to enable configuration of a site router. Router Advertisement messages sent by a provider's router over a point-to-point link can be used to assign one or more address prefixes of arbitrary size to a site, allowing sites with a single router to fully configure the site network with no administrator intervention. Many sites, particularly home users and small businesses, have connectivity needs that are satisfied by a network with a single Ethernet link, a "plug-and-play" router, and an uplink to a single provider. The PD option provides a standard mechanism for numbering the link(s) within such sites, as the configuration of all of these sites is substantially the same. This document is heavily based on [DISCOVERY], and the author wishes to thank T. Narten, E. Nordmark, and W. Simpson for producing it. The author would also like to acknowledge the work of Jun-ichiro itojun Hagino and Kazu Yamamoto in surveying possible mechanisms for site configuration that eventually lead to this specification. 2. Terminology IP - Internet Protocol Version 6. node - a device that implements IP. router - a node that forwards IP packets not addressed to itself. link - a facility over which nodes can exchange IP datagrams, for example, Ethernet, Token Ring, PPP links, and IP tunnels. point-to-point link - a link serving precisely two nodes, for example, PPP links and IP tunnels. uplink - a point-to-point link between a provider's router and a router located at a site. site - an IP network, consisting of a single router and one or more links, controlled by a single organization or individual and connected to the Internet via an uplink. prefix - a bit string that consists of some number of initial bits of an address. link prefix - a prefix unique to a link from which nodes may derive global addresses using either manual configuration or address autoconfiguration as described in [ADDRCONF]. delegated prefix - a prefix assigned to a site by a provider, from which the site may derive link prefixes. 2.1. 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 [KEYWORDS]. 3. Protocol overview 3.1. Deployment scenario The PD option should be used to configure simple site networks that contain only a single router and a single point-to-point uplink: +-----------------+ | Provider Router | +-----------------+ ^ La | | P-t-P link | v Lb +-----------------+ | Site Router | +-----------------+ Gx | | Gy | | | +--> Site link #1 | +------> Site link #2 In such a network, the P-t-P link uses only link-local addresses (La and Lb), and the site links are each assigned a global prefix. The only global addresses assigned to the site router are Gx and Gy, which are derived from the global prefixes assigned to each link. The assignment of the link-local addresses is performed using techniques specific to each link type and is beyond the scope of this document. The PD option SHALL NOT be used to configure any site more complex than that described above. It is inappropriate for sites containing multiple routers, multiple uplinks, or routes updated using routing protocols. A provider can assign address prefixes to customer sites either statically, in which a customer receives the same prefix every time a session is established, or dynamically, in which prefixes are allocated from a pool when a customer connects and returned to the pool upon disconnect. Both types of assignments can be accomodated by the PD option through appropriate settings of the lifetime fields, which specify the duration of time for which the site may use the site prefix. 3.2. Provider router operation Upon establishment of a point-to-point link between a provider router and a customer router, the provider router SHOULD commence sending Router Advertisement messages containing the PD option. The provider MUST route all packets destined for any address within the prefix specified in the PD option to the customer router. 3.3. Site router operation Once a site router has established a point-to-point link to the provider router, it SHOULD send Router Solicitation messages as described in [DISCOVERY]. Upon receiving a Router Solicitation message containing a Prefix Delegation option, the router MUST process the message as described in [DISCOVERY] and [ADDRCONF] before processing the PD option. 3.3.1. Prefix Delegation option processing If the site wishes to autoconfigure itself using the information provided by the PD option, the site router MUST allocate a link prefix for each link using a portion of the address block provided in the PD option. The link prefix assignments MUST be made in accordance with [ADDR-ARCH], which will require that the link prefixes are 64 bits long. The site router SHOULD preserve this numbering in persistent storage to allow the same assignments to be made after a reboot of the site network equipment. Once the site router has numbered each link, it SHOULD send Router Advertisement messages to allow hosts to use address autoconfiguration [ADDRCONF] to obtain global addresses. The Valid Lifetime and Preferred Lifetime of advertised link prefixes that have been derived from the delegated prefix MUST be less than or equal to the Valid Lifetime and Preferred Lifetime, respectively, specified in the PD option received from the provider router. 4. Prefix Delegation option format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type XXX [TBD: IANA] Length 4 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 64. Reserved1 8-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for use by nodes at the site. A value of all one bits (0xffffffff) represents infinity. The site router MUST NOT advertise prefixes derived from the PD prefix using a valid lifetime longer than this field. Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF]. The site router MUST NOT advertise prefixes derived from the PD prefix using a preferred lifetime longer than this field. Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix A prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. The Prefix Delegation option appears in Router Advertisement packets and MUST be silently ignored for other messages. It MUST NOT be sent in such a way that the message might be received by multiple hosts; i.e. it can only be multicast on a point-to-point link. 5. Security considerations Security issues regarding the Neighbor Discovery protocol are discussed in [DISCOVERY]. Author's Address Nathan Lutchansky P.O. Box 33164 Juneau, AK 99803-3164 Phone: (907) 780-4670 EMail: lutchann@litech.org References ADDRCONF Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. ADDR-ARCH Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. DISCOVERY Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. KEYWORDS Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.