[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                          A. Kaiser
Internet-Draft                                               S. Decremps
Intended status: Experimental                                  N. Oualha
Expires: August 29, 2013                                     A. Petrescu
                                                                     CEA
                                                       February 25, 2013


       Prefix Delegation extension to Neighbor Discovery protocol
                         draft-kaiser-nd-pd-01

Abstract

   This document describes an extension to the Neighbor Discovery
   protocol (ND).  The proposed extension enhances ND by providing it
   with a new option: the Prefix Delegation option (ND-PD).  ND-PD
   offers the possibility for routers on a same link to ask for or
   delegate IPv6 prefixes.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Kaiser, et al.           Expires August 29, 2013                [Page 1]


Internet-Draft                    ND-PD                    February 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction and motivations . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Related works  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Use case example: V2V2I  . . . . . . . . . . . . . . . . . . .  7
   6.  Format of the Prefix Delegation option . . . . . . . . . . . .  9
     6.1.  Format of the Prefix Information . . . . . . . . . . . . . 10
   7.  Operations details . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Requesting and delegating prefixes . . . . . . . . . . . . 12
       7.1.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 12
       7.1.2.  Reply  . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.2.  Renewing prefixes  . . . . . . . . . . . . . . . . . . . . 13
       7.2.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 13
       7.2.2.  Reply  . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.3.  Releasing prefixes . . . . . . . . . . . . . . . . . . . . 15
       7.3.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 15
       7.3.2.  Reply  . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.4.  Prefixes synchronization and error detection . . . . . . . 16
   8.  Local operations on requesting and delegating routers  . . . . 18
     8.1.  Delegated prefixes handling  . . . . . . . . . . . . . . . 18
     8.2.  Delegating router behaviour  . . . . . . . . . . . . . . . 18
       8.2.1.  Checking the validity of the PD option . . . . . . . . 18
       8.2.2.  Checking the synchronization of the DPDB . . . . . . . 19
       8.2.3.  Processing the operations  . . . . . . . . . . . . . . 19
     8.3.  Requesting router behaviour  . . . . . . . . . . . . . . . 20
       8.3.1.  Checking the validity of the PD option . . . . . . . . 20
       8.3.2.  Checking the synchronization of the messages
               exchange . . . . . . . . . . . . . . . . . . . . . . . 20
       8.3.3.  Processing the operations  . . . . . . . . . . . . . . 20
   9.  Advertising the ND-PD service  . . . . . . . . . . . . . . . . 21
   10. Messages exchange diagram  . . . . . . . . . . . . . . . . . . 22
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29









Kaiser, et al.           Expires August 29, 2013                [Page 2]


Internet-Draft                    ND-PD                    February 2013


1.  Introduction and motivations

   This document describes a new option that extends ND with a PD
   mechanism.  Using this mechanism, a requesting router can ask for a
   global IPv6 prefix to a delegating router that is present on the same
   link.

   The proposed ND-PD mechanism reaches the same objectives as the
   DHCPv6-PD mechanism described in [DHCPV6_PD], but in a faster and
   less ressources consuming way.  The proposed ND-PD has been initially
   thought and designed for highly mobile networks such as vehicular
   networks, where opportunities for communicating may be quite short.
   Therefore, the less signaling messages are required to auto-configure
   mobile nodes, the more time can be exploited by applications during
   these short communication windows.  Moreover, the default
   availability of the ND protocol in any IPv6 stack makes it a strong
   candidate to handle the PD service rather than implementing an
   additionnal software, especially in hardware and ressources
   constrained devices like sensors or on-board devices.
































Kaiser, et al.           Expires August 29, 2013                [Page 3]


Internet-Draft                    ND-PD                    February 2013


2.  Terminology

   This document uses the terminology defined in [DHCPV6_PD],
   [NEIGHDISC], and [SLAAC].  Also the following additionnal terms are
   used:

   Requesting router:  A router that is asking for prefixes to be
                       delegated.

   Delegating router:  A router that provides prefixes to requesting
                       routers.

   Prefix Information: A logical structure that stores all informations
                       related to a specific prefix.

   DPDB:               The Delegated Prefixes DataBase (DPDB) is a
                       logical structure that stores all prefixes that
                       have been delegated from a specific delegating
                       router along with other informations related to
                       this delegating router.  One DPDB MUST be created
                       on both the requesting and the delegating routers
                       sides for each requesting/delegating routers
                       tuple (see Section 8.1 for more details).




























Kaiser, et al.           Expires August 29, 2013                [Page 4]


Internet-Draft                    ND-PD                    February 2013


3.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [KEYWORDS].














































Kaiser, et al.           Expires August 29, 2013                [Page 5]


Internet-Draft                    ND-PD                    February 2013


4.  Related works

   A few drafts about providing a PD mechanism to the ND protocol have
   already been proposed in the past.

   In [DRAFT_LUTCHANSKY] the author proposes to add a PD option to the
   Router Solicitation (RS) and Router Advertisement (RA) messages
   generated by routers.  A router that needs a global prefix can ask
   for one by including a PD option in a RS message.  Then, a router
   that owns prefixes for delegation replies to the request with a RA
   that includes a PD option.  The main advantage of this proposal is
   that it is very simple and does not require any additionnal message
   to work.  However it lacks of completeness: the handling as well as
   the renewing and releasing of the delegated prefixes are not taken
   into consideration.

   In [DRAFT_HABERMAN] a more complete PD mechanism for ND protocol is
   proposed.  The mechanism is based on two new ICMP messages: the
   Prefix Request and the Prefix Delegation.  The former is used by a
   requesting router to ask for a prefix.  Conversely, the latter is
   used by a delegating router to reply to the request.  The proposal
   also includes the possibility for a requesting router to renew a
   delegated prefix that has not expired yet and to return a delegated
   prefix that is no longer required.

   The proposed ND-PD mechanism that is described in this document is
   close to the one described in [DRAFT_HABERMAN].  However, our
   mechanism relies on the creation of new RS/RA options rather than the
   creation of new ICMP messages.  Also, the ND-PD service provided by a
   router is advertised using the RA flags option [RAFLAGS].  This
   information enable requesting routers to be aware of the presence of
   routers that provide the ND-PD service on link without firstly asking
   for it.


















Kaiser, et al.           Expires August 29, 2013                [Page 6]


Internet-Draft                    ND-PD                    February 2013


5.  Use case example: V2V2I

   Figure 1 shows a vehicular scenario.  Two vehicles are depicted: a
   Leaf Vehicle (LV) and an Internet Vehicle (IV).  Both of them embed a
   various number of Local Fixed Nodes (LFN) (like, for instance,
   sensors) and a Mobile Router (MR) that acts as a gateway between the
   network inside the vehicle and the outdoor.  The main difference
   between the LV and the IV is the number of interfaces that are
   embedded on their MR and, consequently, their (in)ability to connect
   to an infrastructure network.  In this figure, the MR-IV has two
   egress interfaces: one connected to the infrastructure (E2) using a
   long range communication technology (e.g. 3G or LTE) and the other
   one connected to the LV (E1) in an ad-hoc manner using a short range
   communication technology (e.g. 802.11p).

   The objective in the V2V2I use case is to provide an IPv6 end-to-end
   connectivity to the LFN that are embedded in the LV.  To this end, a
   global and topologically correct IPv6 pefix must be advertised by the
   MR-LV on its I1 interface.  The MR-LV gets the required prefix by
   asking for one to the MR-IV using the ND-PD mechanism.  It is assumed
   that the MR-IV is provided with IPv6 prefixes by the infrastructure,
   either using DHCPv6-PD or any other way.

   Details about the messages exchanges generated by ND-PD in the V2V2I
   use case can be found in Section 10, with the MR-LV being the
   requesting router and MR-IV being the delegating router.

























Kaiser, et al.           Expires August 29, 2013                [Page 7]


Internet-Draft                    ND-PD                    February 2013


                                                 +-----------------+
                                                 | INTERNET ACCESS |
                                                 |     VIA THE     |
                                                 | INFRASTRUCTURE  |
                                                 |     NETWORK     |
                                                 +--------+--------+
                                                          |
                                                          |
                                                       E2 |
   +-------------------------+               +-------------------------+
   |                         |               |            |            |
   |                         |               |            |            |
   |      +-----------+      | E1         E1 |      +-----------+      |
   |      |   MR-LV   |------|---------------|------|   MR-IV   |      |
   |      +-----------+      |               |      +-----------+      |
   |         I1 |            |               |         I1 |            |
   |            |            |               |            |            |
   |    --------+--------    |               |    --------+--------    |
   |    |     |         |    |               |    |     |         |    |
   |  LFN-1 LFN-2 ... LFN-x  |               |  LFN-1 LFN-2 ... LFN-x  |
   |                         |               |                         |
   +-------------------------+               +-------------------------+

          Leaf Vehicle                            Internet Vehicle

                       Figure 1: The V2V2I use case

























Kaiser, et al.           Expires August 29, 2013                [Page 8]


Internet-Draft                    ND-PD                    February 2013


6.  Format of the Prefix Delegation option

   This section details the format of the option used in the ND-PD
   mechanism.  This option is only valid if included in RS or RA
   messages and MUST NOT be included in NS, NA, or Redirect messages.

   The Prefix Delegation option is used to manage everything related to
   the delegation of prefixes.  The following operations are considered:

   REQ:     Request operation.  A requesting router asks for a prefix to
            a delegating router.

   REN:     Renew operation.  A requesting router asks the delegating
            router that provided it the prefix to extend its lifetime.

   REL:     Release operation.  A requesting router that does not use
            anymore a delegated prefix informs the delegating router
            that provided it the prefix its intention of releasing it.

   REP:     Reply operation.  A delegating router replies to a message
            sent by a requesting router.

   SYN:     Synchronization operation.  When an error is detected, the
            delegating router sends its DPDB to the requesting router in
            order to re-synchronize their DPDB.

   The Prefix Delegation option is composed of a Prefix Delegation
   header that is followed by a list of Prefix Information (PI).  The
   format of the Prefix Delegation header is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Transac. ID  |   Op. Type    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  N. P. Total  | N. P. cncrnd. |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          List of PI                           .
   .                              ...                              .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:            Value that describes the Prefix Delegation option
                    (TBD: IANA).

   Length:          Size of the option in blocks of 64 bits (according
                    to [NEIGHDISC]) including the fields "Type" and
                    "Length".




Kaiser, et al.           Expires August 29, 2013                [Page 9]


Internet-Draft                    ND-PD                    February 2013


   Transac. ID:     Identifier of the current messages exchange between
                    the requesting router and the delegating router.

   Op. Type:        Describes the type of the operation (REQ, REN, REL,
                    REP or SYN).

   N. P. Total:     The total number of prefixes that have been already
                    delegated by the delegating router to the requesting
                    router (used for synchronization).

   N. P. cncrnd.:   The number of prefixes that are concerned by the
                    operation.

   Reserved:        Unused field.  MUST be set to "0" by sender and
                    ignored by recipient.

   List of PI:      A list of Prefix Informations.

6.1.  Format of the Prefix Information

   A Prefix Information is a structure that holds all informations
   related to a prefix.  The format of the Prefix Information is as
   follow:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix length |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preferred Lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Prefix                             |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Prefix length:          The length of the prefix.

   Reserved:               Unused field.  MUST be set to "0" by sender
                           and ignored by recipient.






Kaiser, et al.           Expires August 29, 2013               [Page 10]


Internet-Draft                    ND-PD                    February 2013


   Preferred Lifetime:     Time length in seconds (relative to the time
                           the packet is sent) during which addresses
                           generated from this prefix remain preferred
                           (see [SLAAC]).  A value of all one bits
                           represents infinity.

   Valid Lifetime:         Time length in seconds (relative to the time
                           the packet is sent) during which the prefix
                           is valid and can be used by nodes for auto-
                           configuration (see [SLAAC]).  A value of all
                           one bits represents infinity.

   Prefix:                 The IPv6 delegated prefix.  All bits in the
                           prefix positionned after the prefix length
                           MUST be set to "0".




































Kaiser, et al.           Expires August 29, 2013               [Page 11]


Internet-Draft                    ND-PD                    February 2013


7.  Operations details

7.1.  Requesting and delegating prefixes

7.1.1.  Request

   A requesting router requests prefixes from a delegating router with
   the REQ operation.  REQ operations are only valid if included in a RS
   message.  This RS message MUST be sent in unicast to a delegating
   router present on link (see Section 9 for delegating routers
   discovery).  The fields of the PD option for a REQ operation MUST be
   filled in with the following values:

   Transac. ID:   An ID of the current messages exchange between the
                  requesting router and the delegating router.  This ID
                  is chosen by the requesting router and MUST be unique
                  among all other current transactions that the
                  requesting router may have started.

   Op. Type:      "REQ".  It is a request for prefixes.

   N. P. Total:   The total number of prefixes that have already been
                  delegated by the delegating router to the requesting
                  router.  This value MUST be set to "0" when requesting
                  prefixes to the delegating router for the first time,
                  even if some prefixes have already been delegated by
                  other delegating routers.

   N. P. cncrnd.: The number of prefixes that are requested by the
                  requesting router.

   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    The list of PI is not necessary with a REQ operation.
                  However, if the requesting router has some preferences
                  about the parameters of the requested prefixes (e.g.
                  the prefix length) it MAY add a PI for each requested
                  prefix that describes its preferences.  For example,
                  if a requesting router requests three prefixes and has
                  a preference for one of the three to have a prefix
                  length of /48, it SHOULD add one PI with the "Prefix
                  Length" field filled in with the value "48".








Kaiser, et al.           Expires August 29, 2013               [Page 12]


Internet-Draft                    ND-PD                    February 2013


7.1.2.  Reply

   A delegating router replies to a REQ operation with a REP operation.
   REP operations are only valid if included in a RA message.  This RA
   message MUST be sent in unicast to the requesting router that
   initiated the message exchange.  The fields of the PD option for a
   REP operation in reply to a REQ operation MUST be filled in with the
   following values:

   Transac. ID:   This ID MUST be the same as the one received with the
                  REQ.

   Op. Type:      "REP".  It is a reply.

   N. P. Total:   The total number of prefixes that have been delegated
                  by the delegating router to the requesting router.
                  This value MUST include the prefixes that are
                  delegated via this message.  For example, if a
                  requesting router has already recceived a prefix from
                  the delegating router and asks for another one, the
                  value of this field MUST be "2" (the previously
                  delegated plus the new one).

   N. P. cncrnd.: The number of prefixes that are delegated via this
                  message.  It may be possible that this value is lower
                  than the one received in the REQ (e.g. if the
                  requesting router requested 3 prefixes but only 2 can
                  be delegated).  If no prefix can be delegated, this
                  field MUST be set to "0".

   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    For each delegated prefix a PI that describes it MUST
                  be added in the list.  If no prefixes are delegated,
                  no PI MUST be added.

7.2.  Renewing prefixes

7.2.1.  Request

   A requesting router renews its delegated prefixes with the REN
   operation.  REN operations are only valid if included in a RS
   message.  This RS message MUST be sent in unicast to the delegating
   router that delegated the concerned prefixes.  The fields of the PD
   option for a REN operation MUST be filled in with the following
   values:




Kaiser, et al.           Expires August 29, 2013               [Page 13]


Internet-Draft                    ND-PD                    February 2013


   Transac. ID:   An ID of the current messages exchange between the
                  requesting router and the delegating router.  This ID
                  is chosen by the requesting router and MUST be unique
                  among all other current transactions that the
                  requesting router may have started.

   Op. Type:      "REN".  It is a renew of prefixes.

   N. P. Total:   The total number of prefixes that have been delegated
                  by the delegating router to the requesting router.

   N. P. cncrnd.: The number of prefixes that are requested to be
                  renewed.  This value MUST be the same as the "N. P.
                  Total" value because the renew operation acts for all
                  the delegated prefixes.

   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    As the REN operation acts for all the delegated
                  prefixes, no list of PI is necessary.

7.2.2.  Reply

   A delegating router replies to a REN operation with a REP operation.
   REP operations are only valid if included in a RA message.  This RA
   message MUST be sent in unicast to the requesting router that
   initiated the message exchange.  The fields of the PD option for a
   REP operation in reply to a REN operation MUST be filled in with the
   following values:

   Transac. ID:   This ID MUST be the same as the one received with the
                  REN.

   Op. Type:      "REP".  It is a reply.

   N. P. Total:   The total number of prefixes that have been delegated
                  by the delegating router to the requesting router.

   N. P. cncrnd.: The number of prefixes that are successfully renewed
                  via this message.  It MAY be possible that this value
                  is lower than the one received in the REN (e.g. if the
                  requesting router requested to renew 3 prefixes but
                  only 2 can be renewed).  If no prefix can be renewed,
                  this field MUST be set to "0".






Kaiser, et al.           Expires August 29, 2013               [Page 14]


Internet-Draft                    ND-PD                    February 2013


   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    The following cases are possible:

                  1.  If no prefix is renewed, the list of PI MUST be
                      empty.

                  2.  If only part of the prefixes are renewed, a PI
                      MUST be added for each successfully renewed
                      prefix.

                  3.  If all the prefixes are renewed, the list of PI is
                      not necessary, except if the parameters of one or
                      more of the renewed prefixes have changed compared
                      with the last delegation/renew time.  As an
                      example, let us consider that the delegating
                      router has delegated two prefixes to the
                      requesting router with preferred and valid
                      lifetimes equal to "10" and "15" respectively.
                      The requesting router now asks for renewing these
                      prefixes.  If both prefixes are renewed for the
                      same amount of time (same preferred and valid
                      lifetimes than previously), no PI SHOULD be added.
                      But, if the prefixes are renewed for a different
                      amount of time (e.g. preferred and valid lifetimes
                      equal to "8" and "12" respectively), a PI MUST be
                      added for each renewed prefix.

7.3.  Releasing prefixes

7.3.1.  Request

   A requesting router releases its delegated prefixes with the REL
   operation.  REL operations are only valid if included in a RS
   message.  This RS message MUST be sent in unicast to the delegating
   router that delegated the concerned prefixes.  The fields of the PD
   option for a REL operation MUST be filled in with the following
   values:

   Transac. ID:   An ID of the current messages exchange between the
                  requesting router and the delegating router.  This ID
                  is chosen by the requesting router and MUST be unique
                  among all other current transactions that the
                  requesting router may have started.






Kaiser, et al.           Expires August 29, 2013               [Page 15]


Internet-Draft                    ND-PD                    February 2013


   Op. Type:      "REL".  It is a release of prefixes.

   N. P. Total:   The total number of prefixes that have been delegated
                  by the delegating router to the requesting router.
                  This value MUST include the prefixes that are included
                  in this message as the release operation has not been
                  successfully processed yet.

   N. P. cncrnd.: The number of prefixes that are requested to be
                  released.

   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    If the REL operation concerns all the prefixes that
                  have been delegated by the delegating router, the list
                  of PI is not needed.  If the REL operation concerns
                  only part of the delegated prefixes, a PI MUST be
                  added for each concerned prefix.

7.3.2.  Reply

   A delegating router does not reply to a REL operation.

7.4.  Prefixes synchronization and error detection

   The SYN operation is sent by a delegating router to a requesting
   router when an error about the DPDB is detected.  SYN operations are
   only valid in a RA message.  This RA message MUST be sent in unicast
   to the requesting router that initiated the message exchange.

   The goal of the SYN operation is to re-synchronize the DPDB of the
   requesting and the delegating router.  Each time a delegating router
   receives a RS message with a PD option, it first starts by checking
   if the total number of delegated prefixes that the requesting router
   has in its DPDB (advertised in the "N. P. Total" field) is the same
   as the one the delegating router has in its DPDB.  If both values are
   the same, the process of the PD option can be continued.  Otherwise,
   an error occurred and both DPDB MUST be re-synchronized (thus the
   operation requested by the requesting router is NOT processed).  The
   rule is simple: the delegating router sends its DPDB back to the
   requesting router via a RA message that includes the PD option with
   the SYN operation.  Upon reception of the message, the requesting
   router updates its DPDB to fit the one advertised by the delegating
   router.  The requesting router MAY then re-send its initial request.

   The fields of the PD option for a SYN operation MUST be filled in
   with the following values:



Kaiser, et al.           Expires August 29, 2013               [Page 16]


Internet-Draft                    ND-PD                    February 2013


   Transac. ID:   This ID MUST be the same as the one received in the PD
                  option of the RS message sent by the requesting
                  router.

   Op. Type:      "SYN".  It is a synchronization operation.

   N. P. Total:   The total number of prefixes that have been delegated
                  by the delegating router to the requesting router.

   N. P. cncrnd.: The number of prefixes that are concerned by this
                  operation.  This value MUST be the same as the one
                  above.

   Reserved:      Unused field.  MUST be set to "0" by sender and
                  ignored by recipient.

   List of PI:    The list of all the PI MUST be added.


































Kaiser, et al.           Expires August 29, 2013               [Page 17]


Internet-Draft                    ND-PD                    February 2013


8.  Local operations on requesting and delegating routers

   Upon reception of a RS or a RA message, requesting and delegating
   routers MUST first check the validity of the message as described in
   section 6.1.  "Message Validation" of [NEIGHDISC].  The processing of
   the message itself along with any option other than the PD option
   described in this document is out of the scope of this document.

8.1.  Delegated prefixes handling

   The delegated prefixes on both the requesting and the delegating
   routers are handled using the DPDB.  The DPDB is a logical structure
   that stores all informations related to a requesting/delegating
   routers tuple.  One and only one DPDB MUST be created for each
   requesting/delegating routers tuple.  The DPDB includes but is not
   restricted to the following informations:

   o  The link-local IPv6 address of the requesting router.

   o  The link-local IPv6 address of the delegating router.

   o  The Transaction ID used in the last RS or RA message received that
      includes a PD option.

   o  The Transaction ID used in the last RS or RA message sent that
      includes a PD option.

   o  The total number of prefixes that have been delegated.

   o  The shortest preferred and valid lifetimes among the delegated
      prefixes (for an easier handling of the renew operation).

   o  The list of all the prefixes that have been delegated (list of
      PI).

8.2.  Delegating router behaviour

8.2.1.  Checking the validity of the PD option

   Upon reception of a RS message that includes a PD option, the
   delegating router MUST first check that the type of operation of the
   PD option is either REQ or REN or REL and that the PD flag (see
   Section 9) is not set.  If one or both of these conditions are not
   met the message MUST be silently discarded.







Kaiser, et al.           Expires August 29, 2013               [Page 18]


Internet-Draft                    ND-PD                    February 2013


8.2.2.  Checking the synchronization of the DPDB

   Before processing the operation, the DPDB synchronization MUST be
   checked.  To this end, the delegating router compares the value of
   the "N. P. Total" field of the PD option with the total number of
   delegated prefixes of its DPDB.  If both values are the same, the
   operation can be processed.  Otherwise, the delegating router MUST
   send back to the requesting router a SYN operation in order to re-
   synchronize both DPDB.

8.2.3.  Processing the operations

   If the PD option includes a REQ operation, the delegating router
   checks its possibility to delegate the requested prefixes to the
   requesting router.  For each successfully delegated prefix the
   delegating router MUST add in its routing table one entry with the
   following parameters: the destination network is the delegated prefix
   and the next-hop is the IPv6 address of the requesting router.  The
   delegating router MUST then reply with a RA message that includes a
   PD option with the REP operation filled accordingly.  While the
   delegated prefixes are not released (either with a REL operation or
   when their valid lifetime has expired) they MUST NOT be delegated
   again.

   If the PD option includes a REN operation, the delegating router
   checks its possibility to renew all the prefixes present in the DPDB.
   For each successfully renewed prefix, the delegating router MUST
   update the corresponding entry in its routing table.  The delegating
   router MUST then reply with a RA message that includes a PD option
   with the REP operation filled accordingly.

   If the PD option includes a REL operation, the delegating router MUST
   release the corresponding prefixes.  For each successfully released
   prefix, the delegating router MUST delete the corresponding entry in
   its routing table.

   If the delegating router detects that one or more of the prefixes
   specified by the requesting router in the REN or REL operations are
   not valid, the delegating router MUST NOT process the operation and
   MUST send back to the requesting router a SYN operation to re-
   synchronize the DPDB.

   When the Valid Lifetime of a delegated prefix has expired, the
   delegating router MUST update its routing table by removing the
   corresponding entry.  The expired prefix is then available for future
   delegation.





Kaiser, et al.           Expires August 29, 2013               [Page 19]


Internet-Draft                    ND-PD                    February 2013


8.3.  Requesting router behaviour

8.3.1.  Checking the validity of the PD option

   Upon reception of a RA message that includes a PD option, the
   requesting router MUST first check that the type of operation of the
   PD option is either REP or SYN and that the PD flag is set (see
   Section 9).  If one or both of these conditions are not met the
   message MUST be silently discarded.

8.3.2.  Checking the synchronization of the messages exchange

   In order to ensure that the received RA message is a reply to the
   initiated request, the requesting router MUST check that the
   "Transac.  ID" of the received message fits the one it generated for
   its last request.

8.3.3.  Processing the operations

   If the PD option includes a REP operation, the requesting router is
   free of advertising the prefixes included in the REP message on any
   of its interfaces except the one from which the REP message was
   received.  For each prefix that is advertised on an interface, the
   requesting router MUST add an entry in its routing table with the
   following parameters: the destination network is the advertised
   prefix and the output interface is the one where the prefix is
   advertised.

   If the PD option includes a SYN operation, the requesting router MUST
   update its DPDB with the inputs included in the RA message along with
   its routing table entries.  The requesting router MAY then re-send
   its initial request.

   When the Valid Lifetime of a delegated prefix has expired, the
   requesting router MUST update its routing table by removing the
   corresponding entry.  Also the requesting router MUST stop
   advertising this prefix on the corresponding interface.














Kaiser, et al.           Expires August 29, 2013               [Page 20]


Internet-Draft                    ND-PD                    February 2013


9.  Advertising the ND-PD service

   Each delegating router that delegates prefixes using the ND-PD
   mechanism described in this document MUST advertise this service by
   adding the new PD flag (for Prefix Delegation) in each RA message it
   sends.  The PD flag MUST be advertised using the RA flags option
   described in [RAFLAGS].












































Kaiser, et al.           Expires August 29, 2013               [Page 21]


Internet-Draft                    ND-PD                    February 2013


10.  Messages exchange diagram

   This section depicts the messages exchanges generated by ND-PD
   between a requesting router and a delegating router.  Values under
   "N. P. Total" represent the current total number of delegated
   prefixes that each router has in its DPDB.  All messages shown in
   this example include a PD option (except the periodic RA message).
   For each of those messages, the type of operation as well as the
   corresponding PI that are carried out by the PD option are pointed
   out.

            +--------+                  +--------+
            |  Req.  |                  |  Del.  |
            | Router |                  | Router |
            +--------+                  +--------+
                |                           |
   N. P. Total  |                           |  N. P. Total
        0       |                           |       0
                | periodic RA - flag PD set |
                |<--------------------------|
                |                           |
                .                           .
                .                           .
                .                           .
                |                           |
                |         RS - REQ          |
                |-------------------------->|
        0       |                           |       0
                |     RA - REP(P1,P2)       |
                |<--------------------------|
        2       |                           |       2
                |                           |

   The delegating router sends periodic RA messages with the PD flag
   set.  Upon reception of such message, the requesting router knows
   that the delegating router provides the ND-PD service.  At some
   point, the requesting router asks for two prefixes.  The delegating
   router accepts the request and delegates prefixes P1 and P2.  Both
   DPDB are updated: the total number of delegated prefix for this tuple
   of requesting/delegating routers is set to 2.

                |                           |
                |         RS - REQ          |
                |-------------------------->|
        2       |                           |       2
                |       RA - REP(P3)        |
                |     X---------------------|
        2       |                           |       3



Kaiser, et al.           Expires August 29, 2013               [Page 22]


Internet-Draft                    ND-PD                    February 2013


                |                           |

   Let us consider that the delegating router now needs one more prefix.
   It asks for a new prefix to the delegating router.  The delegating
   router accepts the request and replies with the new delegated prefix
   P3.  However, for some reasons, this message never arrives to the
   requesting router.  Only the DPDB of the delegating router is
   updated: the delegating router has delegated three prefixes to the
   requesting router but this latter owns only two of them.

                |                           |
                |         RS - REN          |
                |-------------------------->|
        2       |                           |       3
                |    RA - SYN(P1,P2,P3)     |
                |<--------------------------|
        3       |                           |       3
                |                           |

   Let us assume that the Preferred Lifetime of P1 and P2 is now over.
   However, the requesting router would like to keep both prefixes
   active for more time.  Hence, it asks the delegating router to renew
   its delegated prefixes.  Upon checking the synchronization of the
   DPDB, the delegating router detects that the total number of
   delegated prefixes is not the same.  Therefore, the delegating router
   replies with a SYN operation in order to re-synchronize both DPDB.

                |                           |
                |         RS - REN          |
                |-------------------------->|
        3       |                           |       3
                |      RA - REP(P1,P3)      |
                |<--------------------------|
        2       |                           |       2
                |                           |

   Now that both DPDB are re-synchronized, the requesting router asks
   once again for renewing its delegated prefixes.  For some reasons,
   the delegating router accepts the renew only for P1 and P3 and
   replies consequently.  Both DPDB are updated.

                |                           |
                |       RS - REL(P3)        |
                |-------------------------->|
        1       |                           |       1
                |                           |

   Finally, the requesting router does not need anymore P3.  It thus



Kaiser, et al.           Expires August 29, 2013               [Page 23]


Internet-Draft                    ND-PD                    February 2013


   releases it and both DPDB are updated.


















































Kaiser, et al.           Expires August 29, 2013               [Page 24]


Internet-Draft                    ND-PD                    February 2013


11.  Security Considerations

   This section describes the security issues related to prefix
   delegation using ND_PD.

   The ND_PD mechanism is prone to attacks that may target either the
   requesting router or the delegating router, particularly by launching
   denial-of-service (DoS) attacks as discussed in [DHCPV6_PD].  If the
   requesting router is malicious, it may repeatedly request prefixes to
   a delegating router until the exhaustion of all the available
   prefixes.  This attack could be launched with the same requesting
   router identity or with different spoofed link addresses.  On the
   other side, a malicious delegating router may issue bogus prefixes to
   the requesting router which may cause DoS due to unreachability.
   Furthermore, the delegated prefixes could be eavesdropped, suppressed
   or altered during their transmission to the requesting router,
   whereby external attackers aim at using spoofed IP addresses or
   launching DoS attacks in the network.

































Kaiser, et al.           Expires August 29, 2013               [Page 25]


Internet-Draft                    ND-PD                    February 2013


12.  IANA Considerations

   IANA is kindly requested by the authors to allocate the following
   values:

   o  Prefix Delegation option type, which should be added to the
      Neighbor Discovery option type space defined in section 13 of
      [NEIGHDISC]

   o  Prefix Delegation operation types:

      *  REQ

      *  REN

      *  REL

      *  REP

      *  SYN

   o  Space allocation for the PD flag in the RA flags option.





























Kaiser, et al.           Expires August 29, 2013               [Page 26]


Internet-Draft                    ND-PD                    February 2013


13.  Acknowledgements

   The authors would like to acknowledge the useful technical
   contribution of Sofiane Imadali.

   This work has been performed in the framework of the ICT project ICT-
   5-258512 EXALTED, which is partly funded by the European Union.  The
   organisations on the source list [CEA] would like to acknowledge the
   contributions of their colleagues to the project, although the views
   expressed in this contribution are those of the authors and do not
   necessarily represent the project.








































Kaiser, et al.           Expires August 29, 2013               [Page 27]


Internet-Draft                    ND-PD                    February 2013


14.  References

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [DHCPV6_PD]
              Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCPv6) version 6", RFC 3633,
              December 2003.

   [NEIGHDISC]
              Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [SLAAC]    Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [DRAFT_LUTCHANSKY]
              Lutchansky, N., "IPv6 Router Advertisement Prefix
              Delegation Option",
              draft-lutchann-ipv6-delegate-option-00.txt ,
              February 2002.

   [DRAFT_HABERMAN]
              Haberman, B. and J. Martin, "Automatic Prefix Delegation
              Protocol for Internet Protocol Version 6 (IPv6)",
              draft-haberman-ipngwg-auto-prefix-02.txt , February 2002.

   [RAFLAGS]  Haberman, B. and R. Hinden, "IPv6 Router Advertisement
              Flags Option", RFC 4861, March 2008.



















Kaiser, et al.           Expires August 29, 2013               [Page 28]


Internet-Draft                    ND-PD                    February 2013


Authors' Addresses

   Arnaud Kaiser
   Commissariat a l'Energie Atomique
   8 Avenue de la Vauve
   Palaiseau, Ile-de-France  91120
   FR

   Email: arnaud.kaiser@cea.fr


   Sylvain Decremps
   Commissariat a l'Energie Atomique
   8 Avenue de la Vauve
   Palaiseau, Ile-de-France  91120
   FR

   Email: sylvain.decremps@cea.fr


   Nouha Oualha
   Commissariat a l'Energie Atomique
   8 Avenue de la Vauve
   Palaiseau, Ile-de-France  91120
   FR

   Email: nouha.oualha@cea.fr


   Alexandru Petrescu
   Commissariat a l'Energie Atomique
   8 Avenue de la Vauve
   Palaiseau, Ile-de-France  91120
   FR

   Email: alexandru.petrescu@cea.fr















Kaiser, et al.           Expires August 29, 2013               [Page 29]