Prefix Delegation extension to Neighbor Discovery protocol
draft-kaiser-nd-pd-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Arnaud Kaiser , Sylvain Decremps, Alexandre Petrescu | ||
| Last updated | 2012-10-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kaiser-nd-pd-00
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]