Network Working Group A. Kaiser Internet-Draft S. Decremps Intended status: Experimental N. Oualha Expires: August 29, 2013 A. Petrescu CEA February 25, 2013 Prefix Delegation extension to Neighbor Discovery protocol draft-kaiser-nd-pd-01 Abstract This document describes an extension to the Neighbor Discovery protocol (ND). The proposed extension enhances ND by providing it with a new option: the Prefix Delegation option (ND-PD). ND-PD offers the possibility for routers on a same link to ask for or delegate IPv6 prefixes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Kaiser, et al. Expires August 29, 2013 [Page 1] Internet-Draft ND-PD February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and motivations . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Related works . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Use case example: V2V2I . . . . . . . . . . . . . . . . . . . 7 6. Format of the Prefix Delegation option . . . . . . . . . . . . 9 6.1. Format of the Prefix Information . . . . . . . . . . . . . 10 7. Operations details . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Requesting and delegating prefixes . . . . . . . . . . . . 12 7.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Renewing prefixes . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Releasing prefixes . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15 7.3.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. Prefixes synchronization and error detection . . . . . . . 16 8. Local operations on requesting and delegating routers . . . . 18 8.1. Delegated prefixes handling . . . . . . . . . . . . . . . 18 8.2. Delegating router behaviour . . . . . . . . . . . . . . . 18 8.2.1. Checking the validity of the PD option . . . . . . . . 18 8.2.2. Checking the synchronization of the DPDB . . . . . . . 19 8.2.3. Processing the operations . . . . . . . . . . . . . . 19 8.3. Requesting router behaviour . . . . . . . . . . . . . . . 20 8.3.1. Checking the validity of the PD option . . . . . . . . 20 8.3.2. Checking the synchronization of the messages exchange . . . . . . . . . . . . . . . . . . . . . . . 20 8.3.3. Processing the operations . . . . . . . . . . . . . . 20 9. Advertising the ND-PD service . . . . . . . . . . . . . . . . 21 10. Messages exchange diagram . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Kaiser, et al. Expires August 29, 2013 [Page 2] Internet-Draft ND-PD February 2013 1. Introduction and motivations This document describes a new option that extends ND with a PD mechanism. Using this mechanism, a requesting router can ask for a global IPv6 prefix to a delegating router that is present on the same link. The proposed ND-PD mechanism reaches the same objectives as the DHCPv6-PD mechanism described in [DHCPV6_PD], but in a faster and less ressources consuming way. The proposed ND-PD has been initially thought and designed for highly mobile networks such as vehicular networks, where opportunities for communicating may be quite short. Therefore, the less signaling messages are required to auto-configure mobile nodes, the more time can be exploited by applications during these short communication windows. Moreover, the default availability of the ND protocol in any IPv6 stack makes it a strong candidate to handle the PD service rather than implementing an additionnal software, especially in hardware and ressources constrained devices like sensors or on-board devices. Kaiser, et al. Expires August 29, 2013 [Page 3] Internet-Draft ND-PD February 2013 2. Terminology This document uses the terminology defined in [DHCPV6_PD], [NEIGHDISC], and [SLAAC]. Also the following additionnal terms are used: Requesting router: A router that is asking for prefixes to be delegated. Delegating router: A router that provides prefixes to requesting routers. Prefix Information: A logical structure that stores all informations related to a specific prefix. DPDB: The Delegated Prefixes DataBase (DPDB) is a logical structure that stores all prefixes that have been delegated from a specific delegating router along with other informations related to this delegating router. One DPDB MUST be created on both the requesting and the delegating routers sides for each requesting/delegating routers tuple (see Section 8.1 for more details). Kaiser, et al. Expires August 29, 2013 [Page 4] Internet-Draft ND-PD February 2013 3. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. Kaiser, et al. Expires August 29, 2013 [Page 5] Internet-Draft ND-PD February 2013 4. Related works A few drafts about providing a PD mechanism to the ND protocol have already been proposed in the past. In [DRAFT_LUTCHANSKY] the author proposes to add a PD option to the Router Solicitation (RS) and Router Advertisement (RA) messages generated by routers. A router that needs a global prefix can ask for one by including a PD option in a RS message. Then, a router that owns prefixes for delegation replies to the request with a RA that includes a PD option. The main advantage of this proposal is that it is very simple and does not require any additionnal message to work. However it lacks of completeness: the handling as well as the renewing and releasing of the delegated prefixes are not taken into consideration. In [DRAFT_HABERMAN] a more complete PD mechanism for ND protocol is proposed. The mechanism is based on two new ICMP messages: the Prefix Request and the Prefix Delegation. The former is used by a requesting router to ask for a prefix. Conversely, the latter is used by a delegating router to reply to the request. The proposal also includes the possibility for a requesting router to renew a delegated prefix that has not expired yet and to return a delegated prefix that is no longer required. The proposed ND-PD mechanism that is described in this document is close to the one described in [DRAFT_HABERMAN]. However, our mechanism relies on the creation of new RS/RA options rather than the creation of new ICMP messages. Also, the ND-PD service provided by a router is advertised using the RA flags option [RAFLAGS]. This information enable requesting routers to be aware of the presence of routers that provide the ND-PD service on link without firstly asking for it. Kaiser, et al. Expires August 29, 2013 [Page 6] Internet-Draft ND-PD February 2013 5. Use case example: V2V2I Figure 1 shows a vehicular scenario. Two vehicles are depicted: a Leaf Vehicle (LV) and an Internet Vehicle (IV). Both of them embed a various number of Local Fixed Nodes (LFN) (like, for instance, sensors) and a Mobile Router (MR) that acts as a gateway between the network inside the vehicle and the outdoor. The main difference between the LV and the IV is the number of interfaces that are embedded on their MR and, consequently, their (in)ability to connect to an infrastructure network. In this figure, the MR-IV has two egress interfaces: one connected to the infrastructure (E2) using a long range communication technology (e.g. 3G or LTE) and the other one connected to the LV (E1) in an ad-hoc manner using a short range communication technology (e.g. 802.11p). The objective in the V2V2I use case is to provide an IPv6 end-to-end connectivity to the LFN that are embedded in the LV. To this end, a global and topologically correct IPv6 pefix must be advertised by the MR-LV on its I1 interface. The MR-LV gets the required prefix by asking for one to the MR-IV using the ND-PD mechanism. It is assumed that the MR-IV is provided with IPv6 prefixes by the infrastructure, either using DHCPv6-PD or any other way. Details about the messages exchanges generated by ND-PD in the V2V2I use case can be found in Section 10, with the MR-LV being the requesting router and MR-IV being the delegating router. Kaiser, et al. Expires August 29, 2013 [Page 7] Internet-Draft ND-PD February 2013 +-----------------+ | INTERNET ACCESS | | VIA THE | | INFRASTRUCTURE | | NETWORK | +--------+--------+ | | E2 | +-------------------------+ +-------------------------+ | | | | | | | | | | | +-----------+ | E1 E1 | +-----------+ | | | MR-LV |------|---------------|------| MR-IV | | | +-----------+ | | +-----------+ | | I1 | | | I1 | | | | | | | | | --------+-------- | | --------+-------- | | | | | | | | | | | | LFN-1 LFN-2 ... LFN-x | | LFN-1 LFN-2 ... LFN-x | | | | | +-------------------------+ +-------------------------+ Leaf Vehicle Internet Vehicle Figure 1: The V2V2I use case Kaiser, et al. Expires August 29, 2013 [Page 8] Internet-Draft ND-PD February 2013 6. Format of the Prefix Delegation option This section details the format of the option used in the ND-PD mechanism. This option is only valid if included in RS or RA messages and MUST NOT be included in NS, NA, or Redirect messages. The Prefix Delegation option is used to manage everything related to the delegation of prefixes. The following operations are considered: REQ: Request operation. A requesting router asks for a prefix to a delegating router. REN: Renew operation. A requesting router asks the delegating router that provided it the prefix to extend its lifetime. REL: Release operation. A requesting router that does not use anymore a delegated prefix informs the delegating router that provided it the prefix its intention of releasing it. REP: Reply operation. A delegating router replies to a message sent by a requesting router. SYN: Synchronization operation. When an error is detected, the delegating router sends its DPDB to the requesting router in order to re-synchronize their DPDB. The Prefix Delegation option is composed of a Prefix Delegation header that is followed by a list of Prefix Information (PI). The format of the Prefix Delegation header is as follows: 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 | Transac. ID | Op. Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N. P. Total | N. P. cncrnd. | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . List of PI . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Value that describes the Prefix Delegation option (TBD: IANA). Length: Size of the option in blocks of 64 bits (according to [NEIGHDISC]) including the fields "Type" and "Length". Kaiser, et al. Expires August 29, 2013 [Page 9] Internet-Draft ND-PD February 2013 Transac. ID: Identifier of the current messages exchange between the requesting router and the delegating router. Op. Type: Describes the type of the operation (REQ, REN, REL, REP or SYN). N. P. Total: The total number of prefixes that have been already delegated by the delegating router to the requesting router (used for synchronization). N. P. cncrnd.: The number of prefixes that are concerned by the operation. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: A list of Prefix Informations. 6.1. Format of the Prefix Information A Prefix Information is a structure that holds all informations related to a prefix. The format of the Prefix Information is as follow: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Prefix | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix length: The length of the prefix. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. Kaiser, et al. Expires August 29, 2013 [Page 10] Internet-Draft ND-PD February 2013 Preferred Lifetime: Time length in seconds (relative to the time the packet is sent) during which addresses generated from this prefix remain preferred (see [SLAAC]). A value of all one bits represents infinity. Valid Lifetime: Time length in seconds (relative to the time the packet is sent) during which the prefix is valid and can be used by nodes for auto- configuration (see [SLAAC]). A value of all one bits represents infinity. Prefix: The IPv6 delegated prefix. All bits in the prefix positionned after the prefix length MUST be set to "0". Kaiser, et al. Expires August 29, 2013 [Page 11] Internet-Draft ND-PD February 2013 7. Operations details 7.1. Requesting and delegating prefixes 7.1.1. Request A requesting router requests prefixes from a delegating router with the REQ operation. REQ operations are only valid if included in a RS message. This RS message MUST be sent in unicast to a delegating router present on link (see Section 9 for delegating routers discovery). The fields of the PD option for a REQ operation MUST be filled in with the following values: Transac. ID: An ID of the current messages exchange between the requesting router and the delegating router. This ID is chosen by the requesting router and MUST be unique among all other current transactions that the requesting router may have started. Op. Type: "REQ". It is a request for prefixes. N. P. Total: The total number of prefixes that have already been delegated by the delegating router to the requesting router. This value MUST be set to "0" when requesting prefixes to the delegating router for the first time, even if some prefixes have already been delegated by other delegating routers. N. P. cncrnd.: The number of prefixes that are requested by the requesting router. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: The list of PI is not necessary with a REQ operation. However, if the requesting router has some preferences about the parameters of the requested prefixes (e.g. the prefix length) it MAY add a PI for each requested prefix that describes its preferences. For example, if a requesting router requests three prefixes and has a preference for one of the three to have a prefix length of /48, it SHOULD add one PI with the "Prefix Length" field filled in with the value "48". Kaiser, et al. Expires August 29, 2013 [Page 12] Internet-Draft ND-PD February 2013 7.1.2. Reply A delegating router replies to a REQ operation with a REP operation. REP operations are only valid if included in a RA message. This RA message MUST be sent in unicast to the requesting router that initiated the message exchange. The fields of the PD option for a REP operation in reply to a REQ operation MUST be filled in with the following values: Transac. ID: This ID MUST be the same as the one received with the REQ. Op. Type: "REP". It is a reply. N. P. Total: The total number of prefixes that have been delegated by the delegating router to the requesting router. This value MUST include the prefixes that are delegated via this message. For example, if a requesting router has already recceived a prefix from the delegating router and asks for another one, the value of this field MUST be "2" (the previously delegated plus the new one). N. P. cncrnd.: The number of prefixes that are delegated via this message. It may be possible that this value is lower than the one received in the REQ (e.g. if the requesting router requested 3 prefixes but only 2 can be delegated). If no prefix can be delegated, this field MUST be set to "0". Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: For each delegated prefix a PI that describes it MUST be added in the list. If no prefixes are delegated, no PI MUST be added. 7.2. Renewing prefixes 7.2.1. Request A requesting router renews its delegated prefixes with the REN operation. REN operations are only valid if included in a RS message. This RS message MUST be sent in unicast to the delegating router that delegated the concerned prefixes. The fields of the PD option for a REN operation MUST be filled in with the following values: Kaiser, et al. Expires August 29, 2013 [Page 13] Internet-Draft ND-PD February 2013 Transac. ID: An ID of the current messages exchange between the requesting router and the delegating router. This ID is chosen by the requesting router and MUST be unique among all other current transactions that the requesting router may have started. Op. Type: "REN". It is a renew of prefixes. N. P. Total: The total number of prefixes that have been delegated by the delegating router to the requesting router. N. P. cncrnd.: The number of prefixes that are requested to be renewed. This value MUST be the same as the "N. P. Total" value because the renew operation acts for all the delegated prefixes. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: As the REN operation acts for all the delegated prefixes, no list of PI is necessary. 7.2.2. Reply A delegating router replies to a REN operation with a REP operation. REP operations are only valid if included in a RA message. This RA message MUST be sent in unicast to the requesting router that initiated the message exchange. The fields of the PD option for a REP operation in reply to a REN operation MUST be filled in with the following values: Transac. ID: This ID MUST be the same as the one received with the REN. Op. Type: "REP". It is a reply. N. P. Total: The total number of prefixes that have been delegated by the delegating router to the requesting router. N. P. cncrnd.: The number of prefixes that are successfully renewed via this message. It MAY be possible that this value is lower than the one received in the REN (e.g. if the requesting router requested to renew 3 prefixes but only 2 can be renewed). If no prefix can be renewed, this field MUST be set to "0". Kaiser, et al. Expires August 29, 2013 [Page 14] Internet-Draft ND-PD February 2013 Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: The following cases are possible: 1. If no prefix is renewed, the list of PI MUST be empty. 2. If only part of the prefixes are renewed, a PI MUST be added for each successfully renewed prefix. 3. If all the prefixes are renewed, the list of PI is not necessary, except if the parameters of one or more of the renewed prefixes have changed compared with the last delegation/renew time. As an example, let us consider that the delegating router has delegated two prefixes to the requesting router with preferred and valid lifetimes equal to "10" and "15" respectively. The requesting router now asks for renewing these prefixes. If both prefixes are renewed for the same amount of time (same preferred and valid lifetimes than previously), no PI SHOULD be added. But, if the prefixes are renewed for a different amount of time (e.g. preferred and valid lifetimes equal to "8" and "12" respectively), a PI MUST be added for each renewed prefix. 7.3. Releasing prefixes 7.3.1. Request A requesting router releases its delegated prefixes with the REL operation. REL operations are only valid if included in a RS message. This RS message MUST be sent in unicast to the delegating router that delegated the concerned prefixes. The fields of the PD option for a REL operation MUST be filled in with the following values: Transac. ID: An ID of the current messages exchange between the requesting router and the delegating router. This ID is chosen by the requesting router and MUST be unique among all other current transactions that the requesting router may have started. Kaiser, et al. Expires August 29, 2013 [Page 15] Internet-Draft ND-PD February 2013 Op. Type: "REL". It is a release of prefixes. N. P. Total: The total number of prefixes that have been delegated by the delegating router to the requesting router. This value MUST include the prefixes that are included in this message as the release operation has not been successfully processed yet. N. P. cncrnd.: The number of prefixes that are requested to be released. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: If the REL operation concerns all the prefixes that have been delegated by the delegating router, the list of PI is not needed. If the REL operation concerns only part of the delegated prefixes, a PI MUST be added for each concerned prefix. 7.3.2. Reply A delegating router does not reply to a REL operation. 7.4. Prefixes synchronization and error detection The SYN operation is sent by a delegating router to a requesting router when an error about the DPDB is detected. SYN operations are only valid in a RA message. This RA message MUST be sent in unicast to the requesting router that initiated the message exchange. The goal of the SYN operation is to re-synchronize the DPDB of the requesting and the delegating router. Each time a delegating router receives a RS message with a PD option, it first starts by checking if the total number of delegated prefixes that the requesting router has in its DPDB (advertised in the "N. P. Total" field) is the same as the one the delegating router has in its DPDB. If both values are the same, the process of the PD option can be continued. Otherwise, an error occurred and both DPDB MUST be re-synchronized (thus the operation requested by the requesting router is NOT processed). The rule is simple: the delegating router sends its DPDB back to the requesting router via a RA message that includes the PD option with the SYN operation. Upon reception of the message, the requesting router updates its DPDB to fit the one advertised by the delegating router. The requesting router MAY then re-send its initial request. The fields of the PD option for a SYN operation MUST be filled in with the following values: Kaiser, et al. Expires August 29, 2013 [Page 16] Internet-Draft ND-PD February 2013 Transac. ID: This ID MUST be the same as the one received in the PD option of the RS message sent by the requesting router. Op. Type: "SYN". It is a synchronization operation. N. P. Total: The total number of prefixes that have been delegated by the delegating router to the requesting router. N. P. cncrnd.: The number of prefixes that are concerned by this operation. This value MUST be the same as the one above. Reserved: Unused field. MUST be set to "0" by sender and ignored by recipient. List of PI: The list of all the PI MUST be added. Kaiser, et al. Expires August 29, 2013 [Page 17] Internet-Draft ND-PD February 2013 8. Local operations on requesting and delegating routers Upon reception of a RS or a RA message, requesting and delegating routers MUST first check the validity of the message as described in section 6.1. "Message Validation" of [NEIGHDISC]. The processing of the message itself along with any option other than the PD option described in this document is out of the scope of this document. 8.1. Delegated prefixes handling The delegated prefixes on both the requesting and the delegating routers are handled using the DPDB. The DPDB is a logical structure that stores all informations related to a requesting/delegating routers tuple. One and only one DPDB MUST be created for each requesting/delegating routers tuple. The DPDB includes but is not restricted to the following informations: o The link-local IPv6 address of the requesting router. o The link-local IPv6 address of the delegating router. o The Transaction ID used in the last RS or RA message received that includes a PD option. o The Transaction ID used in the last RS or RA message sent that includes a PD option. o The total number of prefixes that have been delegated. o The shortest preferred and valid lifetimes among the delegated prefixes (for an easier handling of the renew operation). o The list of all the prefixes that have been delegated (list of PI). 8.2. Delegating router behaviour 8.2.1. Checking the validity of the PD option Upon reception of a RS message that includes a PD option, the delegating router MUST first check that the type of operation of the PD option is either REQ or REN or REL and that the PD flag (see Section 9) is not set. If one or both of these conditions are not met the message MUST be silently discarded. Kaiser, et al. Expires August 29, 2013 [Page 18] Internet-Draft ND-PD February 2013 8.2.2. Checking the synchronization of the DPDB Before processing the operation, the DPDB synchronization MUST be checked. To this end, the delegating router compares the value of the "N. P. Total" field of the PD option with the total number of delegated prefixes of its DPDB. If both values are the same, the operation can be processed. Otherwise, the delegating router MUST send back to the requesting router a SYN operation in order to re- synchronize both DPDB. 8.2.3. Processing the operations If the PD option includes a REQ operation, the delegating router checks its possibility to delegate the requested prefixes to the requesting router. For each successfully delegated prefix the delegating router MUST add in its routing table one entry with the following parameters: the destination network is the delegated prefix and the next-hop is the IPv6 address of the requesting router. The delegating router MUST then reply with a RA message that includes a PD option with the REP operation filled accordingly. While the delegated prefixes are not released (either with a REL operation or when their valid lifetime has expired) they MUST NOT be delegated again. If the PD option includes a REN operation, the delegating router checks its possibility to renew all the prefixes present in the DPDB. For each successfully renewed prefix, the delegating router MUST update the corresponding entry in its routing table. The delegating router MUST then reply with a RA message that includes a PD option with the REP operation filled accordingly. If the PD option includes a REL operation, the delegating router MUST release the corresponding prefixes. For each successfully released prefix, the delegating router MUST delete the corresponding entry in its routing table. If the delegating router detects that one or more of the prefixes specified by the requesting router in the REN or REL operations are not valid, the delegating router MUST NOT process the operation and MUST send back to the requesting router a SYN operation to re- synchronize the DPDB. When the Valid Lifetime of a delegated prefix has expired, the delegating router MUST update its routing table by removing the corresponding entry. The expired prefix is then available for future delegation. Kaiser, et al. Expires August 29, 2013 [Page 19] Internet-Draft ND-PD February 2013 8.3. Requesting router behaviour 8.3.1. Checking the validity of the PD option Upon reception of a RA message that includes a PD option, the requesting router MUST first check that the type of operation of the PD option is either REP or SYN and that the PD flag is set (see Section 9). If one or both of these conditions are not met the message MUST be silently discarded. 8.3.2. Checking the synchronization of the messages exchange In order to ensure that the received RA message is a reply to the initiated request, the requesting router MUST check that the "Transac. ID" of the received message fits the one it generated for its last request. 8.3.3. Processing the operations If the PD option includes a REP operation, the requesting router is free of advertising the prefixes included in the REP message on any of its interfaces except the one from which the REP message was received. For each prefix that is advertised on an interface, the requesting router MUST add an entry in its routing table with the following parameters: the destination network is the advertised prefix and the output interface is the one where the prefix is advertised. If the PD option includes a SYN operation, the requesting router MUST update its DPDB with the inputs included in the RA message along with its routing table entries. The requesting router MAY then re-send its initial request. When the Valid Lifetime of a delegated prefix has expired, the requesting router MUST update its routing table by removing the corresponding entry. Also the requesting router MUST stop advertising this prefix on the corresponding interface. Kaiser, et al. Expires August 29, 2013 [Page 20] Internet-Draft ND-PD February 2013 9. Advertising the ND-PD service Each delegating router that delegates prefixes using the ND-PD mechanism described in this document MUST advertise this service by adding the new PD flag (for Prefix Delegation) in each RA message it sends. The PD flag MUST be advertised using the RA flags option described in [RAFLAGS]. Kaiser, et al. Expires August 29, 2013 [Page 21] Internet-Draft ND-PD February 2013 10. Messages exchange diagram This section depicts the messages exchanges generated by ND-PD between a requesting router and a delegating router. Values under "N. P. Total" represent the current total number of delegated prefixes that each router has in its DPDB. All messages shown in this example include a PD option (except the periodic RA message). For each of those messages, the type of operation as well as the corresponding PI that are carried out by the PD option are pointed out. +--------+ +--------+ | Req. | | Del. | | Router | | Router | +--------+ +--------+ | | N. P. Total | | N. P. Total 0 | | 0 | periodic RA - flag PD set | |<--------------------------| | | . . . . . . | | | RS - REQ | |-------------------------->| 0 | | 0 | RA - REP(P1,P2) | |<--------------------------| 2 | | 2 | | The delegating router sends periodic RA messages with the PD flag set. Upon reception of such message, the requesting router knows that the delegating router provides the ND-PD service. At some point, the requesting router asks for two prefixes. The delegating router accepts the request and delegates prefixes P1 and P2. Both DPDB are updated: the total number of delegated prefix for this tuple of requesting/delegating routers is set to 2. | | | RS - REQ | |-------------------------->| 2 | | 2 | RA - REP(P3) | | X---------------------| 2 | | 3 Kaiser, et al. Expires August 29, 2013 [Page 22] Internet-Draft ND-PD February 2013 | | Let us consider that the delegating router now needs one more prefix. It asks for a new prefix to the delegating router. The delegating router accepts the request and replies with the new delegated prefix P3. However, for some reasons, this message never arrives to the requesting router. Only the DPDB of the delegating router is updated: the delegating router has delegated three prefixes to the requesting router but this latter owns only two of them. | | | RS - REN | |-------------------------->| 2 | | 3 | RA - SYN(P1,P2,P3) | |<--------------------------| 3 | | 3 | | Let us assume that the Preferred Lifetime of P1 and P2 is now over. However, the requesting router would like to keep both prefixes active for more time. Hence, it asks the delegating router to renew its delegated prefixes. Upon checking the synchronization of the DPDB, the delegating router detects that the total number of delegated prefixes is not the same. Therefore, the delegating router replies with a SYN operation in order to re-synchronize both DPDB. | | | RS - REN | |-------------------------->| 3 | | 3 | RA - REP(P1,P3) | |<--------------------------| 2 | | 2 | | Now that both DPDB are re-synchronized, the requesting router asks once again for renewing its delegated prefixes. For some reasons, the delegating router accepts the renew only for P1 and P3 and replies consequently. Both DPDB are updated. | | | RS - REL(P3) | |-------------------------->| 1 | | 1 | | Finally, the requesting router does not need anymore P3. It thus Kaiser, et al. Expires August 29, 2013 [Page 23] Internet-Draft ND-PD February 2013 releases it and both DPDB are updated. Kaiser, et al. Expires August 29, 2013 [Page 24] Internet-Draft ND-PD February 2013 11. Security Considerations This section describes the security issues related to prefix delegation using ND_PD. The ND_PD mechanism is prone to attacks that may target either the requesting router or the delegating router, particularly by launching denial-of-service (DoS) attacks as discussed in [DHCPV6_PD]. If the requesting router is malicious, it may repeatedly request prefixes to a delegating router until the exhaustion of all the available prefixes. This attack could be launched with the same requesting router identity or with different spoofed link addresses. On the other side, a malicious delegating router may issue bogus prefixes to the requesting router which may cause DoS due to unreachability. Furthermore, the delegated prefixes could be eavesdropped, suppressed or altered during their transmission to the requesting router, whereby external attackers aim at using spoofed IP addresses or launching DoS attacks in the network. Kaiser, et al. Expires August 29, 2013 [Page 25] Internet-Draft ND-PD February 2013 12. IANA Considerations IANA is kindly requested by the authors to allocate the following values: o Prefix Delegation option type, which should be added to the Neighbor Discovery option type space defined in section 13 of [NEIGHDISC] o Prefix Delegation operation types: * REQ * REN * REL * REP * SYN o Space allocation for the PD flag in the RA flags option. Kaiser, et al. Expires August 29, 2013 [Page 26] Internet-Draft ND-PD February 2013 13. Acknowledgements The authors would like to acknowledge the useful technical contribution of Sofiane Imadali. This work has been performed in the framework of the ICT project ICT- 5-258512 EXALTED, which is partly funded by the European Union. The organisations on the source list [CEA] would like to acknowledge the contributions of their colleagues to the project, although the views expressed in this contribution are those of the authors and do not necessarily represent the project. Kaiser, et al. Expires August 29, 2013 [Page 27] Internet-Draft ND-PD February 2013 14. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DHCPV6_PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCPv6) version 6", RFC 3633, December 2003. [NEIGHDISC] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [DRAFT_LUTCHANSKY] Lutchansky, N., "IPv6 Router Advertisement Prefix Delegation Option", draft-lutchann-ipv6-delegate-option-00.txt , February 2002. [DRAFT_HABERMAN] Haberman, B. and J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", draft-haberman-ipngwg-auto-prefix-02.txt , February 2002. [RAFLAGS] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 4861, March 2008. Kaiser, et al. Expires August 29, 2013 [Page 28] Internet-Draft ND-PD February 2013 Authors' Addresses Arnaud Kaiser Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Email: arnaud.kaiser@cea.fr Sylvain Decremps Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Email: sylvain.decremps@cea.fr Nouha Oualha Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Email: nouha.oualha@cea.fr Alexandru Petrescu Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Email: alexandru.petrescu@cea.fr Kaiser, et al. Expires August 29, 2013 [Page 29]