Network Working Group Arun Thulasi Internet-Draft Shankar Raman Hewlett-Packard April 2004 IPv6 Prefix Delegation Using ICMPv6 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. This Internet-Draft will expire on October 24, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a Prefix Delegation Mechanism which delegates IPv6 prefixes to a subscriber's network (or "site") by an Internet Service Provider (ISP). It uses ICMPv6 messages to handle Prefix Delegation between the Delegating Router and the Requesting Router. Table of Contents 1. Introduction............................................ 3 2. Terminologies and Definitions........................... 3 2.1 Basic Terminologies and Setup........................ 3 2.2 Mechanism Specific Terminology....................... 4 3. Alignment with Requirements............................. 5 3.1 Number and Length of Delegated Prefixes.............. 5 3.2 Use of Delegated Prefixes in Customer Network........ 5 Arun & Shankar Expires October 30, 2004 [Page 1] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 3.3 Static and Dynamic Assignment........................ 5 3.4 Policy-based Assignment.............................. 5 3.5 Expression of Requirements or Preferences by the CPE.............................................. 5 3.6 Security Mechanism................................... 6 3.7 Accounting........................................... 6 3.8 Hardware Technology Considerations................... 6 4. Message Types........................................... 6 4.1 Prefix Solicitation.................................. 6 4.2 Prefix Delegation.................................... 8 4.3 Option Formats....................................... 10 4.3.1 Source Link-layer Address Option................ 11 4.3.2. Arbitrary Delegation Request Option............. 11 4.3.3. Block Delegation Request Option................. 13 4.3.4. Individual Prefix Delegation Request Option.......................................... 16 4.3.5. Block Delegation Response Option................ 18 4.3.6. Individual Prefix Delegation Response Option.......................................... 19 5. Prefix Delegation Mechanism and Overview................ 20 5.1 Conceptual Data Structures........................... 20 5.2 States of Prefixes................................... 21 5.3 Conceptual Sending Algorithm......................... 22 6. Requesting Router Specification......................... 23 6.1 Prefix Solicitation by a Requesting Router........... 23 6.1.1 Prefix Solicitation Header Specification........ 23 6.1.2 Prefix Solicitation Option Specification........ 24 6.2 Prefix Delegation Acknowledgement & Returning by a Requesting Router............................... 25 6.2.1 Prefix Delegation Acknowledgement Header Specification................................... 25 6.2.2 Prefix Delegation Acknowledgement Option Specification................................... 25 6.3 Prefix Renewal by a Requesting Router................ 25 6.3.1 Prefix Solicitation Header Specification........ 26 6.3.2 Prefix Solicitation Option Specification........ 26 6.4 Prefix Delegation Message Validation by Requesting Router.................................... 27 6.4.1 Prefix Delegation Header Validation............. 27 6.4.2 Prefix Delegation Option Validation............. 27 6.5 Configurable Parameters for Requesting Router........ 28 7. Delegating Router Specification......................... 28 7.1 Prefix Delegation by a Delegating Router............. 28 7.1.1 Prefix Delegation Header Specification.......... 28 7.1.2 Prefix Delegation Option Specification.......... 29 7.2 Prefix Revoking by a Delegating Router............... 29 7.2.1 Prefix Revoking Header Specification............ 29 7.2.2 Prefix Delegation Option Specification.......... 29 7.3 Prefix Solicitation Message Validation by Delegating Router.................................... 30 7.3.1 Prefix Solicitation Header Validation........... 30 Arun & Shankar Expires October 30, 2004 [Page 2] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 7.3.2 Prefix Solicitation Options Validation.......... 30 7.4 Configurable Parameters for Delegating Router.......... 31 8. IANA Considerations........................................ 31 9. Security Considerations.................................... 32 References.................................................... 32 Authors' Addresses............................................ 32 Appendix A: Usage of Service Bands and Discretion Flag........ 33 Appendix B: Implementation Suggestions on Usage of Prefix States..................................... 33 Appendix C: Future Options.................................... 33 Full Copyright Statement...................................... 34 Acknowledgements.............................................. 34 1. Introduction With the introduction of IPv6 [IPv6], the address space for nodes has increased manifold. With such an increased address space several ISPs would be ready to provide the IPv6 access to the public. With such a task in mind, a requirements draft specifying Requirements for IPv6 Prefix Delegation [PDReq] was written. It specifies the requirements for an efficient mechanism to delegate prefixes from the ISP's site to the customer's site. It also mentions that the delegating mechanism should automate the process of informing the customer's networking equipment of the prefixes to be used at the customer's site. This document describes a mechanism to delegate prefixes from PE to CPE. 2. Terminologies and Definitions 2.1 Basic Terminologies and Setup The following figure illustrates a likely example for the organization of a network providing subscription IPv6 service: /------\ / \ + | / \ / +---------------+ +--------+/ \------/ |ISP Edge Router|Point-to-point|Customer+ | +--------------+ Router | Customer networks | (PE) | link | (CPE) + +---------------+ +--------+\ /------\ \ / \ + | \ / \------/ Figure 1: Illustration of ISP-customer network architecture Arun & Shankar Expires October 30, 2004 [Page 3] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 | <----- ISP Premises ---->|<----- Customer Premises ----> | +---------------+ Request|Prefix +------------+ | Delegating |<-------|--------| Requesting | | Router |--------|------->| Router | +---------------+Delegate| Prefix +------------+ | /Customer\ | / Networks \ | /--------\ /---------\ | + + + + | \--------/ \---------/ Figure 2: Illustration of relationship between a Requesting Router and a Delegating Router PE: Provider edge device; the device connected to the service provider's network infrastructure at which the link to the customer site is terminated CPE: Customer premises equipment; the device at the customer site at which the link to the ISP is terminated RR: Requesting Router; the router on the customer's end which makes the requests to the CPE. It could also be a single machine which requires a prefix for it's own address. DR: Delegating Router; the router on the ISP's end which delegates the addresses to the RR. 2.2 Mechanism Specific Terminology Prefix Solicitation(PS) - A message type with which a RR makes a request to the DR to allocate a set of prefixes for itself. Prefix Delegation(PD) - A message type with which a DR delegates a set of prefixes to an RR. This may or may not be in response to a PS message. Arbitrary Delegation(AD) - A type of delegation where the CPE does not have any particular preference over any prefix, but requires just an arbitrary number of prefixes at a specified prefix length. Block Delegation(BD) - A type of delegation where the CPE prefers that its prefixes be within a specified range and with a specified prefix length. Individual Delegation(ID) - A type of delegation where the CPE requires a certain individual prefix at a specified length. Arun & Shankar Expires October 30, 2004 [Page 4] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 3. Alignment with Requirements The mechanism specified in this document intends to solve the requirements issues specified in [PDReq]. A summary of the requirements and the solutions are as below. 3.1 Number and Length of Delegated Prefixes The mechanism specified allows the CPE to request multiple prefixes with multiple prefix lengths for each type of prefix requested. It also allows the CPE to make prefix requests in different formats with different preferences in one single request. 3.2 Use of Delegated Prefixes in Customer Network In the mechanism specified, the PE does not impose any rule or restrictions on the creation of longer, different prefixes by the CPE once it has been delegated a given set of prefixes. It allows the CPE to form its own set of prefixes from the set of prefixes that were delegated to it by the PE and further delegate them inside the customer's network. 3.3 Static and Dynamic Assignment The mechanism specified would be capable of handling both static, long-lived pre-assignment of addresses and dynamic, short-lived, on-demand assignment of prefixes to a customer. Pre-assignment of addresses refers to a case where the number of prefixes to be delegated to the Requesting Router (RR) are determined before the first request is made from the RR to the Delegating Router (DR). An example could be a case where the CPE is assigned a set of prefixes after completing a process of registration over paper. The mechanism specified differentiates between static and dynamic prefixes based on the requested/assigned valid lifetimes of the prefixes. 3.4 Policy-based Assignment The mechanism specified would allow the PE to perform policy based assignment of prefixes to the CPE. This policy may include decisions that determine the number, length and valid lifetimes that could be assigned to a particular CPE. Using such policies, the PE should be able to serve a CPE's request as requested or it could serve it as best as it could. 3.5 Expression of Requirements or Preferences by the CPE The mechanism specified would allow the CPE to specify the various preferences that it has over the prefix that it requests. These preferences include - An arbitrary number of prefixes for a specified length - A block of contiguous prefixes within the address space, each such block with a certain prefix length. - An individual prefix that is fully specified, with a certain Arun & Shankar Expires October 30, 2004 [Page 5] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 prefix length. 3.6 Security Mechanism The mechanism specified allows the CPE and the PE to use supported security mechanisms. For example, ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. 3.7 Accounting The mechanism specified would allow the PE to obtain various accounting information about the prefixes delegated. 3.8 Hardware Technology Considerations The mechanism specified does not have any known hardware technological limitations and would work on any hardware technology between the CPE and PE. It does not post any restrictions on the ISP's ability to utilize any hardware technology's authentication mechanism, if available. 4. Message Types 4.1 Prefix Solicitation A Prefix Solicitation (PS) message is sent by the RR to the DR requesting for a set of prefixes that are specified in the message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Service |D|A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface of the RR Destination Address The IP address of the DR Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Arun & Shankar Expires October 30, 2004 [Page 6] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type PD_CPE_REQUEST Code 0 Checksum The ICMP Checksum. See [ICMPv6]. Seq Num 16-bit unsigned integer. The Sequence Number for this request. It is generated by the RR and should be uniformly distributed across the requests. It SHOULD be a non-zero value. This SHOULD be used in all requests and returns of prefixes. The Sequence Number is used as a message identifier between the RR and DR and SHOULD not change during one transaction. Service 8-bit unsigned integer. The Service-Band of the customer making this request. The RR MAY set it to its existing Service-Band or to another Service-Band that it expects itself to be from now on. The Service-Band signifies the kind of preferential service that the RR enjoys with the DR. The usages of the Service field are discussed in Appendix A. D One bit "Discretion" flag. If it is set by the RR it indicates that the the DR is allowed to use it's discretion while serving this request. This allows the RR to express its requests freely, and at the same time allowing the DR to apply its policies depending on the RR. It MAY be set by the RR if it wants to allow DR to use its discretion in allocating addresses to this request. The usages of the Discretion flag are discussed in Appendix A. A One bit "Acknowledgement" flag. If it is set, it means that the RR is acknowledging a reply from the DR. It SHOULD be set to zero in a request message. It SHOULD be set to one while acknowledging the receipt of prefixes and returning of prefixes. Reserved 6-bit Reserved Field. It MUST be initialized to zero by the sender and MUST be ignored by the Arun & Shankar Expires October 30, 2004 [Page 7] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 receiver. Identifier 32-bit unsigned integer. Unique identifier for this RR. It SHOULD be set to zero if the RR does not know its identifier. A value of zero would mean that the DR has to allocate an identifer for this RR. Once the RR has been alloted its Identifier, it MUST use it in all its future communications. The Identifier could be a pre-assigned Identifier given by the DR. Possible Options: Arbitrary Delegation Prefix Options Arbitrary Delegation Prefix options can be specified. The RR could require 'm' sets of 'n' prefixes with 'x' bits in prefix length, where a set is defined as {number of prefixes, prefix length} Block Delegation Prefix Options Block Delegation Prefix options can be specified. The RR could require 'm' sets of 'n' prefixes which lie within a certain block of addresses and are 'x' bits in prefix length, where a set is defined as {number of prefixes, prefix length} Individual Delegation Prefix Options Individual Delegation Prefix options can be specified. The RR could require 'm' sets of prefixes which have 'y' as prefix, where a set is defined as {prefix, prefix length} Source Link Layer Address The Source Link Layer Address option MUST be specified in cases when the RR requests a new Identifier. It MUST not be specified when the RR knows its Identifier. 4.2 Prefix Delegation A Prefix Delegation (PD) message is sent by the DR to the RR delegating a set of prefixes that are specified in the message. Arun & Shankar Expires October 30, 2004 [Page 8] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq Num | Service |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface of the DR. Destination Address The source IP address of the packet that sent the request with the current sequence number. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type PD_PE_RESPONSE Code 0 Checksum The ICMP Checksum. See [ICMPv6]. Seq Num 16-bit unsigned integer. The Sequence Number for this request. It is the same Sequence Number of the PS message that generated this response. It SHOULD be a non-zero value. This should be used in all responses. Service 8-bit unsigned integer. The Service-Band assigned to the customer making this request. The DR sets it to its existing Service-Band for the RR. The Service-Band signifies the kind of preferential service that the RR enjoys with the DR. A 1-bit Acknowledgement Flag. It SHOULD be set to 1 when the DR is acknowledging a request from the RR. It SHOULD be set to zero when the DR Arun & Shankar Expires October 30, 2004 [Page 9] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 is sending a message on it's own. Reserved 7-bit Reserved field. SHOULD be set to zero by the DR and should be ignored by the RR. Identifier 32-bit Identifier field. Created by the DR using the RR's interface identifier. Uniquely identifies a RR. The way in which the DR generates the Identifier is implementation dependent. Possible Options: Block Delegation Prefix Options Block Delegation Prefix options can be specified. The DR could delegate 'm' sets of 'n' prefixes which lie within a certain block of addresses and are 'x' bits in prefix length. where a set is defined as {number of prefixes, prefix length} Individual Delegation Prefix Options Individual Delegation Prefix options can be specified. The DR could delegate 'm' sets of prefixes which have 'y' as prefix, where a set is defined as {number of prefixes, prefix length}. 4.3 Option Formats Prefix Delegation messages include zero or more options, some of which may appear multiple times in the same message. All options are of the form: 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 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 8-bit identifier of the type of option. The options defined in this document are: Option Name Type Source Link-Layer Address 1 Arbitrary Delegation Request Option 2 Arun & Shankar Expires October 30, 2004 [Page 10] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Block Delegation Request Option 3 Individual Delegation Request Option 4 Individual Delegation Response Option 5 Block Delegation Response Option 6 4.3.1. Source Link-layer Address Option 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 | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 1 for Source Link-layer Address Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. Description The Source Link-Layer Address option contains the link-layer address of the sender of the packet. It is used in the Prefix Request messages when the RR does not know its unique identifier. These options MUST be silently ignored for other messages. 4.3.2. Arbitrary Delegation Request Option 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 |No.of Prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arun & Shankar Expires October 30, 2004 [Page 11] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Fields: Type 2 for Arbitrary Delegation Request Option Length 2 Prefix Length 8-bit unsigned integer. The length of the requested prefix. The value ranges from 0 to 128. It denotes the length of the all the prefixes that would be delegated as a response to this message. A value of 0 notifies the DR to use it's default prefix length. No. of Prefixes 8-bit unsigned integer. The number of prefixes requested by the RR in this message. Reserved 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 1 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix(es) to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have (one of) the associated prefix(es) in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix(es). A value of all 1 bits (0xffffffff) set in a Arbitrary Delegation Request Message by the RR is invalid. It SHOULD NOT be set by the sender and SHOULD be silently ignored by the receiver. Valid Lifetime 2 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix(es) to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have (one of) the associated prefix(es) in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix(es). Valid Lifetime 2 SHOULD be set to a value lesser than Valid Lifetime 1. Valid Lifetime 2 SHOULD be set to zero by the Arun & Shankar Expires October 30, 2004 [Page 12] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 sender and ignored by the receiver if Valid Lifetime 1 is all-zero. A value of all 1 bits (0xffffffff) set in a Arbitrary Delegation Request Message by the RR is invalid. It SHOULD NOT be set by the sender and SHOULD be silently ignored by the receiver. Description The RR can use the Arbitrary Delegation Request Option to request for an arbitrary number of prefixes which have an specified prefix length. It can specify two values as expected valid lifetimes for the DR to choose from. If the RR is not specific about lifetimes, it SHOULD set both the fields to zero. A value for infinite valid lifetime is disallowed. The Arbitrary Delegation Request option appears in a PD_CPE_REQUEST message. These options MUST be silently ignored for other messages. 4.3.3. Block Delegation Request Option 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 |No. of Prefixes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix Address Block1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix Address Block2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Arun & Shankar Expires October 30, 2004 [Page 13] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Type 3 for Block Delegation Request Option Length 6 Prefix Length 8-bit unsigned integer. The length of the requested prefix. The value ranges from 0 to 128. It denotes the length of the all the prefixes that would be delegated as a response to this message. A value of 0 notifies the DR to use it's default prefix length. No. of Prefixes 8-bit unsigned integer. The number of prefixes requested by the RR in this message. Reserved 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 1 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix(es) to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have (one of) the associated prefix(es) in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix(es). A value of all one bits (0xffffffff) set in a ack-request message by the RR represents that it is returning the address. Valid Lifetime 2 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix(es) to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have (one of) the associated prefix(es) in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix(es). Valid Lifetime 2 SHOULD be set to a value lesser than Valid Lifetime 1. Valid Lifetime 2 SHOULD be set to zero by the sender and ignored by the receiver if Valid Lifetime 1 is all-zero or all-one. Arun & Shankar Expires October 30, 2004 [Page 14] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 A value of all ones (0xffffffff) SHOULD NOT be set in Valid Lifetime 2 by the sender and SHOULD be ignored by the receiver. Prefix Address Block 1 128-bit field. The start of an address block (inclusive) in the IPv6 address space from where the RR wants its prefix(es). The Prefix Length field contains the number of valid leading bits in the prefix address block. The bits in the prefix address block after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. An RR SHOULD send a prefix option only for globally valid prefixes and a DR SHOULD ignore any other prefix option. Prefix Address Block 2 128-bit field. The end of an address block (inclusive) in the IPv6 address space from where the RR wants its prefix(es). The Prefix Length field contains the number of valid leading bits in the prefix address block. The bits in the prefix address block after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. An RR SHOULD send a prefix option only for globally valid prefixes and a DR SHOULD ignore any other prefix option. Description The RR can use the Block Delegation Request Option to request for an fixed number of prefixes which have an specified prefix length that lie within a block of addresses. It can specify two values as expected valid lifetimes for the DR to choose from. If the RR is not specific about lifetimes, it can set BOTH the fields to zero. A value for infinite valid lifetime MUST be disallowed. The Block Delegation Request option appears in a PD_CPE_REQUEST message. These options MUST be silently ignored for other messages. Arun & Shankar Expires October 30, 2004 [Page 15] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 4.3.4. Individual Prefix Delegation Request Option 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 4 for Individual Prefix Information 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 128. It denotes the length of the all the prefixes included in this message. A value of 0 notifies the DR to use its default prefix length. Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved2 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 1 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have the associated prefix in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix. A value of all one bits (0xffffffff) set in a Arun & Shankar Expires October 30, 2004 [Page 16] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 ack-request message by the RR represents that it is returning the address. Valid Lifetime 2 32-bit unsigned integer. The length of time in seconds (relative to the time the ack is received) that the RR expects the associated prefix to be valid, ie, the time in seconds until which the RR expects the DR to route packets, which have the associated prefix in the destination address, to the RR. A value of all zero bits (0x00000000) set in a request message by the RR represents that it has no preference about the lifetime of the prefix. Valid Lifetime 2 SHOULD be set to a value lesser than Valid Lifetime 1. Valid Lifetime 2 SHOULD be set to zero by the sender and ignored by the receiver if Valid Lifetime 1 is all-zero or all-one. A value of all ones (0xffffffff) SHOULD NOT be set in Valid Lifetime 2 by the sender and SHOULD be ignored by the receiver. Prefix An IP address or 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. A RR SHOULD send a prefix option only for globally valid prefixes and a DR SHOULD ignore any other prefix option. Description The Individual Request Prefix option lets the RR request for multiple prefixes in one single message. It also allows the RR to return or return one or more prefixes. The Individual Request Prefix option appears in a PD_CPE_REQUEST message. These options MUST be silently ignored for other messages. Arun & Shankar Expires October 30, 2004 [Page 17] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 4.3.5. Block Delegation Response Option 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix Address Block1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix Address Block2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 6 for Block Delegation Response Option Length 5 Prefix Length 8-bit unsigned integer. The length of the delegated prefix. The value ranges from 1 to 128. It denotes the length of the all the prefixes that are delegated as a response to this message. Reserved 32-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 ack is received) that the associated prefix is valid, ie, the time in seconds until which the DR would route packets, which have the associated prefix in the destination address, to the RR. A value of all one bits (0xffffffff) set in a response message by the DR represents that it is revoking the address. Arun & Shankar Expires October 30, 2004 [Page 18] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Prefix Address Block 1 128-bit field. The start of an address block (inclusive) in the IPv6 address space from where the DR delegates its prefix(es). The Prefix Length field contains the number of valid leading bits in the prefix address block. The bits in the prefix address block after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. An DR SHOULD delegate the prefix option only for globally valid prefixes and a RR SHOULD ignore any other prefix option. Prefix Address Block 2 128-bit field. The end of an address block (inclusive) in the IPv6 address space from where the DR delegates its prefix(es). The Prefix Length field contains the number of valid leading bits in the prefix address block. The bits in the prefix address block after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. An DR SHOULD delegate the prefix option only for globally valid prefixes and a RR SHOULD ignore any other prefix option. Description The DR can use the Block Delegation Response Option to delegate a fixed number of prefixes which have an arbitrary prefix length that lie within a block of addresses. A value for infinite valid lifetime is disallowed. The Block Delegation Response option appears in a PD_PE_RESPONSE message and PD_CPE_REQUEST message. These options MUST be silently ignored for other messages. 4.3.6. Individual Prefix Delegation Response Option 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arun & Shankar Expires October 30, 2004 [Page 19] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Fields: Type 5 for Individual Prefix Information Length 3 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 1 to 128. It denotes the length of the all the prefixes included in this message. Reserved 6-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 ack is received) that the associated prefix is valid, ie, the time in seconds until which the DR would route packets, which have the associated prefix in the destination address, to the RR. A value of all one bits (0xffffffff) set in a response message by the DR represents that it is revoking the address. Prefix An IP address or 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. A DR SHOULD NOT send a prefix option only for globally valid prefixes and a RR SHOULD ignore any other prefix option. Description The Individual Prefix option lets the DR delegate multiple prefixes to the RR in one single message. It also allows the DR to cancel or revoke one or more prefixes. The Block Delegation Response option appears in a PD_PE_RESPONSE message and PD_CPE_REQUEST message. These options MUST be silently ignored for other messages. 5. Prefix Delegation Mechanism and Overview 5.1 Conceptual Data Structures DRs will need to maintain the following information Arun & Shankar Expires October 30, 2004 [Page 20] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Free Prefix Cache The Free prefix cache would contain the list of available prefixes. For each of the free prefix, the DR can have a minimum and a maximum valid lifetime that it can delegate it for. This would facilitate the DR to allocate set of addresses for dynamic assignments, static assignments and maintain band of such address pools. It should also contain details of acceptable IP addresses for this prefix, last allocated RR's identifier, IP address and state of the prefix. Having the IP address of the RR would also help in handling cases of pre-assigned prefixes. Allocated Prefix Cache The Allocated prefix cache would contain the list of allocated prefixes. For each of the allocated prefixes, the DR can have the request id for this prefix, the identifier of the RR that has been delegated this prefix, the valid lifetime of the prefix and a timer that would clear the prefix from the Allocated prefix cache and return it back to the Free prefix cache. RRs will need to maintain the following information Current Prefix Cache The Current prefix cache would contain the list of all the prefixes that are either requested for or already delegated to the RR, Valid Lifetime(s) for the prefix, state of the prefix. Note that the above conceptual data structures can be implemented using a variety of techniques. One possible implementation is to use a single table for all of the above data structures. Regardless of the specific implementation, it is critical that the data be easily accessible and persistent to avoid any issues that could result due to failures and crashes on the nodes. An implementation is at liberty to implement such data structures in any way it pleases. 5.2 States of Prefixes A Prefix is said to be in one of the following states at any time in the DR's Data Structures. Free The Prefix is available for delegation provided the RR meets other requirements if any. Pending The Prefix has been delegated to a RR and is awaiting a acknowledgement from the RR. Delegated The Prefix has been delegated to a RR and the RR has acknowledged the receipt of this prefix. Deprecated The Prefix has been delegated to and Arun & Shankar Expires October 30, 2004 [Page 21] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 acknowledged by the RR and is due to expire in a specified time (ideally, PDDeprecateTimer). Expired The Prefix has been delegated to and acknowledged by the RR and the valid lifetime has expired. A Prefix is said to be in one of the following states at any time in the RR's Data Structures. Pending The Prefix has been sent as a request to the DR and is awaiting a response from the RR. Delegated The Prefix has been delegated to by the DR and an acknowledgement to the receipt of this prefix has been sent. Deprecated The Prefix has been delegated by and an acknowledgement sent to the DR and is due to expire in a specified time (ideally, PDDeprecateTimer). Expired The Prefix has been delegated by and an acknowledgement sent to the RR and the valid lifetime has expired. 5.3 Conceptual Sending Algorithm A Requesting Router(RR) sends a Prefix Solicitation(PS) message to a Delegating Router(DR) when it finds the needs for delegating prefixes downstream inside the customer environment. It includes all the prefixes that it requires in the PS message using the various options available, viz. Arbitrary Delegation(AD), Block Delegation(BD) and Individual Delegation(ID). If a RR has arranged for pre-assigned prefixes, it would send an empty message to the DR to let it know that he is online and can respond to Response queries with acknowledgements. A DR receives a PS message from a RR and looks up for availability of prefixes. It sends a list of all the available prefixes that suit the RR's requirements, after considering multiple factors like Discretionary setting and the Service-Band of the RR. After sending a reply to the PS using a Prefix Delegation(PD) message, the DR awaits an acknowledgement from the RR to the effect. Only after the acknowledgement from the RR, can the DR start its billing for the delegated prefixes and forwarding of the packets received. If it receives an empty request message, it checks it's data structures to see if there are preassigned prefixes for this RR, and if so, responds with the preassigned prefixes. The RR receives the PD message sent by the DR and checks the prefixes that it has been delegated. It then prepares a PS message with the ack field set and sends it to the DR acknowledging the receipt of the prefixes. The RR can also return prefixes that have Arun & Shankar Expires October 30, 2004 [Page 22] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 been given to it by the DR. When the valid lifetime is about to expire for a given prefix, the RR may choose to renew it with the DR. It sends a PS message to the DR indicating the newer lifetimes that it requires for the given prefixes. When the valid lifetime is about to expire for a given prefix, the DR does not send reminder probes to the RR to that effect. It is the responsibility of the RR to renew a prefix on the event of it expiring. The DR can choose to revoke a set of prefixes that were previously delegated to a RR before they expire. The RR sends a PD message with the list of prefixes that are to be revoked. In such an instance, the DR need not wait for acknowledgement. For example, a DR might choose to revoke a prefix due to complaints of abuse of a certain prefix. The RR can attempt to regain the prefixes by sending a PS message containing the revoked prefixes. 6. Requesting Router Specification A Requesting Router(RR) would be able to send Prefix Solicitation(PS) messages and acknowledged PS messages to a Delegating Router(DR). 6.1 Prefix Solicitation by a Requesting Router A Requesting Router(RR) finds the need for delegating prefixes downstream and sends a Prefix Solicitation(PS) message to the Delegating Router(DR). 6.1.1 Prefix Solicitation Header Specification - RR sets the Type to PD_CPE_REQUEST, Code to zero and the ICMP Checksum as mentioned in [ICMPv6]. - If the RR chooses to allow the DR to use its "discretion" in delegating the prefixes, it sets the Discretion bit to one. Otherwise, it is set to zero. - In a Prefix Solicitation message, the Acknowledgement bit SHOULD be set to zero by the RR. - The RR SHOULD be capable of generating a 16-bit long sequence number. This number should be randomized using a seed and SHOULD be different than any recently generated sequence number on this node. This sequence number SHOULD be set in the Sequence Number field. The node can choose to implement the sequence number generating algorithm in a way that it chooses to be appropriate. - If the RR does not have an agreed service type and is requesting the DR for ANY service type, it sets the Service Type field to zero. If the RR already has an agreed service type, it SHOULD set it in the Service Type field. If the RR wants to change its agreed service type, it SHOULD set the new service type in the Service Type field. - If the RR does not have a unique identifier to identify itself Arun & Shankar Expires October 30, 2004 [Page 23] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 with the DR, it SHOULD set the Identifier field to zero and it SHOULD include the Source Link Layer Address(SLLA) Option. If the RR has an already agreed identifier to identify itself with the DR, it SHOULD set the Identifier field accordingly. - The Reserved field should be initialized to zero. 6.1.2 Prefix Solicitation Option Specification - It includes all the prefixes that it requires in the PS message using the various options available, viz. Arbitrary Delegation(AD), Block Delegation(BD) and Individual Delegation(ID). - If the prefixes are preassigned, no options are included. - If the RR requires a prefix with no particular preference, it adds an AD Request Option to the PS message. The expected length that the prefixes need to have is set in the Prefix Length field. If there is no preference, it is set to zero. The number of arbitrary prefixes with the aforesaid prefix length is set in the No. of Prefixes field. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 1 field. If the RR has no preference in this regard, the Valid Lifetime 1 field is set to zero. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 2 field. If the RR has no preference in this regard, the Valid Lifetime 2 field is set to zero. The Valid Lifetime 2 field SHOULD be set to a value lesser than the value specified in Valid Lifetime 1 field. - If the RR requires a prefix to lie within a particular block of addresses, it adds a BD Request Option to the PS message. The expected length that the prefixes need to have is set in the Prefix Length field. If there is no preference, it is set to zero. The number of prefixes with the aforesaid prefix length is set in the No. of Prefixes field. If it is set to zero, all prefixes within the block need to be delegated. The Reserved field should be set to zero. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 1 field. If the RR has no preference in this regard, the Valid Lifetime 1 field is set to zero. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 2 field. If the RR has no preference in this regard, the Valid Lifetime 2 field is set to zero. The Valid Lifetime 2 field SHOULD be set to a value lesser than the value specified in Valid Lifetime 1 field. The starting point(inclusive) of the address block within which the RR expects the prefixes to be is set in Prefix Address Block 1. The ending point(inclusive) of the address block within which the RR expects the prefixes to be is set in Prefix Address Block 2. - If the RR requires a specified prefix, it adds an ID Request Option to the PS message. The expected length that the prefixes need to have is set in the Prefix Length field. If there is no preference, it is set to zero. The Reserved fields should be set to zero. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 1 field. If the RR has no preference in this Arun & Shankar Expires October 30, 2004 [Page 24] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 regard, the Valid Lifetime 1 field is set to zero. The number of seconds the prefix is expected to be alive is set in the Valid Lifetime 2 field. If the RR has no preference in this regard, the Valid Lifetime 2 field is set to zero. The Valid Lifetime 2 field SHOULD be set to a value lesser than the value specified in Valid Lifetime 1 field. The specific prefix that the RR requires is set in the Prefix field. 6.2 Prefix Delegation Acknowledgement & Returning by a Requesting Router When a DR delegates prefixes, the RR should acknowledge the receipt of the prefixes. The DR would start forwarding packets only after it receives the acknowledgement from the RR. The RR can acknowledge the receipt of the prefixes and also return any of the delegated prefixes using the same Block and Individual Delegation Response options received in the DR's response. A Return could be done as a separate message or it could be piggy-backed with an acknowledgement. If the Returning is done in a separate message, it would require a new sequence number. If the RR intends to use all the prefixes that have been allocated, it SHOULD send a acknowledgement message without options. If it intends to reject a few prefixes, they SHOULD be included as options with all ones (0xffffffff) as Valid Lifetime. 6.2.1 Prefix Delegation Acknowledgement Header Specification - It sets the Type to PD_CPE_REQUEST, Code to zero and the ICMP Checksum as mentioned in [ICMPv6]. - The discretion bit SHOULD be set to zero. - In an Acknowledgement message, the Acknowledgement bit SHOULD be set to one by the RR. - The RR SHOULD use the same sequence number that was used in the original PS message. - The RR SHOULD use the same Service Type field of the PD message to set the Service Type field - The RR SHOULD use the agreed identifier to set the Identifier field. - The Reserved field should be initialized to zero. 6.2.2 Prefix Delegation Acknowledgement Option Specification - Block Delegation Response Option from the PD that is acknowledged is included on return of prefixes. If the RR chooses to return any prefix the valid lifetime field is set to all ones (0xffffffff) to indicate that this block of prefixes is returned. - Individual Delegation Response Option from the PD that is acknowledged is included on return of prefixes. If the RR chooses to return any prefix the valid lifetime field is set to all ones (0xffffffff) to indicate that the individual prefix is returned. 6.3 Prefix Renewal by a Requesting Router Arun & Shankar Expires October 30, 2004 [Page 25] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 - When a prefix reaches Deprecated state, a RR could send renewal messages to DR to extend the Valid Lifetime of the prefix. It could do so using a PS message. The renewal message is treated as a new solicitation message. After sending a PS message, the state of the prefix would be Pending. 6.3.1 Prefix Solicitation Header Specification - It sets the Type to PD_CPE_REQUEST, Code to zero and the ICMP Checksum as mentioned in [ICMPv6]. - If the RR chooses to allow the DR to use its "discretion" in delegating the prefixes, it sets the Discretion bit to one. Otherwise, it is set to zero. - In a Prefix Solicitation message, the Acknowledgement bit SHOULD be set to zero by the RR. - The RR SHOULD be capable of generating a 16-bit long sequence number. This number should be randomised using a seed and SHOULD be different than any recently generated sequence number on this node. This sequence number SHOULD be set in the Sequence Number field. The node can choose to implement the sequence number generating algorithm in a way that it chooses to be appropriate. - If the RR does not have an agreed service type and is requesting the DR for ANY service type, it sets the Service Type field to zero. If the RR already has an agreed service type, it SHOULD set it in the Service Type field. If the RR wants to change its agreed service type, it SHOULD set the new service type in the Service Type field. - The RR's unique identifier should be used to set the Identifier field. - The Reserved field should be initialized to zero. 6.3.2 Prefix Solicitation Option Specification - It includes all the prefixes that it requires to be renewed in the PS message using Block Delegation(BD) and Individual Delegation(ID). Arbitrary Delegation cannot be used since only well-specified prefixes can be renewed. - If the RR requires a block of continuos prefixes to be renewed, it adds a BD Request Option to the PS message. The length of the prefixes is set in the Prefix Length field. The number of block prefixes which are to be renewed is set in the No. of Prefixes field. If it is set to zero, all the prefixes within the block need to be renewed. The Reserved field should be set to zero. The number of seconds the prefix is expected to be renewed is set in the Valid Lifetime 1 field. If the RR has no preference in this regard, the Valid Lifetime 1 field is set to zero. The number of seconds the prefix is expected to be renewed is set in the Valid Lifetime 2 field. If the RR has no preference in this regard, the Valid Lifetime 2 field is set to zero. The Valid Lifetime 2 field SHOULD be set to a value lesser than the value specified in Valid Lifetime 1 field. The starting point(inclusive) of the address block within which Arun & Shankar Expires October 30, 2004 [Page 26] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 the prefixes are is set in Prefix Address Block 1. The ending point(inclusinve) of the address block within which the the prefixes are is set in Prefix Address Block 2. - If the RR requires to renew a specified prefix, it adds an ID Request Option to the PS message. The length of the renewing prefix is set in the Prefix Length field. The Reserved fields should be set to zero. The number of seconds the prefix is expected to be renewed is set in the Valid Lifetime 1 field. If the RR has no preference in this regard, the Valid Lifetime 1 field is set to zero. The number of seconds the prefix is expected to be renewed is set in the Valid Lifetime 2 field. If the RR has no preference in this regard, the Valid Lifetime 2 field is set to zero. The Valid Lifetime 2 field SHOULD be set to a value lesser than the value specified in Valid Lifetime 1 field. The specific prefix that the RR requires is set in the Prefix field. 6.4 Prefix Delegation Message Validation by Requesting Router A RR receives Prefix Delegation(PD) messages from the DR in response to it's PS message. 6.4.1 Prefix Delegation Header Validation - Verify if Type is PD_PE_RESPONSE, Code is Zero and ICMPv6 Checksum field is correct. If not, silently ignore the message. - If ACK field is set, ensure a solicited message with the corresponding Sequence Number is available in the Data Structures with prefix state Pending. If ACK field is not set, ensure a solicited message with the corresponding Sequence Number is available in the Data Structures with prefix state anything other than Pending. If not, silently ignore the message. - If the Sequence Number field is zero, it denotes a case of pre-assignment of prefixes. Otherwise, check if prefixes with Pending state match the Sequence Number. If they do not match, silently ignore the message. - Set Service field in the data structure to Service field in the PD header. This would be the new service band for the RR. - If the Identifier field is zero, the message should be silently ignored. If the Identifier value in the local data structure is zero, set the value in the Identifier field of the message. This SHOULD be used in all future communications. Otherwise, it should be checked and if it does not match, the message should be silently ignored. - The Reserved field should be ignored. 6.4.2 Prefix Delegation Option Validation - If the Discretion flag was not set, check if all the prefixes requested are provided with requested Valid Lifetimes. If not, silently ignore the message. Arun & Shankar Expires October 30, 2004 [Page 27] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 - If the Discretion flag was set, process each option individually. - If the options are empty, check if there are any preassigned prefixes awaiting acknowledgement for this RR. If not, silently ignore the message. - If a prefix is not in Pending state, Return the prefix. - Move the prefixes from the Pending state to Delegated State - If the Valid Lifetimes are all-zeroes, ignore the prefix 6.5 Configurable Parameters for Requesting Router PDCPEMaxRetries The number of retries the RR has to perform before it gets a reply to its solicitation. PDCPEMaxPrefixes Maximum number of prefixes that could be requested by a RR at its next request. It depends on the type of service that the RR enjoys. PDCPEDynamicThreshold The threshold value which is used to determine if a prefix is static or a dynamic prefix. This can be used when the RR wishes to request for static or a dynamic prefix. PDCPEDeprecateTimer The value in seconds for which a prefix would remain deprecated. When there are PDCPEDeprecateTimer seconds for the Valid Lifetime to expire, the RR can start sending renewal requests for the prefix. PDCPERetransTimer The value in seconds between two retries. PDCPEReplayTimer The value in seconds after a which a RR allows an old sequence number to be accepted as a valid sequence number and not reject it as a replay. 7. Delegating Router Specification A Delegating Router(DR) would send Prefix Delegation(PD) messages to a Requesting Router(RR). 7.1 Prefix Delegation by a Delegating Router A Delegating Router(DR) responds to a Prefix Solicitation(PS) message from a RR with a PD message. 7.1.1 Prefix Delegation Header Specification - If the Discretion bit was not set, and all prefixes with requested valid lifetimes are not available, silently ignore the message. - Set Type to PD_PE_RESPONSE, Code to zero and Checksum a mentioned in [ICMPv6]. - If the message is an acknowledgement to a previously received PS Arun & Shankar Expires October 30, 2004 [Page 28] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 message, set the ACK bit to one. Otherwise, set the ACK bit to zero. - If it is a case of pre-assignment of prefixes, set the Sequence Number field to zero. Otherwise, set it to the value from the previously received PS message. - Set the Service field to either the current or updated Service band of the RR - If the Identifier field is non-zero, Set the Identifier field to the same value. Otherwise, set it to the newly arrived Identifier value. - The Reserved field should be to set to zero. 7.1.2 Prefix Delegation Option Specification - If Addresses could be allocated in a block, use Block Delegation Response Option. Set the Prefix Length field to the prefix length that is common to all the prefixes in the block. Set the starting address of the prefix block (inclusive) in Prefix Address Block 1 and the ending address of the prefix block (inclusive) in Prefix Address Block 2. Set the Valid Lifetime field to the applicable value. - If Addresses could not be allocated in a block, use Individual Delegation Response Option. Set the Prefix Length field to the prefix length of the prefix and load the prefix in the Prefix field. Set the Valid Lifetime field to the applicable value. 7.2 Prefix Revoking by a Delegating Router A DR can revoke the prefixes that it had delegated using a PS message. This SHOULD NOT be piggy-backed with a current delegation response and SHOULD be sent only as a standalone message. 7.2.1 Prefix Revoking Header Specification - Set Type to PD_PE_RESPONSE, Code to zero and Checksum a mentioned in [ICMPv6]. - Set the ACK bit to zero, since this is not an acknowledgement. - If it is a case of pre-assignment of prefixes, set the Sequence Number field to zero. Otherwise, set it to the value from the previously received PS message which performed the delegation. - Set the Service field to either the current Service band of the RR - Set the Identifier field to the value of the RR. - The Reserved field should be to set to zero. 7.2.2 Prefix Delegation Option Specification - If Addresses could be revoked in a block, use Block Delegation Response Option. Set the Prefix Length field to the prefix length that is common to all the prefixes in the block. Set the starting address of the prefix block (inclusive) in Prefix Address Block 1 and the ending address of the prefix block (inclusive) in Prefix Address Block 2. Set the Valid Lifetime field to all ones (0xffffffff). Arun & Shankar Expires October 30, 2004 [Page 29] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 - If Addresses could not be revoked in a block, use Individual Delegation Response Option. Set the Prefix Length field to the prefix length of the prefix and load the prefix in the Prefix field. Set the Valid Lifetime field to all ones (0xffffffff). 7.3 Prefix Solicitation Message Validation by Delegating Router A DR receives PS messages from RRs which require prefixes. 7.3.1 Prefix Solicitation Header Validation - Verify if Type is PD_CPE_REQUEST, Code is zero and Checksum is correct. If not, silently ignore the message. - If the ACK flag is set, the RR is acknowledging a previous PD message. If the ACK flag is not set, the RR is making a fresh request. - If the Discretion flag is set alongside the ACK flag, ignore the message. Otherwise, ensure that all prefixes are available with appropriate Valid Lifetimes. If prefixes are not available, silently ignore the message. - If the Sequence Number field is zero and the Ack flag is not set, silently ignore the message. - If the Service field is zero, assign a new Service band for the RR. If the Service field is different, assign the new Service band if it meets the policy guidelines, if any. - If the Identifier field is zero, check for SLLA option. If not found, silently ignore the message. If found, use it in a implementation-dependent hash algorithm to generate a 32-bit identifier for the RR. - Ignore the Reserved bits. 7.3.2 Prefix Solicitation Options Validation - If ACK flag is set and there are no options, all the prefixes that were allocated in the message with the appropriate Sequence Number are acknowledged by the RR. If ACK flag is not set and there are no options, check for a case of Pre-assigned prefixes. - If Identifier field is non-zero, ignore the SLLA option. - For all kinds of prefixes solicited, check if such a prefix is in the Free state. If not, ignore the Prefix. - If Prefix Length is set to zero in the solicitation message, the default prefix value is taken. - For all available prefixes, check if Valid Lifetime 1 option is zero. If so, Ignore the Valid Lifetime 2 option and delegate the prefix with Valid Lifetime depending on the Service Band of the Arun & Shankar Expires October 30, 2004 [Page 30] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 Customer. Ignore the prefix if Ack bit is zero and Valid Lifetime is all-ones (0xffffffff). If Ack bit is one and Valid Lifetime is all-ones (0xffffffff), set the entry to Expire in the table and ignore the Valid Lifetime 2 option. - If Valid Lifetime 1 is non-zero and not all-ones, Check Valid Lifetime 2 to see minimum and maximum values for Valid Lifetime. If such a prefix matches, delegate it with Valid Lifetime based on the Service Band of the customer. Otherwise, ignore the prefix. - Once a prefix is delegated, Mark it as Pending. After receiving the Ack, set it to Delegated. 7.4 Configurable Parameters for Delegating Router PDPEMaxRetries The number of retries the DR has to perform before it gets an Ack to its PD message. PDPEMaxPrefixes Maximum number of prefixes that could be delegated by a DR at its next request. It depends on the type of service that the RR enjoys. PDPEDynamicThreshold The threshold value which is used to determine if a prefix is static or a dynamic prefix. This can be used when the DR wishes to allocate for a static or a dynamic prefix. PDPEDeprecateTimer The value in seconds for which a prefix would remain deprecated. When there are PDPEDeprecateTimer seconds for the Valid Lifetime to expire, the RR can start expecting renewal requests for the prefix. PDPERetransTimer The value in seconds between two retries. PDPEExpireTimer The value in seconds when the DR decides that the prefix can be freed after having expired earlier. PDPEDefaultPrefixLength The default prefix length to be chosen by the PE if the RR does not have any preference on the prefix length. PDPEReplayTimer The value in seconds after a which a DR allows an old sequence number to be accepted as a valid sequence number and not reject it as a replay. 8. IANA Considerations IANA is requested to assign an option code to the following options Arun & Shankar Expires October 30, 2004 [Page 31] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 from the option-code space for ICMPv6 [ICMPv6]. Option Name Value Described in PD_CPE_SOLICIT tbd Section 4 PD_PE_RESPONSE tbd Section 4 9. Security Considerations For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, authentication may not be necessary. On other links, Security considerations like man in the middle exist. 10. Normative References [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 [IPv6-ADDR] Deering, S., Hinden, R., "IP Version 6 Addressing Architecture", Work in Progress, December 1998 [ICMPv6] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", Work in Progress, February 2004 [PDReq] Miyakawa, S., Droms, R., "Requirements for IPv6 prefix delegation", Work in Progress, February 2004 [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, March 1997. [IPv6-DISC] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December, 1998. [ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [IPv6-AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [IPv6-ESP] Kent, S., R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Arun & Shankar Expires October 30, 2004 [Page 32] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 11. Authors' Addresses Arun Thulasi Shankar Raman Hewlett-Packard, Hewlett-Packard, 29, Cunningham Road, 29, Cunningham Road, Bangalore - 560052 Bangalore - 560052 India. India. arun_thulasi@hp.com shankar_r@hp.com Appendix A : Usage of Service Bands & Discretion Flag Service Bands can be used for various reasons. A DR can use a Service Band to distinguish between various customers. The number of prefixes that would be delegated to a RR, the Lifetimes of those prefixes, Revoking of prefixes and Renewal of prefixes could be streamlines using Service Bands. For example, a customer with a certain Service Band could be allowed more renewals than a customer with a lower Service Band. Service Bands serve as an important tool for the DR to apply policy based delegation. At the time of specifying this mechanism, the DR is eligible to define it's own service bands. Further discussions may result in well known Service Bands being identified. The Discretion bit is aimed to allow complete freedom on the part of the DR, provided the RR is okay with it. In cases, where the RR wishes to check if this DR has a certain prefix that it requires, it can send a PS message with the prefixes and the Discretion bit unset. It also helps in cases when the RR is specific about having certain Valid Lifetimes for the prefixes that it requires. In such cases, the RR can unset the Discretion bit to let the DR know that it should not apply it's discretion while delegating the prefixes. If the Discretion bit is set, it also allows the DR to exercise its discretion on Valid Lifetimes and Block of Prefixes. Appendix B : Implementation Suggestions on Usage of Prefix States The Deprecated State can be used as a method to block flood of renewal messages. Unless the Prefix passes on to Deprecated State, renewal messages would not be entertained and would be silently ignored. This could help in preventing a DOS attack using Renewal Messages. Appendix C : Future Options Future options could be added to share other information between RRs and DRs. Some of the options that have been considered at the time of specifying this mechanism are - Synchronizing Global values between RR and DR Arun & Shankar Expires October 30, 2004 [Page 33] Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004 This would help in the RR and DR knowing information about each other. - Accounting Information Requests from DR to RR If the DR wishes to have accounting information on the usage of prefixes, these requests would help in it. - Current Status of a Prefix from RR to DR At times, a RR might want to get details about the prefixes that it has been allocated with. It could use this option to query the Current State and Status of the prefix. - Reservation of a prefix by the RR with the DR The RR might want to reserve a prefix with the DR which it would start using after a specified amount of time. The Reservation Option would facilitate this. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 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. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Arun & Shankar Expires October 30, 2004 [Page 34]