One document matched: draft-bykim-ipv6-hpd-01.txt
Differences from draft-bykim-ipv6-hpd-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 14:58:41 |