Network Working Group S. Rao Internet-Draft Motorola Intended status: Standards Track T. Enos Expires: August 20, 2007 CI Software S. Madanapalli LogicaCMG A. Thulasi Hewlett Packard February 16, 2007 IPv6 Prefix Delegation using ICMPv6 draft-rao-ipv6-prefix-delegation-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The currently proposed solution for IPv6 Prefix Delegation is based on DHCPv6 protocol. We believe that in certain network topologies and configurations where the CPE routers may not be capable or Rao, et al. Expires August 20, 2007 [Page 1] Internet-Draft IPv6 Prefix Delegation February 2007 configured to use DHCPv6 and hence can not utilize the currently proposed DHCPv6 based ipv6 prefix delegation procedure. Therefore an alternate ipv6 prefix delegation procedure that does not require or depend on the DHCPv6 protocol is needed. This document proposes an ICMPv6 based prefix delegation (PD) mechanism which is in conformance with RFC 3769 that describes the requirements for IPv6 prefix delegation. This proposal involves using the Router Solicitation (RS) message for the prefix request and the Router Advertisement(RA) message for the prefix delegation. A new flag called P-flag (bit 0 of the reserved field) is defined to indicate that the RS message includes a PD request. RS messages with PD request can now include PIO option(s) to carry PD information such as prefix preference(s) or PD parameters such as lease etc. It also proposes defining a new flag called D-flag (reserved bit 26) of the PIO option to indicate the presence of PD specific PIO in RS and RA messages. Rao, et al. Expires August 20, 2007 [Page 2] Internet-Draft IPv6 Prefix Delegation February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation for ICMPv6 based Prefix Delegation . . . . . . . . 5 4. ICMPv6 based Prefix Delegation procedure . . . . . . . . . . . 5 4.1. Modified Message Formats . . . . . . . . . . . . . . . . . 7 4.1.1. Router Solicitation Message Format . . . . . . . . . . 7 4.1.2. PIO Option Format . . . . . . . . . . . . . . . . . . 8 4.2. Message Processing . . . . . . . . . . . . . . . . . . . . 9 4.2.1. RS Message Processing . . . . . . . . . . . . . . . . 9 4.2.2. RA Message Processing . . . . . . . . . . . . . . . . 9 5. Error Handling and Notifications . . . . . . . . . . . . . . . 10 5.1. Error Messages . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Notification Messages . . . . . . . . . . . . . . . . . . 12 6. Configuration Variables . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Rao, et al. Expires August 20, 2007 [Page 3] Internet-Draft IPv6 Prefix Delegation February 2007 1. Introduction [1] defines neighbor discovery procedures for IPv6 for router discovery, prefix discovery, address resolution, neighbor unreachability detection and parameter discovery. It also defines the format for the Router Solicitation (RS) and the Router Advertisement (RA) messages. [2] describes the Prefix Delegation procedure and options to be used for Prefix Delegation process using DHCPv6 protocol. This document describes IPv6 Prefix delegation mechanism based on the ICMPv6 protocol that is used for ND process also. This proposal is in conformance with the RFC 3769 which describes the requirements for IPv6 Prefix Delegation. This proposal is intended for delegation of prefixes from a delegating router (DR) to a requesting node (RN). It is also agnostic to the way prefixes are provisioned or managed at the delegating Router (DR) or at the requesting node (RN). The IPv6 PD mechanism described in this draft is appropriate for all the situations for which RFC3633 is appropriate. But it works without requiring DHCP client / server components on the requesting routers such as CPE routers. ICMPv6 based PD mechanism is applicable to several different scenarios where IPv6 PD is required but DHCPv6 is not. Neighbor Discovery (ND), SLAAC and ICMPv6 are all integral part of the IPv6 stack and hence the proposed mechanism for Prefix Delegation does not require any additional components or applications on either the requester or the delegator for prefix delegation purposes. ICMPv6 based PD as proposed in this document does not conflict with the DHCPv6 based approach as defined in the RFC 3633. In fact, both mechanisms can co-exist and are not mutually exclusive. While the basic prefix delegation mechanism described in this document is different from the DHCPv6 based mechanism, the model and the concepts of the IPv6 prefix delegation remain the same. 2. Terminology This document uses some of the terminology defined in IPv6 Neighbor Discovery RFC 2461 and RFC 3769. In addition, this document uses the following definitions: a. Requesting Node (RN): a host or a router that is requesting prefix(es) to be delegated from an upstream router Rao, et al. Expires August 20, 2007 [Page 4] Internet-Draft IPv6 Prefix Delegation February 2007 b. Delegating Router (DR): The router delegating prefix(es) to one of its downstream requesting nodes c. P-Flag: A flag indicating that sender of the RS message is requesting PD. This document proposes to use bit 0 of the reserved field of the RS message. d. D-Flag: A flag indicating that the RS and / or RA messages PIO option contains prefix request or delegation. This document proposes to use bit 26 of the PIO option (a reserved bit) 3. Motivation for ICMPv6 based Prefix Delegation The following list summarizes the motivation for this proposal: DHCPv6 based Prefix Delegation may not work in all situations such as Stateless Automatic Address Configuration where the client routers may not have DHCPv6 components deployed or enabled. Also there are certain access technology deployments where CPE routers are not DHCP enabled. Therefore, there is a need for non-DHCP based ipv6 prefix delegation mechanism. In situations such as mobile networks, Mobile Routers (MR) can take advantage of the ICMPv6 based prefix delegation procedure if DHCPv6 based approach neither available nor enabled in the Mobile Routers. Additionally, there has been some customer feedback and requests for a non-dhcp based prefix delegation in the ISP space based on the complexity of the DHCPv6 based approach. The simplicity of the proposed solution and its potential applicability for an automatic hierarchical PD procedure that can be made to work recursively is very attractive as it aligns well with the design principles of SLAAC. 4. ICMPv6 based Prefix Delegation procedure Though the basic mechanism proposed for prefix delegation is different from the DHCPv6 based mechanism, the requirements, model and concepts of IPv6 prefix delegation as defined in RFC 3633 and RFC 3769, still remains the same. RFC 2461 defines ICMPv6 based ND procedure, as well as the message formats such as Router Solicitation (RS) message, Router Advertisement (RA) message and options such as Prefix Information Rao, et al. Expires August 20, 2007 [Page 5] Internet-Draft IPv6 Prefix Delegation February 2007 Option (PIO). In general, Router Advertisements and per-prefix flags allow recipients how the address configuration is performed (Stateful and / or stateless). This specification proposes modifications to these ND messages and the PIO option; each will be considered in turn. Additionally, a Requesting Router (RR) can use the modified RS message to specify its preferences to the DR. In order for a RN (Requesting Node; aka CE) to independently request IPv6 prefix delegation, RS message is modified as follows: a. A new flag (P-flag) is defined to indicate that RS message includes a PD request. b. In order for the requesting node (RN) to be able to inform the delegating router (DR) of its PD preference(s) for prefix(es) and / or parameters, RS message will be allowed to carry PIO options(s). PD request without any preferences will have just the P-flag set to 1 and does not include any PIO option(s). A new flag (D-flag) is defined in the PIO option to indicate the presence of prefix(es) delegated in the RA message containing the PIO option(s). Since the format of the PIO option is common for both the RS and the RA messages, if the RS message has the P-flag set, then setting D-flag in the PIO option(s) that are included in the RS message for indicating preferences is irrelevant. The information contained in each accompanying PIO is understood to be preferred prefix / parameter(s). IPv6 ND procedure as defined by RFC 2461 allows PIO option to be present only in the RA messages. In order for a RN (Requesting Node; aka CE) to independently request an IPv6 prefix delegation, this document proposes a change to that policy and modifies the RS messages with P-flag set, to carry the PIO option(s). Setting D-flag in those PIO option(s) is irrelevant and as such the nodes receiving and processing the RS message with p-flag set need not check for the D-flag bit to be set to 1. RS Messages with P-flag set but do not include any PIO options are to be processed as PD requests without any preferences. All RS messages that do not have P-flag set SHOULD be processed as per RFC 2461. RA messages containing PIO option(s) without the D-bit set MUST be treated as the normal prefix(es) for on-link and SLAAC and SHOULD be processed as per the RFC 2461. RA messages containing PIO option(s) with D-bit set MUST be treated as the delegation of prefix(es) to the receiving node and SHOULD be processed as per this document. Rao, et al. Expires August 20, 2007 [Page 6] Internet-Draft IPv6 Prefix Delegation February 2007 There may be cases where more than one DR is present on the link shared with the RN. In cases such as this, the RN will choose as its DR the PD capable router whose solicited RA it received first. Subsequent RAs received from the remaining on-link PD-capable routers will be ignored. 4.1. Modified Message Formats 4.1.1. Router Solicitation Message Format RNs send RS messages for requesting prefix delegation besides ND reasons. Modified RS Message format is shown below: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+- ICMP Fields: Type: 133 (8 bits, RS Message) Code: 0 (8 bits) Checksum: 16-bits. ICMP checksum. See ICMPv6 specification. P: PD Request Flag. 1-bit. Reserved: 31 bits - unused. MUST be initialized to zeros by the sender and MUST be ignored by the receiver. Valid Options: Variable number of options. Besides Source Link- layer Address option, PIO option can also be included with the RS message to indicate the PD Request preference(s). Receivers MUST silently ignore any options they do not recognize and continue processing the message. Rao, et al. Expires August 20, 2007 [Page 7] Internet-Draft IPv6 Prefix Delegation February 2007 4.1.2. PIO Option Format As per RFC2461, ND messages include zero or more options, some of which may appear multiple times in the same message. Prefix Information Option type is 3 and is also described in RFC2461. Modified PIO option format is shown below, which defines a new flag called D-Flag (Delegation Flag) (bit 26 of the PIO option) to be used by the ICMPv6 based prefix delegation mechanism. 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 |L|A|D|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIO Option Fields: Type: 3 (PIO option) Length: 4 (Total length of the PIO option - units of 8 byte octets) Prefix Length: 8-bit unsigned integer. L: 1-bit on-link flag A: 1-bit autonomous address configuration flag D: 1-bit delegation flag: If it is set in RS message it denotes prefix request and if set in a RA message it denotes prefix delegation. Rao, et al. Expires August 20, 2007 [Page 8] Internet-Draft IPv6 Prefix Delegation February 2007 Reserved1: 5 bits - unused. MUST be initialized to zeros by the sender and MUST be ignored by the receiver. Valid Lifetime: 32 bit unsigned integer. refer to RFC 2461. Preferred Lifetime: 32 bit unsigned integer. refer to RFC 2461. Reserved2: unused. MUST be initialized to zeros by the sender and MUST be ignored by the receiver. Prefix: IP address or prefix of an IP address. Prefix Length field contains the number of valid leading bits in the prefix. Bits in the prefix after prefix length MUST be treated as reserved bits and MUST be ignored by the receiver and MUST be set to zero by the sender. 4.2. Message Processing 4.2.1. RS Message Processing The logic below describes the way the RS messages is to be processed by the receivers. If (P-Flag is set in RS) { if (PIOs present) { for (each PIO) { process the PIO as PD request with preferences. do not care D-Flag. } } else { process as PD Request without preferences } } else { (P-Flag is not set) process as per RFC 2461 (not PD specific). } 4.2.2. RA Message Processing The logic below describes the way the RA messages is to be processed by the receivers. Rao, et al. Expires August 20, 2007 [Page 9] Internet-Draft IPv6 Prefix Delegation February 2007 If ( PIOs present) { for (each PIO) { if (D-Flag is set) { It is a PD delegation PIO. process the PIO as PD delegation. } else { process as per rfc 2461 (not PD specific) } } } 5. Error Handling and Notifications The PD mechanism should be capable of reporting error and informational messages between the RN and the DR. ICMPv6 messages would be used for this purpose. 5.1. Error Messages Error Messages are exchanged between the RN and DR to report critical issues that would need to be addressed by either end for the delegation process to complete successfully. The Type field for such ICMPv6 message types would be taken from the same value space given to ICMPv6 error messages (0 - 127). The error message sent in response to PD RS / RA messages SHOULD contain the original request that triggered it, as part of the error message. This would enable the receiving node to log appropriate error messages with sufficient details. The following error messages need to be considered: 1. Unavailable Prefix This message is sent by the DR to the RN to express it's inability to allocate a prefix requested by the RN. This error message could be sent by the DR if * the prefix has already been delegated to another RN * the prefix is not available for the DR to delegate * the RN is not eligible to request this prefix due to policies * the other requirements specified by the RN in it's request message cannot be met * the prefix cannot be renewed Rao, et al. Expires August 20, 2007 [Page 10] Internet-Draft IPv6 Prefix Delegation February 2007 This error message is always sent in response to a RS message requesting prefix delegation. ICMP code field can be used to indicate the specific cause of the failure. If the RN receives the error message indicating that requested prefix is delegated to another RN, it SHOULD log the message and SHOULD not request the same prefix immediately. If the RN receives an error message indicating the prefix is not available for the DR to delegate, it SHOULD log the message and SHOULD never request the same prefix. If the RN receives an error message indicating the prefix is not available due to the DR's policies or due to a failure in meeting any requirements specified by the RN in it's request message, it could change the requirements and re-send the request. The error message sent by the DR may contain information indicating possible parameters for the subsequent PD request message to be sent by the RN. If the RN receives an error message indicating the prefix cannot be renewed, it should log the message and can request another prefix. 2. Duplicate Prefix This message is sent by the DR to the RN to suggest that the requested prefix has already been allocated to the RN. This message is sent by the DR if it receives a PD RS from the RN for the same prefixes too soon. The DR might consider this as a indication that the RA containing the prefix options was not received by the RN. On receipt of a Duplicate Prefix error message from the DR, the RN can start using the prefix requested. The lifetime fields should be considered valid from the time of the original request. If the RN had not made a request for the prefix, it must silently discard the message. 3. Revoked Prefix This message is sent by the DR to the RN to suggest that an already allocated prefix has now been revoked and the RN MAY NOT continue to use it. Typically, this occurs when there is a renumbering done by the DR and it's originally assigned set of prefixes. This message is not generated in response to any Rao, et al. Expires August 20, 2007 [Page 11] Internet-Draft IPv6 Prefix Delegation February 2007 RS message unlike the Unavailable Prefix error message. On receipt of a Revoked Prefix error message from the DR, the RN SHOULD immediately stop using the prefix. If the Revoked Prefix was never requested or allocated to the RN, the message MUST be silently discarded. 5.2. Notification Messages Type values for these messages fall between 128 - 255 as per rfc 2463. The following informational messages are defined for the prefix delegation mechanism. Returned Prefix This message is sent by the RN to the DR to suggest that it does not require the prefix any more. The DR would then be able to add this prefix to it's existing pool and delegate it to other RNs if possible. This message may or may not be sent as a response to a RA message delegating prefixes. This message MUST contain the prefix(es) returned using the PIO option format so that the DR can free up the allocation of appropriate prefixes. If the DR has not delegated the prefix(es) being returned, it MUST silently discard the message. Any other messages should be processed as per ICMPv6 specification. 6. Configuration Variables The following Variables need to be considered 1. MinPDMsgTxInterval The MinPDMsgTxInterval variable defines the time between two successive PD error/informational messages sent by one node to another. The node has to wait for MinPDMsgTxInterval before re-transmitting a message. ND Configuration Variables such as RTR_SOLICITATION_INTERVAL and MAX_ROUTER_SOLICITATIONS etc. (defined in RFC 2461) SHOULD be honored Rao, et al. Expires August 20, 2007 [Page 12] Internet-Draft IPv6 Prefix Delegation February 2007 by this prefix delegation procedure for the purpose of rate limitting the RS and RA messages. 7. Security Considerations This document specifies a few amendments to the [1] and does not introduce any new security threats. To reduce the threats associated with ND it is recommended that deployments use SeND [3] to secure neighbor discovery messages. 8. IANA Considerations This document defines new ICMPv6 message types in Sections 5.1 and 5.2 which requires IANA to assign codes for these new ICMPv6 messages. 9. Acknowledgements TBD 10. References [1] "Neighbor Discovery for IP version 6 (IPv6), draft-ietf-ipv6-2461bis-07.txt(work in progress)", May 2006. [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [4] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. Rao, et al. Expires August 20, 2007 [Page 13] Internet-Draft IPv6 Prefix Delegation February 2007 Authors' Addresses Satya Rao Motorola 6500 River Place Blvd, Building 7 Austin, TX 78730 USA Email: sbrao@motorola.com Tim Enos CI Software 100 Cummings Center Suite 127A Beverly, MA 01915 USA Email: timbeck04@verizon.net Syam Madanapalli LogicaCMG 125 Yemlur Main Road Off Airport Road Bangalore 560037 India Email: smadanapalli at gmail dot com Arun Thulasi Hewlett Packard 29 Cunningham Road Bangalore 560052 India Email: arun_thulasi@hp.com Rao, et al. Expires August 20, 2007 [Page 14] Internet-Draft IPv6 Prefix Delegation February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Rao, et al. Expires August 20, 2007 [Page 15]