Internet DRAFT - draft-kaiser-nd-pd
draft-kaiser-nd-pd
Network Working Group A. Kaiser
Internet-Draft S. Decremps
Intended status: Experimental N. Oualha
Expires: May 22, 2014 CEA
A. Petrescu
CEA, LIST
November 18, 2013
Prefix Delegation extension to Neighbor Discovery protocol
draft-kaiser-nd-pd-02
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 May 22, 2014.
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
Kaiser, et al. Expires May 22, 2014 [Page 1]
Internet-Draft ND-PD November 2013
include Simplified BSD License text as described in Section 4.e of
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
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Kaiser, et al. Expires May 22, 2014 [Page 2]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 3]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 4]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 5]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 6]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 7]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 8]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 9]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 10]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 11]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 12]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 13]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 14]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 15]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 16]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 17]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 18]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 19]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 20]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 21]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 22]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 23]
Internet-Draft ND-PD November 2013
releases it and both DPDB are updated.
Kaiser, et al. Expires May 22, 2014 [Page 24]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 25]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 26]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 27]
Internet-Draft ND-PD November 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 May 22, 2014 [Page 28]
Internet-Draft ND-PD November 2013
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-kaiser-nd-pd-01.txt to draft-kaiser-nd-pd-02.txt:
o updated one author's affiliation detail.
Kaiser, et al. Expires May 22, 2014 [Page 29]
Internet-Draft ND-PD November 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
CEA, LIST
CEA Saclay
Gif-sur-Yvette, Ile-de-France 91190
France
Phone: +33169089223
Email: Alexandru.Petrescu@cea.fr
Kaiser, et al. Expires May 22, 2014 [Page 30]
