Network Working Group A. Kaiser Internet-Draft S. Decremps Intended status: Experimental A. Petrescu Expires: April 18, 2013 CEA October 15, 2012 Prefix Delegation extension to Neighbor Discovery protocol draft-kaiser-nd-pd-00 Abstract This document describes an extension to the Neighbor Discovery protocol (ND). The proposed extension enhances ND by providing it a new option: the Prefix Delegation option (ND_PD). ND_PD offers the possibility for a router to ask for prefixes to be delegated, even if no DHCPv6 Server (or Relay) are present on link. 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 April 18, 2013. Copyright Notice Copyright (c) 2012 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 the Trust Legal Provisions and are provided without warranty as Kaiser, et al. Expires April 18, 2013 [Page 1] Internet-Draft ND PD October 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Related works . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Example use case . . . . . . . . . . . . . . . . . . . . . 7 6. Format of the Prefix Delegation option . . . . . . . . . . . . 9 6.1. Format of the Prefix Collection structure . . . . . . . . 10 6.2. Format of the Prefix Information structure . . . . . . . . 11 7. Prefix Delegation packets format . . . . . . . . . . . . . . . 13 7.1. Requesting prefixes . . . . . . . . . . . . . . . . . . . 13 7.2. Delegating prefixes . . . . . . . . . . . . . . . . . . . 13 7.3. Renewing/rebinding prefixes . . . . . . . . . . . . . . . 14 7.4. Releasing prefixes . . . . . . . . . . . . . . . . . . . . 15 8. Advertisement of the ND_PD service . . . . . . . . . . . . . . 16 9. Local operations on requesting and delegating routers . . . . 17 9.1. Delegating router behaviour . . . . . . . . . . . . . . . 17 9.2. Requesting router behaviour . . . . . . . . . . . . . . . 18 10. Status codes . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Kaiser, et al. Expires April 18, 2013 [Page 2] Internet-Draft ND PD October 2012 1. Introduction 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 even if any DHCPv6 Server (or Relay) is present on the link. The goal of the ND_PD mechanism described in this document is the same as the DHCPv6 Prefix Delegation mechanism (DHCPv6_PD) described in [DHCPV6_PD]. Therefore, the ND_PD mechanism can be seen as a substitute of the DHCPv6_PD mechanism that can be used on links lacking in DHCPv6 Servers (or Relays). Indeed, there exists a various number of situations where the DHCPv6 services may not be enabled on a link. In the context of vehicular networks for instance, a vehicle (called Leaf Vehicle (LV)) may access the Internet through another vehicle (called Internet Vehicle (IV)) that shares its Internet connexion. In order to provide Internet access to the nodes present in the LV, the latter needs a global IPv6 prefix. If the IV does not provide DHCPv6 services, the LV will not be able to get a global IPv6 prefix. In this kind of situations, the LV can still ask for a prefix using the ND_PD mechanism. Indeed, as the ND protocol is present on each IPv6 capable node (which is not the case for DHCPv6), providing ND with a PD extension ensures that any IPv6 router is able to request for a prefix in any situation. Moreover, as the proposed ND_PD mechanism relies only on the exchange of two messages (compared with DHCPv6_PD that needs the exchange of 4 messages), it can be more suitable in the case of highly mobile networks (e.g. vehicular networks). Kaiser, et al. Expires April 18, 2013 [Page 3] Internet-Draft ND PD October 2012 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 Collection: A logical structure that stores a list of Prefix Informations. A Prefix Collection is identified by its unique identifier, namely PC_ID. Prefix Information: A logical structure that stores all informations related to a prefix. A Prefix Information is always associated with a Prefix Collection. Kaiser, et al. Expires April 18, 2013 [Page 4] Internet-Draft ND PD October 2012 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 April 18, 2013 [Page 5] Internet-Draft ND PD October 2012 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 that the creation of new ICMP messages. Also, the ND_PD service provided by a router is advertised in the header of its RA. This information enable requesting routers to be aware of the presence of routers that provide the ND_PD service on link without asking for it by, for instance, sending a RS on the all-routers link-local multicast address. Kaiser, et al. Expires April 18, 2013 [Page 6] Internet-Draft ND PD October 2012 5. Protocol overview The ND_PD mechanism presented in this document defines a new option for the RS and the RA messages. Using this option, routers on a same link can request and/or delegate prefixes to other routers even if any DHCPv6_PD Server/Relay is present on the link. The Prefix Delegation option proposed in this document adds the following functionnalities to the Neighbor Discovery protocol: o Request of prefixes o Delegation of prefixes o Renew of already delegated prefixes o Release of delegated prefixes These functionnalities are described in more details in Section 6. 5.1. Example use case In Figure 1 a vehicular scenario is shown. The figure depicts two vehicles: a Leaf Vehicle (LV) and an Internet Vehicle (IV). Both of them embed several Local Fixed Nodes (LFN), like sensors for example, and a Mobile Router (MR) that acts as a gateway between the network inside the vehicle (made of LFNs) and the outdoor. The main difference between the LV and the IV is the number of interfaces present in the MR and its capacity 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 technology (e.g. 3G or LTE) and the other one connected to the LV (E1) in ad-hoc using a short range technology (e.g. wifi). Let us assume that a DHCPv6 server exists in the infrastructure. Therefore, using DHCPv6_PD the MR-IV can obtain a global prefix to announce on its ingress interface (I1) to configure its LFNs. In order to enable the LFNs of the LV to access the Internet, the LV also needs a global prefix to assign on its ingress interface I1. As the IV is neither a DHCPv6 Server nor a DHCPv6 Relay, the LV can still ask for a prefix to the IV using the ND_PD mechanism. If the IV has a pool of prefixes to assign, it will delegate a prefix to the LV. Otherwise, the IV can ask the DHCPv6 Server in the infrastructure for an additionnal prefix that it will delegate to the LV. Kaiser, et al. Expires April 18, 2013 [Page 7] Internet-Draft ND PD October 2012 +----------+ | INTERNET | | ACCESS | +-----+----+ | | 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: A vehicular scenario Kaiser, et al. Expires April 18, 2013 [Page 8] Internet-Draft ND PD October 2012 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 delegated prefixes. The following operations are considered: REQ: Request operation. A requesting router asks for a prefix to a delegating router. REP: Reply operation. A delegating router replies to a requesting router. Depending on the type of request, a reply message acts as a delegating message that contains the delegated prefix (i.e. in response of a REQ, REN, or REB message) or as an acknoledgment message that contains the prefix that has been successfully released (i.e. in response of a REL message). REN: Renew operation. A requesting router asks the delegating router that provided it the prefix to extend its lifetime. REB: Rebind operation. A requesting router asks any delegating router present on the link to extend the lifetime of its delegated prefix. 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. The Prefix Delegation option is composed of a Prefix Delegation header followed by a list of Prefix Collection structures. 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 | Msg. Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . List of PC . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kaiser, et al. Expires April 18, 2013 [Page 9] Internet-Draft ND PD October 2012 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". Transac. ID: Identifier of the current messages exchange between the requesting router and the delegating router. Msg. Type: Describes the type of operation related to the message (REQ, REP, REN, REB, or REL). Reserved: Unused field. MUST be set to 0 by sender and ignored by recipient. List of PC: A list of Prefix Collection structures. 6.1. Format of the Prefix Collection structure A Prefix Collection is a structure that holds a list of prefixes. It is composed of a Prefix Collection header followed by a list of Prefix Information structures. It can be seen as the equivalent of an IA_PD option in DHCPv6_PD. The format of the Prefix Collection 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Status Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PC_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Renew Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rebind Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . List of PI . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The length in blocks of 64 bits of the Prefix Collection including the Prefix Collection header and all the Prefix Informations associated with it. Kaiser, et al. Expires April 18, 2013 [Page 10] Internet-Draft ND PD October 2012 Status Code: An unsigned integer value that gives informations about the success or failure of an operation along with other additionnal informations. When processing RS messages, this value MUST be set to FULL_SUCCESS by the sender and ignored by the recipient. More details are presented in Section 10. Reserved: Unused field. MUST be set to 0 by sender and ignored by recipient. PC_ID: An unique identifier of the Prefix Collection. The PC_ID MUST be unique among all PC_ID known by the requesting router. Renew Time: Time length in seconds (relative to the time the packet is sent) before which the requesting router should contact the delegating router from which the Prefix Collection has been received to extend the lifetime of all the prefixes associated with this Prefix Collection. Rebind Time: Time length in seconds (relative to the time the packet is sent) before which the requesting router should contact any delegating router that is present on the link to extend the lifetime of all the prefixes associated with the Prefix Collection. List of PI: A list of Prefix Information structures. 6.2. Format of the Prefix Information structure A Prefix Information is a structure that holds all informations related to a prefix. A Prefix Information can be seen as the equivalent of an IA_PD Prefix option in DHCPv6_PD. The format of the Prefix Information is as follow: Kaiser, et al. Expires April 18, 2013 [Page 11] Internet-Draft ND PD October 2012 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. 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 April 18, 2013 [Page 12] Internet-Draft ND PD October 2012 7. Prefix Delegation packets format 7.1. Requesting prefixes The request for prefixes is done using the REQ operation. Thus, the "Msg. Type" field in the Prefix Delegation option of the RS message MUST be set to REQ. When requesting prefixes a requesting router MUST add for each requested prefix a Prefix Information in the Prefix Delegation option of the RS message. For example, if a router requests three prefixes, three Prefix Information MUST be included in the RS message. The requested prefixes MUST also be associated to a Prefix Collection. The number of Prefix Information associated to a Prefix Collection is left to the choice of the requesting router. However a Prefix Information MUST be associated with only one Prefix Collection. The format of the RS message is as follows: +----+--------+------+------+-----+------+------+---- | RS | PD opt.| PC 1 | PI 1 | ... | PI x | PC x | ... +----+--------+------+------+-----+------+------+---- The fields "Renew Time" and "Rebind Time" in the Prefix Collection header and all the fields in the Prefix Information MAY be set to values that the requesting router prefers. If the requesting router has no preference, these fields MUST be set to 0. Also notice that the PC_ID value in the Prefix Collection header is left to the choice of the requesting router, following the rule that a PC_ID MUST be unique among all PC_ID known by the requesting router. 7.2. Delegating prefixes The delegation of prefixes is done using the REP operation. Thus, the "Msg. Type" field in the Prefix Delegation option of the RA message MUST be set to REP. Upon reception of a RS message, a delegating router replies with a RA message that includes all delegated prefixes. If, for some reasons, the request (or part of the request) cannot be fulfilled, the delegating router replies with only the Prefix Collection header and the associated Status Code. The format of the RA message is as follows: Kaiser, et al. Expires April 18, 2013 [Page 13] Internet-Draft ND PD October 2012 +----+--------+------+------+-----+------+------+------+---- | RA | PD opt.| PC 1 | PI 1 | ... | PI x | PC 2 | PC x | ... +----+--------+------+------+-----+------+------+------+---- \__ __/ \/ An error has occured thus PC 2 is empty of PIs. 7.3. Renewing/rebinding prefixes The renew or rebind of prefixes is done using the REN or REB operation respectively. Thus, the "Msg. Type" field in the Prefix Delegation option of the RS message MUST be set to REN or REB. When the Renew Time of a Prefix Collection expires, a requesting router SHOULD renew the Prefix Collection in order to continue using the associated delegated prefixes. To this end, the requesting router MUST send a RS message to the delegating router that delegated it the Prefix Collection. The RS message MUST contain all Prefix Collections (including all the Prefix Informations associated to them) that need to be renewed. The format of the RS message is the same as the one presented in Section 7.1. When the Rebind Time of a Prefix Collection expires, the behaviour of the requesting router is the same as in the renew case. The only difference is that the RS message MUST be sent to all routers present in the link. The behaviour of a delegating router that receives a Renew or Rebind request is as follows: 1. The delegating router can identify a Prefix Collection (using its PC_ID): it updates the Renew and Rebind Times of the Prefix Collection and the Preferred and Valid Lifetimes of all the prefixes associated with this Prefix Collection and adds in its RA message ("Msg. Type" = REP) the Prefix Collection (including all the Prefix Information associated with it). 2. The delegating router cannot identify a Prefix Collection: it adds in the RA message only the Prefix Collection header with an appropriate Status Code. The format of the RA message is the same as the one presented in Section 7.2. Kaiser, et al. Expires April 18, 2013 [Page 14] Internet-Draft ND PD October 2012 7.4. Releasing prefixes The release of prefixes is done using the REL operation. Thus, the "Msg. Type" field in the Prefix Delegation option of the RS message MUST be set to REL. When a requesting router does not use anymore a prefix, it SHOULD release it. To this end, the requesting router SHOULD send a RS message to the delegating router that delegated it the prefix. The RS message MUST include the Prefix Collection header to which the releasing prefix is associated with and MUST only include the Prefix Informations related to the prefixes that should be released. For example, if a requesting router has a Prefix Collection with four prefixes associated with it and it wants to release one of the four, only the Prefix Information of this prefix MUST be added in the RS message. The format of the RS message is the same as the one presented in Section 7.1. When a delegating router receives a request for releasing prefixes, it replies with a RA message ("Msg. type" = REP) that includes either only the Prefix Collection header and an appropriate Status Code if an error occurred and the release cannot be fulfilled, or the Prefix Collection header and the Prefix Informations associated with it that have been successfully released. Thus, this reply acts as an acknoledgment of the prefixes that have been successfully released. The format of the RA message is the same as the one presented in Section 7.2. Kaiser, et al. Expires April 18, 2013 [Page 15] Internet-Draft ND PD October 2012 8. Advertisement of the ND_PD service Each router that runs the ND_PD mechanism as described in this document MUST advertise the nodes about this service. To this end the new D flag ("prefix Delegation" flag) is added in the header of the RA messages (according to [RAFLAGS] and [IANAWEB] the flag space could be allocated at position 6). If set, this flag indicates that the router that originated the RA message provides the ND_PD service. Figure 2 shows the modified header of the RA messages that includes this new flag. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Prf|P|D|r| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... | +-+-+-+-+-+-+-+-+-+-+-+- Figure 2: Header of a RA message M: Managed Address Configuration Flag [NEIGHDISC] O: Other Configuration Flag [NEIGHDISC] H: Mobile IPv6 Home Agent Flag [MIPV6] Prf: Router Selection Preferences [DRPREF] P: Neighbor Discovery Proxy Flag [NDPROXY] D: The prefix Delegation flag that indicates the ND_PD service provided by the originating router. r: Reserved. Please refer to section 4.2 of [NEIGHDISC] for more details about the other fields. Kaiser, et al. Expires April 18, 2013 [Page 16] Internet-Draft ND PD October 2012 9. 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 Prefix Delegation option described in this document is out of the scope of this document. 9.1. Delegating router behaviour Upon reception of a REQ message, the delegating router checks the possibility to delegate the requested prefixes to the client. If there are prefixes that are available in the pool to satisfy the whole or part of the request, the delegating router MUST add in its routing table one entry for each delegated prefix via the link-local address of the requesting router, and MUST reply with a REP message that includes all the delegated prefixes and MUST set the status code of the message to either FULL_SUCCESS (if all requested prefixes are delegated) or PARTIAL_SUCCESS (if only part of the requested prefixes are delegated). All the prefixes that have been delegated MUST NOT be delegated again before being released either by a REL message coming from the requesting router or by reaching the valid lifetime associated to the prefix. If the request cannot be satisfied, the delegating router MUST reply with a REP message that includes no prefix and MUST set the status code to NO_PREF_AVAIL. Upon reception of a REN message, the delegating router checks the possibility to renew each prefix present in the message. For each prefix that can be renewed, the delegating router MUST update the corresponding entry in its routing table. A REP message MUST then be replied with either the FULL_SUCCESS or the PARTIAL_SUCCESS status code depending on the number of prefixes that have been successfully renewed. If none of the prefixes can be renewed, the delegating router MUST remove all corresponding entries in its routing table and MUST reply with a REP message whose status code is set to NO_PREF_AVAIL. Upon reception of a REB message, the delegating router checks the possibility to rebind each prefix included in the message. For each successfully rebinded prefix, the delegating router MUST update its routing table by adding one entry for each delegated prefix via the link-local address of the requesting router. A REP message MUST then be replied with either the FULL_SUCCESS or the PARTIAL_SUCCESS status code depending on the number of prefixes that have been successfully rebinded. If none of the prefixes can be rebinded, the delegating router MUST reply with a REP message with a status code set to NO_PREF_AVAIL. Kaiser, et al. Expires April 18, 2013 [Page 17] Internet-Draft ND PD October 2012 Upon reception of a REL message, the delegating router checks the possibility to release each prefix included in the REL message. For each successfully released prefix, the delegating router MUST update its routing table by removing the corresponding entries. A REP message that includes all successfully released prefixes as well as the corresponding FULL_SUCCESS or PARTIAL_SUCCESS status code MUST be replied. If, for any reason, none of the prefixes can be released, the delegating router MUST reply with a REP message that do not include any prefix and with the NO_PREF_AVAIL status code. When the Valid Lifetime of a delegated prefix has been reached, the delegating router MUST update its routing table by removing the corresponding entry. The expired prefix is then available for future delegation. 9.2. Requesting router behaviour Upon reception of a REP message that includes delegated prefixes (i.e. in response of a REQ, REN or REB message), 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 (or update if the entry already exists) an entry for the prefix through the interface where it is advertised. If a REP message is received in response of a REL message, the requesting router MUST stop advertising any prefix that is included in the REP message. The requesting router MUST also update its routing table by removing each entry that matches the prefixes included in the REP message. If the Valid Lifetime of a delegated prefix is reached, the requesting router MUST stop advertising the expired prefix and MUST update its routing table by removing the corresponding entry. Kaiser, et al. Expires April 18, 2013 [Page 18] Internet-Draft ND PD October 2012 10. Status codes Status codes are present in the Prefix Collection headers. They are used to give additionnal information to a requesting router about the result of its request. Therefore, all Prefix Collections included in a REP message MUST include a Status code related to their current status. On the contrary, the Status code has no utility when sending requesting messages (REQ, REN, REB and REL messages). Thus, the Status code of a Prefix Collection MUST be set to FULL_SUCCESS (default value) by the requesting router and ignored by the recipient. The following Status codes are supported: FULL_SUCCESS Indicates that the request has been successfully processed: the requested operation (REQ, REN, REB or REL) has been successfull on all prefixes listed in the Prefix Collection. PARTIAL_SUCCESS Informs that only part of the request has been successfully processed: the requested operation has been successfull only on part of the prefixes listed in the requested Prefix Collection. Thus, the replied Prefix Collection includes only the successfull prefixes. NO_PREF_AVAIL Informs that no prefixes are available for delegation. Kaiser, et al. Expires April 18, 2013 [Page 19] Internet-Draft ND PD October 2012 11. Security Considerations TBD Kaiser, et al. Expires April 18, 2013 [Page 20] Internet-Draft ND PD October 2012 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 Message Type: * REQ * REP * REN * REB * REL o Status Codes: * FULL_SUCCESS * PARTIAL_SUCCESS * NO_PREF_AVAIL o Space allocation for the D flag in the header of RA messages. Kaiser, et al. Expires April 18, 2013 [Page 21] Internet-Draft ND PD October 2012 13. Acknowledgements The authors would like to acknowledge the useful technical contribution of Sofian 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 April 18, 2013 [Page 22] Internet-Draft ND PD October 2012 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. [IANAWEB] "http://www.iana.org/assignments/icmpv6-parameters/ icmpv6-parameters.xml#icmpv6-parameters-11". [MIPV6] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, June 2004. [DRPREF] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [NDPROXY] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. Kaiser, et al. Expires April 18, 2013 [Page 23] Internet-Draft ND PD October 2012 Authors' Addresses Arnaud Kaiser Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Phone: +33 1 69 08 07 28 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 Alexandru Petrescu Commissariat a l'Energie Atomique 8 Avenue de la Vauve Palaiseau, Ile-de-France 91120 FR Phone: +33 1 69 08 92 23 Email: alexandru.petrescu@cea.fr Kaiser, et al. Expires April 18, 2013 [Page 24]