Individual Submission Byung-Yeob Kim Internet-Draft Kyeong-Jin Lee Jung-Soo Park Hyoung-Jun Kim ETRI Expires: April 2004 20 October 2003 Hierarchical Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6) Status 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. Abstract Stateless Autoconfiguration enables IPv6 hosts to send a request for a prefix, a network identifier to a router on the subnet. Using this ability a host can configure its IPv6 address. Likewise, by defining a way to request for a prefix to an upper level router, a router can get a prefix to be assigned to its subnet. This document describes a protocol for prefix delegation between routers. It allows routers get prefixes from its upstream routers, enabling the entire network and its belonging hosts autoconfigure their own addresses. Kim, et al. Expires - April 2004 [Page 1] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Conventions used in this document 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 [RFC 2119]. Table of Contents 1. Terminology...................................................2 2. Introduction..................................................3 3. Protocol Overview.............................................3 3.1 Prefix Negotiation.......................................3 3.2 Prefix Delegation........................................4 3.3 Router Authentication....................................4 3.4 Prefix Return............................................4 3.5 Built-in Routing.........................................5 4. Messages......................................................5 4.1 Prefix Request Message...................................5 4.2 Prefix Delegation Message................................7 4.3 Prefix Information Option................................9 5. Security Consideration.......................................10 6. IANA considerations..........................................10 7. Acknowledgements.............................................10 8. Copyright....................................................11 9. Normative References.........................................11 10. Authors' Addresses..........................................12 1. Terminology This document uses the terminology defined in [RFC 2460] and [RFC 2461] with the following new terms: Requesting Router The router requesting prefixes to be assigned for its subnets. Delegating Router The router responding to the Prefix request. Root Router The Root Router is placed on top of the network hieararchy where the Hierarchical Prefix Delegation begins. Only the Root Kim, et al. Expires - April 2004 [Page 2] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Router requires manual administration and is assumed to have an interface to the Global Internet. The Root Router is a Delegating Router. 2. Introduction This specification defines the Hierarchical Prefix Delegation (HPD) protocol for Internet Protocol Version 6 (IPv6). It is an extended prefix delegation protocol based on Automatic Prefix Delegation Protocol first introduced by B. Harberman and J.Martin [APD]. It absorbs basic prefix delegation abilities of its predecessor with a couple of extensions: Extended Prefix Delegation - Prefix Delegation is not limited to a leaf router. Once a Requesting Router receives a prefix from its upstream router, it can play the role of the Delegating Router. It provides its downstream routers with parts of its address space by delegating longer level prefixes, enabling multiple-level hierarchical prefix delegation. Built-in Routing capability - The Hierarchical Prefix Delegation protocol (HPD) provides routing capability that enables routing on "HPDed" routers without external routing protocols such as RIP or OSPF. 3. Protocol Overview The Hierarchical Prefix Delegation protocol defines two new ICMPv6 message types, the Prefix Request and the Prefix Delegation. The Prefix Request is used by the Requesting Router to send requests to the Delegating Router. Conversely, the Prefix Delegation is used by the Delegating Router to send prefixes and other information to the Requesting Router. The actual prefix delivery is made by Prefix Information Option included in these messages. 3.1 Prefix Negotiation The Requesting Router begins the Hierarchical Prefix Delegation protocol by sending a Prefix Request message of code "Delegator Query" to the All-routers link-local multicast address (FF02::2). The Requesting Router SHOULD specify the number of prefixes it wishes to receive. Upon receiving the "Delegator Query" the Delegating Router determines if it has enough available prefixes. If so, it unicasts a Prefix Kim, et al. Expires - April 2004 [Page 3] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Delegation message of code "Prefix Delegator" back to the Requesting Router. The message MUST contain the number of available prefixes, their prefix length and the prefix length difference. If more than one reply is received from multiple Delegating Routers, the Requesting Router SHOULD choose the one with the shorter prefix length. Note that these messages are for negotiation purpose only. Actual prefix delivery is not provided in this phase. 3.2 Prefix Delegation Once a Delegating Router is chosen, the Requesting Router sends a Prefix Request message of code "Initial Request" to the unicast IP address of the Delegating Router. The Requesting Router MUST confirm the prefix length and the prefix difference by sending back these parameters in the message. The number of requesting prefixes MUST be less than or equal to the number of prefixes in the received "Prefix Delegator." Upon receiving the "Initial Request" the Delegating Router replies by sending Prefix Delegation message with a code of "Prefix Delegated." The message MUST include one or more Prefix Information Options. 3.3 Router Authentication Depending on the administor's local policy, the Delegating Router can mandate the use of Cryptographically Generated Address (CGA) as a Source Address. For "Initial Request" without an authorized Source Address, the Delegating Router returns Prefix Delegation message with a code of "Authenticaion Required." A Requesting Router receiving this message MAY reinitiate the request by sending Prefix Request message with a valid CGA address. A Delegating Router who has received a message with a CGA as a source address MUST verify its validity. For messages with invalid CGA the Delegating Router SHOULD reply back a Prefix Delegation message with a code of "Authenticaion Failed." 3.4 Prefix Return A Requesting Router SHOULD return the delegated prefixes when it does not need them any more. It sends Prefix Request message with a code of "Prefix Returned" to Delegating Router. Returning prefixes MUST be stored in Prefix Information Options included in the message. Once a prefix is returned, the Delegating Router replies back with a Prefix Delegation message with code "Prefix Returned." Returning Kim, et al. Expires - April 2004 [Page 4] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 prefixes SHOULD be contained in Prefix Information Options for confirmation. Once a prefix is returned, the prefix belongs to the Delegating Router and the Delegating Router recycles it. A Requesting Router can extend the life time of a prefix by sending Prefix Request message with a code of "renewal Request." Expired prefixes MUST NOT be used anymore and SHOULD be considered to be returned by the Delegate Router. 3.5 Built-in Routing The Root Router MAY run with a built-in routing option. When this option is turned on, the Root Router and its all subsidiary Delegating Routers keep track of delegated prefixes, being aware of which subnet is being used on which interface. Using longest matching, packets with a source address of delegated prefix will be forwarded to the corresponding downstream router. Packets with an unidentified destination will be sent to the upstream router. This option MUST be set initially by the administrator when the Root Router starts bootstrapping and SHOULD be inherited to its subsidiary routers. 4. Messages All messages have the following general 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixCnt | PrefixLen | PrefixDiff |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Prefix Information Option + | | 4.1 Prefix Request Message The Prefix Request Message is used to request, renew, or return prefixes. IP Fields Source Address Kim, et al. Expires - April 2004 [Page 5] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 A Cryptographically Generated Address (CGA) or an ordinary IP address assigned to the sending interface. Destination Address The All-Routers link-local multicast address (FF02::2) for Delegator Query messages. All other Prefix Request messages should be sent to a unicast address of the Delegating Router. ICMP Fields Type TBD Code The Type of code: Delegator Query (0) The Delegator Query is used by the Requesting Router to identify potential Delegating Routers. It is sent to the all-routers link-local multicast address. The requesting router MAY specify the number of prefixes it is requesting in PrefixCnt field. Initial Request (1) The Initial Request is to initiate the request process. It is sent to the unicast IP address of the Delegating Router. The PrefixLen and PrefixDiff fields MUST have the same value received through the Prefix Delegator message while PrefixCnt has less or equal value as the Prefix Delegator message. Renewal Request (2) The Renewal Request is to renew the lifetime of prefixes that have been previously allocated. It is sent to the unicast IP address of the Delegating Router. One or more Prefix Information Options MUST be included for this message. Prefix Return (3) The Prefix Return is used to return prefixes to the Delegating Router. It is sent to a unicast IP address of the Delegating Router. One or more Prefix Information Options MUST be included for this message. Checksum The ICMP checksum as defined in RFC [2463]. PrefixCnt Kim, et al. Expires - April 2004 [Page 6] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 For messages with the code of "Delegator Query" or "Initial Request," The PrefixCnt indicates the number of prefixes the Requesting Router is requesting for. Otherwise, it denotes the number of Prefix Information options attached to the message. PrefixLen The PrefixLen indicates the length of the prefix. For a "Prefix Request" message with a code of "Initial Request," it must be the same value as the PrefixLen received through the previously received Prefix Delegation message with code of "Prefix Delegator." For other Prefix Request messages, it MUST be set to zero. PrefixDiff The PrefixDiff is used to confirm the PrefixDiff value received through the Prefix Delegation message with code of "Prefix Delegator." For other Prefix Request messages it MUST be set to zero. R The R flag is not used in this message. Reserved Reserved for future use. Must be set to zero. 4.2 Prefix Delegation Message The Prefix Delegate Message is used to provide the Requesting Router with prefixes and other valuable information like error returns. IP Fields Source Address A Cryptographically Generated Address (CGA) or an ordinary IP address assigned to the sending interface. Destination Address The IP address of the Requesting Router specified by the Source Address in the Prefix Request message. ICMP Fields Type TBD Code The Type of Response Code: Kim, et al. Expires - April 2004 [Page 7] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Prefix Delegator (0) The Prefix Delegator is to inform the Requesting Router the number of available prefixes. It is sent to the unicast IP address specified in the Source Address portion of the Prefix Request message. The number of available prefixes is specified in the PrefixCnt field. The PrefixCnt of zero indicates that Prefix Delegator does not have available prefix at all. The Delegating Router MUST specify the length of the available prefixes and the difference of the prefix lengths between the Delegating Router and the Requesting Router as well. Authentication Required (1) The Authentication Required is use to inform the Requesting Router that a Cryptographically Generated Address must be used as a source address. It is sent to the unicast IP address in the Source Address portion of the Prefix Request message. Unused fields must be initialized to zero. Authorization Failed (2) The Authorization Failed is use to inform the Requesting Router that its source address is failed to be verified. It is sent to the unicast IP address in the Source Address portion of the Prefix Request message. Unused fields must be initialized to zero. Prefix Delegated (3) The Prefix Delegated delivers the actual prefixes the Requesting Router has requested. It is sent to the unicast IP address in the Source Address portion of the Prefix Request message. One or more Prefix Information Options MUST be included for this message. Prefix Returned (4) The Prefix Returned is used to confirm the return of the prefixes. It is sent to the unicast IP address in the Source Address portion of the Prefix Request message. One or more Prefix Information Options MUST be included for this message. Checksum The ICMP checksum as defined in RFC [2463]. PrefixCnt For the message with a code of "Prefix Delegator," The PrefixCnt indicates the number of prefixes the Delegating Kim, et al. Expires - April 2004 [Page 8] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Router is to offer. Otherwise, it denotes the number of Prefix Information options attached to the Prefix Delegation message. PrefixLen The PrefixLen indicates the length of the prefix. For a message with a code of "Prefix Delegator," The PrefixLen indicates the length of prefixes the Delegating Router is to offer. For other Prefix Delegation messages it MUST be set to zero. PrefixDiff The PrefixDiff indicates the prefix length difference between the Requesting Router and the Delegating Router, configured by an administrator. Initially it is set by the administrator on the Root Router and will be inherited over routers down to the leaf router. R The R flag is used to inform the Requesting Router to use built-in routing. Reserved Reserved for future use. Must be set to zero. 4.3 Prefix Information Option The Prefix Information Option is used to relay prefix between Requesting Router and Delegating Router. A message doing prefix delievery contains exact the same number of the options as specified in the PrefixCnt field. It has the following 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kim, et al. Expires - April 2004 [Page 9] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Prefix Option Fields Type TBD This field indicates the presence of a Prefix Information. Length The length of the prefix contained in this option. Reserved Reserved for future use. This field must be set to zero. Prefix Lifetime The lifetime of the prefix contained in the option. Prefix This field contains an IPv6 Prefix. The portion of bits longer than the specified length MUST be filled with zero. 5. Security Consideration Prefix Delegation opens up several vulnerabilities. A node may attempt to request prefixes to deplete Delegating Router's prefix pool. On the other hand a node may reply to the Delegation Request with certain short-length prefixes to disrupt the delegation. In order to prevent illicit nodes, Routers using Hierarchical Prefix Delegation Protocol need an authentication method. Using Cryptographically Generated Address as a Source Address is suggested for this purpose. Using CGA option and signature option devised by Secure Neighbor Discovery working group [SEND] is RECOMMENDED in this case. Employing other options being articulated in the working group is also preferable for better security. 6. IANA considerations This document defines two new ICMP message types and one ICMP Option type. They must be assigned ICMPv6 type numbers. 7. Acknowledgements We would like to acknowledge B. Harberman and J. Martin for their invention of the Automatic Prefix Delegation Protocol which this Kim, et al. Expires - April 2004 [Page 10] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 draft is based on. We would also like to thank Wan-Jik Lee and Seok- Yeul Heo for their implementation efforts on Hierarchical Prefix Delegation Protocol on Linux OS. 8. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 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 implementation 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 assignees. 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. 9. Normative References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Kim, et al. Expires - April 2004 [Page 11] Internet-Draft Hierarchical Prefix Delegation Protocol October 2003 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2463] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [CGA] T. Aura, "Cryptographically Generated Addresses (CGA) ", working in pregress, [SEND] J. Arkko, "SEcure Neighbor Discovery (SEND) ", working in progress, [APD] B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6", expired, 10. Authors' Addresses Byung-Yeob Kim skylane@etri.re.kr Phone: +82 42 860 6627 Kyeong-Jin Lee leekj@etri.re.kr Phone: +82 42 860 6484 Jung-Soo Park pjs@etri.re.kr Phone: +82 42 860 6514 Hyoung-Jun Kim khj@etri.re.kr Phone: +82 42 860 6576 Protocol Engineering Center, Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-Gu Daejon 305-350 Republic of Korea Kim, et al. Expires - April 2004 [Page 12]