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

Versions: 00 01                                                         
Individual Submission                                    Byung-Yeob Kim
Internet-Draft                                           Kyeong-Jin Lee
                                                          Jung-Soo Park
                                                         Hyoung-Jun Kim
<draft-bykim-ipv6-hpd-01.txt>                                      ETRI
Expires: August 2004                                   15 February 2004


                  Hierarchical Prefix Delegation Protocol
                  for Internet Protocol Version 6 (IPv6)


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   Stateless Autoconfiguration enables IPv6 hosts to send a request for
   a prefix, a network identifier to a router on the subnet.  Using this
   ability a host can configure its IPv6 address.  Likewise, by defining
   a way to request for a prefix to an upper level router, a router can
   get a prefix to be assigned to its subnet.

   This document describes a protocol for prefix delegation between
   routers.  It allows routers get prefixes from its upstream routers,
   enabling the entire network and its belonging hosts autoconfigure
   their own addresses.






Kim, et al.             Expires - August 2004                [Page 1]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].


Table of Contents

   1. Terminology...................................................2
   2. Introduction..................................................3
   3. Protocol Overview.............................................3
      3.1  Prefix Negotiation.......................................3
      3.2  Prefix Delegation........................................4
      3.3  Router Authentication....................................4
      3.4  Prefix Return............................................4
      3.5  Built-in Routing.........................................5
   4. Messages......................................................5
      4.1  Prefix Request Message...................................5
      4.2  Prefix Delegation Message................................7
      4.3  Prefix Information Option................................9
   5. Security Consideration.......................................10
   6. IANA considerations..........................................10
   7. Acknowledgements.............................................10
   8. Copyright....................................................11
   9. References...................................................11
   10. Authors' Addresses...........................................12


1. Terminology

   This document uses the terminology defined in [RFC 2460] and [RFC
   2461] with the following new terms:


     Requesting Router

        The router requesting prefixes to be assigned for its subnets.

     Delegating Router

        The router responding to the Prefix request.

     Root Router

        The Root Router is placed on top of the network hieararchy
        where the Hierarchical Prefix Delegation begins.  Only the Root



Kim, et al.             Expires - August 2004                [Page 2]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


        Router requires manual administration and is assumed to have an
        interface to the Global Internet.  The Root Router is a
        Delegating Router.


2. Introduction

   This specification defines the Hierarchical Prefix Delegation (HPD)
   protocol for Internet Protocol Version 6 (IPv6).  It is an extended
   prefix delegation protocol based on Automatic Prefix Delegation
   Protocol first introduced by B. Haberman and J. Martin [APD].  It
   retains basic prefix delegation abilities of its predecessor with a
   couple of following extensions:

        Extended Prefix Delegation - Prefix Delegation is not limited
        to a leaf router.  Once a Requesting Router receives a prefix
        from its upstream router, it can play the role of the
        Delegating Router.  It provides its downstream routers with
        parts of its address space by delegating longer level prefixes,
        enabling multiple-level hierarchical prefix delegation.

        Built-in Routing capability - The Hierarchical Prefix
        Delegation protocol (HPD) provides routing capability that
        enables routing on "HPDed" routers without external routing
        protocols such as RIP or OSPF.


3. Protocol Overview

   The Hierarchical Prefix Delegation protocol defines two new ICMPv6
   message types, the Prefix Request and the Prefix Delegation.  The
   Prefix Request is used by the Requesting Router to send requests to
   the Delegating Router. Conversely, the Prefix Delegation is used by
   the Delegating Router to send prefixes and other information to the
   Requesting Router.  The actual prefix delivery is made by Prefix
   Information Option included in these messages.


3.1 Prefix Negotiation

   The Requesting Router begins the Hierarchical Prefix Delegation
   protocol by sending a Prefix Request message of code "Delegator
   Query" to the All-routers link-local multicast address (FF02::2).
   The Requesting Router SHOULD specify the number of prefixes it wishes
   to receive.

   Upon receiving the "Delegator Query" the Delegating Router determines
   if it has enough available prefixes.  If so, it unicasts a Prefix


Kim, et al.             Expires - August 2004                [Page 3]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


   Delegation message of code "Prefix Delegator" back to the Requesting
   Router.  The message MUST contain the number of available prefixes,
   their prefix length and the prefix length difference.  If more than
   one reply is received from multiple Delegating Routers, the
   Requesting Router SHOULD choose the one with the shorter prefix
   length.

   Note that these messages are for negotiation purpose only.  Actual
   prefix delivery is not provided in this phase.

3.2 Prefix Delegation

   Once a Delegating Router is chosen, the Requesting Router sends a
   Prefix Request message of code "Initial Request" to the unicast IP
   address of the Delegating Router.  The Requesting Router MUST confirm
   the prefix length and the prefix difference by sending back these
   parameters in the message.  The number of requesting prefixes MUST be
   less than or equal to the number of prefixes in the received "Prefix
   Delegator."

   Upon receiving the "Initial Request" the Delegating Router replies by
   sending Prefix Delegation message with a code of "Prefix Delegated."
   The message MUST include one or more Prefix Information Options.

3.3 Router Authentication

   Depending on local administration policy, the Delegating Router can
   mandate the use of Cryptographically Generated Address (CGA) as a
   Source Address.  For "Initial Request" without an authorized Source
   Address, the Delegating Router returns Prefix Delegation message with
   a code of "Authentication Required."  A Requesting Router receiving
   this message MAY reinitiate the request by sending Prefix Request
   message with a valid CGA address.

   A Delegating Router who has received a message with a CGA as a source
   address MUST verify its validity.  For messages with invalid CGA the
   Delegating Router SHOULD reply back a Prefix Delegation message with
   a code of "Authentication Failed."

3.4 Prefix Return

   A Requesting Router SHOULD return the delegated prefixes when it does
   not need them any more.  It sends Prefix Request message with a code
   of "Prefix Returned" to Delegating Router.  Returning prefixes MUST
   be stored in Prefix Information Options included in the message.

   Once a prefix is returned, the Delegating Router replies back with a
   Prefix Delegation message with code "Prefix Returned."  Returning


Kim, et al.             Expires - August 2004                [Page 4]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


   prefixes SHOULD be contained in Prefix Information Options for
   confirmation.  Once a prefix is returned, the prefix belongs to the
   Delegating Router and the Delegating Router recycles it.

   A Requesting Router can extend the life time of a prefix by sending
   Prefix Request message with a code of "renewal Request."  Expired
   prefixes MUST NOT be used anymore and SHOULD be considered to be
   returned by the Delegate Router.

3.5 Built-in Routing

   The Root Router MAY run with a built-in routing option.  When this
   option is turned on, the Root Router and its all subsidiary
   Delegating Routers keep track of delegated prefixes, being aware of
   which subnet is being used on which interface.

   Using longest matching, packets with a source address of delegated
   prefix will be forwarded to the corresponding downstream router.
   Packets with an unidentified destination will be sent to the upstream
   router.  This option MUST be set initially by the administrator when
   the Root Router starts bootstrapping and SHOULD be inherited to its
   subsidiary routers.


4. Messages

   All messages have the following general format:

     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             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   PrefixCnt   |   PrefixLen   |   PrefixDiff  |R|  Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                  Prefix Information Option                    +
    |                                                               |


4.1 Prefix Request Message

   The Prefix Request Message is used to request, renew, or return
   prefixes.

   IP Fields

      Source Address


Kim, et al.             Expires - August 2004                [Page 5]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


        A Cryptographically Generated Address (CGA) or an ordinary IP
        address assigned to the sending interface.

      Destination Address
        The All-Routers link-local multicast address (FF02::2) for
        Delegator Query messages.  All other Prefix Request messages
        should be sent to a unicast address of the Delegating Router.

   ICMP Fields

      Type
        TBD <To be assigned by IANA>

      Code
         The Type of code:

         Delegator Query (0)
           The Delegator Query is used by the Requesting Router to
           identify potential Delegating Routers.  It is sent to the
           all-routers link-local multicast address.  The requesting
           router MAY specify the number of prefixes it is requesting
           in PrefixCnt field.

         Initial Request (1)
           The Initial Request is to initiate the request process.  It
           is sent to the unicast IP address of the Delegating Router.
           The PrefixLen and PrefixDiff fields MUST have the same value
           received through the Prefix Delegator message while
           PrefixCnt has less or equal value as the Prefix Delegator
           message.

         Renewal Request (2)
           The Renewal Request is to renew the lifetime of prefixes
           that have been previously allocated.  It is sent to the
           unicast IP address of the Delegating Router.  One or more
           Prefix Information Options MUST be included for this message.

         Prefix Return (3)
           The Prefix Return is used to return prefixes to the
           Delegating Router.  It is sent to a unicast IP address of
           the Delegating Router.  One or more Prefix Information
           Options MUST be included for this message.

      Checksum
         The ICMP checksum as defined in RFC [2463].

      PrefixCnt



Kim, et al.             Expires - August 2004                [Page 6]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


        For messages with the code of "Delegator Query" or "Initial
        Request," The PrefixCnt indicates the number of prefixes the
        Requesting Router is requesting for.  Otherwise, it denotes the
        number of Prefix Information options attached to the message.

      PrefixLen
        The PrefixLen indicates the length of the prefix.  For a
        "Prefix Request" message with a code of "Initial Request," it
        must be the same value as the PrefixLen received through the
        previously received Prefix Delegation message with code of
        "Prefix Delegator."  For other Prefix Request messages, it MUST
        be set to zero.

      PrefixDiff
        The PrefixDiff is used to confirm the PrefixDiff value received
        through the Prefix Delegation message with code of "Prefix
        Delegator."  For other Prefix Request messages it MUST be set
        to zero.

      R
        The R flag is not used in this message.

      Reserved
        Reserved for future use. Must be set to zero.

4.2 Prefix Delegation Message

   The Prefix Delegate Message is used to provide the Requesting Router
   with prefixes and other valuable information like error returns.

   IP Fields

      Source Address
        A Cryptographically Generated Address (CGA) or an ordinary IP
        address assigned to the sending interface.

      Destination Address
        The IP address of the Requesting Router specified by the Source
        Address in the Prefix Request message.


   ICMP Fields

      Type
         TBD <To be assigned by IANA>

      Code
         The Type of Response Code:


Kim, et al.             Expires - August 2004                [Page 7]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004



         Prefix Delegator (0)
           The Prefix Delegator is to inform the Requesting Router the
           number of available prefixes. It is sent to the unicast IP
           address specified in the Source Address portion of the
           Prefix Request message.  The number of available prefixes is
           specified in the PrefixCnt field.  The PrefixCnt of zero
           indicates that Prefix Delegator does not have available
           prefix at all.  The Delegating Router MUST specify the
           length of the available prefixes and the difference of the
           prefix lengths between the Delegating Router and the
           Requesting Router as well.

         Authentication Required (1)
           The Authentication Required is use to inform the Requesting
           Router that a Cryptographically Generated Address must be
           used as a source address.  It is sent to the unicast IP
           address in the Source Address portion of the Prefix Request
           message.  Unused fields must be initialized to zero.

         Authorization Failed (2)
           The Authorization Failed is use to inform the Requesting
           Router that its source address is failed to be verified.  It
           is sent to the unicast IP address in the Source Address
           portion of the Prefix Request message.  Unused fields must
           be initialized to zero.

         Prefix Delegated (3)
           The Prefix Delegated delivers the actual prefixes the
           Requesting Router has requested. It is sent to the unicast
           IP address in the Source Address portion of the Prefix
           Request message. One or more Prefix Information Options MUST
           be included for this message.

         Prefix Returned (4)
           The Prefix Returned is used to confirm the return of the
           prefixes.  It is sent to the unicast IP address in the
           Source Address portion of the Prefix Request message.  One
           or more Prefix Information Options MUST be included for this
           message.

      Checksum
         The ICMP checksum as defined in [RFC 2463].

      PrefixCnt
        For the message with a code of "Prefix Delegator," The
        PrefixCnt indicates the number of prefixes the Delegating



Kim, et al.             Expires - August 2004                [Page 8]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


        Router is to offer.  Otherwise, it denotes the number of Prefix
        Information options attached to the Prefix Delegation message.

      PrefixLen
        The PrefixLen indicates the length of the prefix.  For a
        message with a code of "Prefix Delegator," The PrefixLen
        indicates the length of prefixes the Delegating Router is to
        offer. For other Prefix Delegation messages it MUST be set to
        zero.

      PrefixDiff
        The PrefixDiff indicates the prefix length difference between
        the Requesting Router and the Delegating Router, configured by
        an administrator.  Initially it is set by the administrator on
        the Root Router and will be inherited over routers down to the
        leaf routers.

      R
        The R flag is used to inform the Requesting Router to use
        built-in routing.

      Reserved
        Reserved for future use. Must be set to zero.

4.3 Prefix Information Option

   The Prefix Information Option is used to relay prefix between
   Requesting Router and Delegating Router.  A message doing prefix
   delievery contains exact the same number of the options as specified
   in the PrefixCnt field.

   It has the following format:

      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     |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Prefix Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                             Prefix                            +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Kim, et al.             Expires - August 2004                [Page 9]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004




   Prefix Option Fields

      Type
        TBD <To be assigned by IANA>
        This field indicates the presence of a Prefix Information.

      Length
        The length of the prefix contained in this option.

      Reserved
        Reserved for future use.  This field must be set to zero.

      Prefix Lifetime
        The lifetime of the prefix contained in the option.

      Prefix
        This field contains an IPv6 Prefix.  The portion of bits longer
        than the specified length MUST be filled with zero.


5. Security Consideration

   Prefix Delegation opens up several vulnerabilities.  A node may
   attempt to request prefixes to deplete Delegating Router's prefix
   pool.  On the other hand a node may reply to the Delegation Request
   with certain short-length prefixes to disrupt the delegation.

   In order to prevent illicit nodes, Routers using Hierarchical Prefix
   Delegation Protocol need an authentication method.  Using
   Cryptographically Generated Address as a Source Address is suggested
   for this purpose.  Using CGA option and signature option devised by
   Secure Neighbor Discovery working group [SEND] is RECOMMENDED in this
   case.  Employing other options being articulated in the working group
   is also preferable for better security.


6. IANA considerations

   This document defines two new ICMP message types and one ICMP Option
   type.  They must be assigned ICMPv6 type numbers.


7. Acknowledgements

   We would like to acknowledge B. Haberman and J. Martin for their
   invention of the Automatic Prefix Delegation Protocol which this


Kim, et al.             Expires - August 2004               [Page 10]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


   draft is based on.  We would also like to thank Wan-Jik Lee and Seok-
   Yeul Heo for their implementation efforts on Hierarchical Prefix
   Delegation Protocol on Linux OS.


8. Copyright

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this
   document.

   Copyright (C) The Internet Society July 12, 2001.  All Rights
   Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


9. References

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

   [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor


Kim, et al.             Expires - August 2004               [Page 11]


Internet-Draft  Hierarchical Prefix Delegation Protocol  February 2004


              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC 2463] A. Conta and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [CGA]      T. Aura, "Cryptographically Generated Addresses (CGA) ",
             working in pregress, <draft-ietf-send-cga-01.txt>

   [SEND]     J. Arkko, "SEcure Neighbor Discovery (SEND) ",
             working in progress, <draft-arkko-send-ndopt-01.txt>

   [APD]      B. Haberman and J. Martin, "Automatic Prefix Delegation
              Protocol for Internet Protocol Version 6", expired,
             <draft-haberman-ipngwg-auto-prefix-02.txt>


10.  Authors' Addresses

   Byung-Yeob Kim
   skylane@etri.re.kr
   Phone: +82 42 860 6627

   Kyeong-Jin Lee
   leekj@etri.re.kr
   Phone: +82 42 860 6484

   Jung-Soo Park
   pjs@etri.re.kr
   Phone: +82 42 860 6514

   Hyoung-Jun Kim
   khj@etri.re.kr
   Phone: +82 42 860 6576


   Protocol Engineering Center,
   Electronics and Telecommunications Research Institute (ETRI)
   161 Gajeong-Dong, Yuseong-Gu
   Daejon 305-350
   Republic of Korea








Kim, et al.             Expires - August 2004               [Page 12]