Internet DRAFT - draft-arunt-prefix-delegation-using-icmpv6
draft-arunt-prefix-delegation-using-icmpv6
Network Working Group Arun Thulasi
Internet-Draft Shankar Raman
Hewlett-Packard
April 2004
IPv6 Prefix Delegation Using ICMPv6
<draft-arunt-prefix-delegation-using-icmpv6-00.txt>
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.
This Internet-Draft will expire on October 24, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a Prefix Delegation Mechanism which
delegates IPv6 prefixes to a subscriber's network (or "site") by an
Internet Service Provider (ISP). It uses ICMPv6 messages to handle
Prefix Delegation between the Delegating Router and the Requesting
Router.
Table of Contents
1. Introduction............................................ 3
2. Terminologies and Definitions........................... 3
2.1 Basic Terminologies and Setup........................ 3
2.2 Mechanism Specific Terminology....................... 4
3. Alignment with Requirements............................. 5
3.1 Number and Length of Delegated Prefixes.............. 5
3.2 Use of Delegated Prefixes in Customer Network........ 5
Arun & Shankar Expires October 30, 2004 [Page 1]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
3.3 Static and Dynamic Assignment........................ 5
3.4 Policy-based Assignment.............................. 5
3.5 Expression of Requirements or Preferences by
the CPE.............................................. 5
3.6 Security Mechanism................................... 6
3.7 Accounting........................................... 6
3.8 Hardware Technology Considerations................... 6
4. Message Types........................................... 6
4.1 Prefix Solicitation.................................. 6
4.2 Prefix Delegation.................................... 8
4.3 Option Formats....................................... 10
4.3.1 Source Link-layer Address Option................ 11
4.3.2. Arbitrary Delegation Request Option............. 11
4.3.3. Block Delegation Request Option................. 13
4.3.4. Individual Prefix Delegation Request
Option.......................................... 16
4.3.5. Block Delegation Response Option................ 18
4.3.6. Individual Prefix Delegation Response
Option.......................................... 19
5. Prefix Delegation Mechanism and Overview................ 20
5.1 Conceptual Data Structures........................... 20
5.2 States of Prefixes................................... 21
5.3 Conceptual Sending Algorithm......................... 22
6. Requesting Router Specification......................... 23
6.1 Prefix Solicitation by a Requesting Router........... 23
6.1.1 Prefix Solicitation Header Specification........ 23
6.1.2 Prefix Solicitation Option Specification........ 24
6.2 Prefix Delegation Acknowledgement & Returning
by a Requesting Router............................... 25
6.2.1 Prefix Delegation Acknowledgement Header
Specification................................... 25
6.2.2 Prefix Delegation Acknowledgement Option
Specification................................... 25
6.3 Prefix Renewal by a Requesting Router................ 25
6.3.1 Prefix Solicitation Header Specification........ 26
6.3.2 Prefix Solicitation Option Specification........ 26
6.4 Prefix Delegation Message Validation by
Requesting Router.................................... 27
6.4.1 Prefix Delegation Header Validation............. 27
6.4.2 Prefix Delegation Option Validation............. 27
6.5 Configurable Parameters for Requesting Router........ 28
7. Delegating Router Specification......................... 28
7.1 Prefix Delegation by a Delegating Router............. 28
7.1.1 Prefix Delegation Header Specification.......... 28
7.1.2 Prefix Delegation Option Specification.......... 29
7.2 Prefix Revoking by a Delegating Router............... 29
7.2.1 Prefix Revoking Header Specification............ 29
7.2.2 Prefix Delegation Option Specification.......... 29
7.3 Prefix Solicitation Message Validation by
Delegating Router.................................... 30
7.3.1 Prefix Solicitation Header Validation........... 30
Arun & Shankar Expires October 30, 2004 [Page 2]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
7.3.2 Prefix Solicitation Options Validation.......... 30
7.4 Configurable Parameters for Delegating Router.......... 31
8. IANA Considerations........................................ 31
9. Security Considerations.................................... 32
References.................................................... 32
Authors' Addresses............................................ 32
Appendix A: Usage of Service Bands and Discretion Flag........ 33
Appendix B: Implementation Suggestions on Usage of
Prefix States..................................... 33
Appendix C: Future Options.................................... 33
Full Copyright Statement...................................... 34
Acknowledgements.............................................. 34
1. Introduction
With the introduction of IPv6 [IPv6], the address space for nodes has
increased manifold. With such an increased address space several
ISPs would be ready to provide the IPv6 access to the public. With
such a task in mind, a requirements draft specifying Requirements
for IPv6 Prefix Delegation [PDReq] was written. It specifies the
requirements for an efficient mechanism to delegate prefixes from the
ISP's site to the customer's site. It also mentions that the
delegating mechanism should automate the process of informing the
customer's networking equipment of the prefixes to be used at the
customer's site.
This document describes a mechanism to delegate prefixes from PE to
CPE.
2. Terminologies and Definitions
2.1 Basic Terminologies and Setup
The following figure illustrates a likely example for the
organization of a network providing subscription IPv6 service:
/------\
/ \
+ |
/ \ /
+---------------+ +--------+/ \------/
|ISP Edge Router|Point-to-point|Customer+
| +--------------+ Router | Customer networks
| (PE) | link | (CPE) +
+---------------+ +--------+\ /------\
\ / \
+ |
\ /
\------/
Figure 1: Illustration of ISP-customer network architecture
Arun & Shankar Expires October 30, 2004 [Page 3]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
|
<----- ISP Premises ---->|<----- Customer Premises ---->
|
+---------------+ Request|Prefix +------------+
| Delegating |<-------|--------| Requesting |
| Router |--------|------->| Router |
+---------------+Delegate| Prefix +------------+
| /Customer\
| / Networks \
| /--------\ /---------\
| + + + +
| \--------/ \---------/
Figure 2: Illustration of relationship between a Requesting Router
and a Delegating Router
PE: Provider edge device; the device connected to the service
provider's network infrastructure at which the link to the
customer site is terminated
CPE: Customer premises equipment; the device at the customer site at
which the link to the ISP is terminated
RR: Requesting Router; the router on the customer's end which makes
the requests to the CPE. It could also be a single machine which
requires a prefix for it's own address.
DR: Delegating Router; the router on the ISP's end which delegates
the addresses to the RR.
2.2 Mechanism Specific Terminology
Prefix Solicitation(PS) - A message type with which a RR makes a
request to the DR to allocate a set of prefixes for itself.
Prefix Delegation(PD) - A message type with which a DR delegates a
set of prefixes to an RR. This may or may not be in response to a
PS message.
Arbitrary Delegation(AD) - A type of delegation where the CPE does
not have any particular preference over any prefix, but requires
just an arbitrary number of prefixes at a specified prefix length.
Block Delegation(BD) - A type of delegation where the CPE prefers
that its prefixes be within a specified range and with a specified
prefix length.
Individual Delegation(ID) - A type of delegation where the CPE
requires a certain individual prefix at a specified length.
Arun & Shankar Expires October 30, 2004 [Page 4]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
3. Alignment with Requirements
The mechanism specified in this document intends to solve the
requirements issues specified in [PDReq]. A summary of the
requirements and the solutions are as below.
3.1 Number and Length of Delegated Prefixes
The mechanism specified allows the CPE to request multiple prefixes
with multiple prefix lengths for each type of prefix requested.
It also allows the CPE to make prefix requests in different formats
with different preferences in one single request.
3.2 Use of Delegated Prefixes in Customer Network
In the mechanism specified, the PE does not impose any rule or
restrictions on the creation of longer, different prefixes by
the CPE once it has been delegated a given set of prefixes.
It allows the CPE to form its own set of prefixes from the set
of prefixes that were delegated to it by the PE and further
delegate them inside the customer's network.
3.3 Static and Dynamic Assignment
The mechanism specified would be capable of handling both static,
long-lived pre-assignment of addresses and dynamic, short-lived,
on-demand assignment of prefixes to a customer. Pre-assignment of
addresses refers to a case where the number of prefixes to be
delegated to the Requesting Router (RR) are determined before the
first request is made from the RR to the Delegating Router (DR).
An example could be a case where the CPE is assigned a set of
prefixes after completing a process of registration over paper.
The mechanism specified differentiates between static and dynamic
prefixes based on the requested/assigned valid lifetimes of the
prefixes.
3.4 Policy-based Assignment
The mechanism specified would allow the PE to perform policy based
assignment of prefixes to the CPE. This policy may include decisions
that determine the number, length and valid lifetimes that could be
assigned to a particular CPE. Using such policies, the PE should be
able to serve a CPE's request as requested or it could serve it as
best as it could.
3.5 Expression of Requirements or Preferences by the CPE
The mechanism specified would allow the CPE to specify the various
preferences that it has over the prefix that it requests. These
preferences include
- An arbitrary number of prefixes for a specified length
- A block of contiguous prefixes within the address space, each
such block with a certain prefix length.
- An individual prefix that is fully specified, with a certain
Arun & Shankar Expires October 30, 2004 [Page 5]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
prefix length.
3.6 Security Mechanism
The mechanism specified allows the CPE and the PE to use supported
security mechanisms. For example, ICMP protocol packet exchanges can
be authenticated using the IP Authentication Header [IPv6-AUTH] or IP
Encapsulating Security Payload Header [IPv6-ESP].
3.7 Accounting
The mechanism specified would allow the PE to obtain various
accounting information about the prefixes delegated.
3.8 Hardware Technology Considerations
The mechanism specified does not have any known hardware
technological limitations and would work on any hardware technology
between the CPE and PE. It does not post any restrictions on the
ISP's ability to utilize any hardware technology's authentication
mechanism, if available.
4. Message Types
4.1 Prefix Solicitation
A Prefix Solicitation (PS) message is sent by the RR to the DR
requesting for a set of prefixes that are specified in the message.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Service |D|A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An IP address assigned to the sending interface of
the RR
Destination Address
The IP address of the DR
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Arun & Shankar Expires October 30, 2004 [Page 6]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type PD_CPE_REQUEST
Code 0
Checksum The ICMP Checksum. See [ICMPv6].
Seq Num 16-bit unsigned integer. The Sequence Number for
this request. It is generated by the RR and
should be uniformly distributed across the
requests. It SHOULD be a non-zero value. This
SHOULD be used in all requests and returns
of prefixes. The Sequence Number is used as a
message identifier between the RR and DR and
SHOULD not change during one transaction.
Service 8-bit unsigned integer. The Service-Band of
the customer making this request. The RR
MAY set it to its existing Service-Band or
to another Service-Band that it expects itself
to be from now on. The Service-Band signifies
the kind of preferential service that the RR
enjoys with the DR.
The usages of the Service field are discussed in
Appendix A.
D One bit "Discretion" flag. If it is set by the
RR it indicates that the the DR is allowed to
use it's discretion while serving this request.
This allows the RR to express its requests
freely, and at the same time allowing the DR
to apply its policies depending on the RR. It
MAY be set by the RR if it wants to allow DR to
use its discretion in allocating addresses to
this request.
The usages of the Discretion flag are discussed
in Appendix A.
A One bit "Acknowledgement" flag. If it is set,
it means that the RR is acknowledging a reply
from the DR. It SHOULD be set to zero in a
request message. It SHOULD be set to one while
acknowledging the receipt of prefixes and
returning of prefixes.
Reserved 6-bit Reserved Field. It MUST be initialized to
zero by the sender and MUST be ignored by the
Arun & Shankar Expires October 30, 2004 [Page 7]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
receiver.
Identifier 32-bit unsigned integer. Unique identifier for
this RR. It SHOULD be set to zero if the RR
does not know its identifier. A value of zero
would mean that the DR has to allocate an
identifer for this RR. Once the RR has been
alloted its Identifier, it MUST use it in all
its future communications. The Identifier could
be a pre-assigned Identifier given by the DR.
Possible Options:
Arbitrary Delegation Prefix Options
Arbitrary Delegation Prefix options can be
specified. The RR could require 'm' sets of
'n' prefixes with 'x' bits in prefix length,
where a set is defined as {number of prefixes,
prefix length}
Block Delegation Prefix Options
Block Delegation Prefix options can be
specified. The RR could require 'm' sets of
'n' prefixes which lie within a certain block
of addresses and are 'x' bits in prefix length,
where a set is defined as {number of prefixes,
prefix length}
Individual Delegation Prefix Options
Individual Delegation Prefix options can be
specified. The RR could require 'm' sets of
prefixes which have 'y' as prefix, where a set
is defined as {prefix, prefix length}
Source Link Layer Address
The Source Link Layer Address option MUST be
specified in cases when the RR requests a new
Identifier. It MUST not be specified when the
RR knows its Identifier.
4.2 Prefix Delegation
A Prefix Delegation (PD) message is sent by the DR to the RR
delegating a set of prefixes that are specified in the message.
Arun & Shankar Expires October 30, 2004 [Page 8]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Num | Service |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An IP address assigned to the sending interface
of the DR.
Destination Address
The source IP address of the packet that sent the
request with the current sequence number.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type PD_PE_RESPONSE
Code 0
Checksum The ICMP Checksum. See [ICMPv6].
Seq Num 16-bit unsigned integer. The Sequence Number for
this request. It is the same Sequence Number of
the PS message that generated this response.
It SHOULD be a non-zero value. This should be
used in all responses.
Service 8-bit unsigned integer. The Service-Band
assigned to the customer making this request.
The DR sets it to its existing Service-Band for
the RR. The Service-Band signifies the kind of
preferential service that the RR enjoys with
the DR.
A 1-bit Acknowledgement Flag. It SHOULD be set to
1 when the DR is acknowledging a request from
the RR. It SHOULD be set to zero when the DR
Arun & Shankar Expires October 30, 2004 [Page 9]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
is sending a message on it's own.
Reserved 7-bit Reserved field. SHOULD be set to zero by
the DR and should be ignored by the RR.
Identifier 32-bit Identifier field. Created by the DR
using the RR's interface identifier. Uniquely
identifies a RR. The way in which the DR
generates the Identifier is implementation
dependent.
Possible Options:
Block Delegation Prefix Options
Block Delegation Prefix options can be
specified. The DR could delegate 'm' sets of
'n' prefixes which lie within a certain block
of addresses and are 'x' bits in prefix length.
where a set is defined as {number of prefixes,
prefix length}
Individual Delegation Prefix Options
Individual Delegation Prefix options can be
specified. The DR could delegate 'm' sets of
prefixes which have 'y' as prefix, where a set
is defined as {number of prefixes,
prefix length}.
4.3 Option Formats
Prefix Delegation messages include zero or more options, some of
which may appear multiple times in the same message. All options are
of the form:
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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 8-bit identifier of the type of option. The
options defined in this document are:
Option Name Type
Source Link-Layer Address 1
Arbitrary Delegation Request Option 2
Arun & Shankar Expires October 30, 2004 [Page 10]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Block Delegation Request Option 3
Individual Delegation Request Option 4
Individual Delegation Response Option 5
Block Delegation Response Option 6
4.3.1. Source Link-layer Address Option
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 | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type
1 for Source Link-layer Address
Length The length of the option (including the type and
length fields) in units of 8 octets. For example,
the length for IEEE 802 addresses is 1 [IPv6-
ETHER].
Link-Layer Address
The variable length link-layer address.
The content and format of this field (including
byte and bit ordering) is expected to be specified
in specific documents that describe how IPv6
operates over different link layers. For instance,
[IPv6-ETHER].
Description
The Source Link-Layer Address option contains the
link-layer address of the sender of the packet. It
is used in the Prefix Request messages when the RR
does not know its unique identifier.
These options MUST be silently ignored for other
messages.
4.3.2. Arbitrary Delegation Request Option
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 | Prefix Length |No.of Prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arun & Shankar Expires October 30, 2004 [Page 11]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Fields:
Type 2 for Arbitrary Delegation Request Option
Length 2
Prefix Length 8-bit unsigned integer. The length of the
requested prefix. The value ranges from 0 to 128.
It denotes the length of the all the prefixes
that would be delegated as a response to this
message. A value of 0 notifies the DR to use it's
default prefix length.
No. of Prefixes
8-bit unsigned integer. The number of prefixes
requested by the RR in this message.
Reserved 32-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime 1
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix(es) to
be valid, ie, the time in seconds until which the
RR expects the DR to route packets, which have
(one of) the associated prefix(es) in the
destination address, to the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix(es).
A value of all 1 bits (0xffffffff) set in a
Arbitrary Delegation Request Message by the RR
is invalid. It SHOULD NOT be set by the sender and
SHOULD be silently ignored by the receiver.
Valid Lifetime 2
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix(es) to
be valid, ie, the time in seconds until which the
RR expects the DR to route packets, which have
(one of) the associated prefix(es) in the
destination address, to the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix(es).
Valid Lifetime 2 SHOULD be set to a value lesser
than Valid Lifetime 1.
Valid Lifetime 2 SHOULD be set to zero by the
Arun & Shankar Expires October 30, 2004 [Page 12]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
sender and ignored by the receiver if Valid
Lifetime 1 is all-zero.
A value of all 1 bits (0xffffffff) set in a
Arbitrary Delegation Request Message by the RR is
invalid. It SHOULD NOT be set by the sender and
SHOULD be silently ignored by the receiver.
Description
The RR can use the Arbitrary Delegation Request
Option to request for an arbitrary number of
prefixes which have an specified prefix length.
It can specify two values as expected valid
lifetimes for the DR to choose from. If the RR
is not specific about lifetimes, it SHOULD set
both the fields to zero.
A value for infinite valid lifetime is disallowed.
The Arbitrary Delegation Request option appears in
a PD_CPE_REQUEST message. These options MUST be
silently ignored for other messages.
4.3.3. Block Delegation Request Option
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 | Prefix Length |No. of Prefixes|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix Address Block1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix Address Block2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Arun & Shankar Expires October 30, 2004 [Page 13]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Type 3 for Block Delegation Request Option
Length 6
Prefix Length 8-bit unsigned integer. The length of the
requested prefix. The value ranges from 0 to 128.
It denotes the length of the all the prefixes
that would be delegated as a response to this
message. A value of 0 notifies the DR to use it's
default prefix length.
No. of Prefixes
8-bit unsigned integer. The number of prefixes
requested by the RR in this message.
Reserved 32-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime 1
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix(es) to
be valid, ie, the time in seconds until which the
RR expects the DR to route packets, which have
(one of) the associated prefix(es) in the
destination address, to the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix(es).
A value of all one bits (0xffffffff) set in a
ack-request message by the RR represents that it
is returning the address.
Valid Lifetime 2
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix(es) to
be valid, ie, the time in seconds until which the
RR expects the DR to route packets, which have
(one of) the associated prefix(es) in the
destination address, to the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix(es).
Valid Lifetime 2 SHOULD be set to a value lesser
than Valid Lifetime 1.
Valid Lifetime 2 SHOULD be set to zero by the
sender and ignored by the receiver if Valid
Lifetime 1 is all-zero or all-one.
Arun & Shankar Expires October 30, 2004 [Page 14]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
A value of all ones (0xffffffff) SHOULD NOT be
set in Valid Lifetime 2 by the sender and SHOULD
be ignored by the receiver.
Prefix Address Block 1
128-bit field. The start of an address block
(inclusive) in the IPv6 address space from where
the RR wants its prefix(es). The Prefix Length
field contains the number of valid leading bits in
the prefix address block. The bits in the prefix
address block after the prefix length are reserved
and MUST be initialized to zero by the sender and
ignored by the receiver. An RR SHOULD send a
prefix option only for globally valid prefixes
and a DR SHOULD ignore any other prefix option.
Prefix Address Block 2
128-bit field. The end of an address block
(inclusive) in the IPv6 address space from where
the RR wants its prefix(es). The Prefix Length
field contains the number of valid leading bits in
the prefix address block. The bits in the prefix
address block after the prefix length are reserved
and MUST be initialized to zero by the sender and
ignored by the receiver. An RR SHOULD send a
prefix option only for globally valid prefixes
and a DR SHOULD ignore any other prefix option.
Description
The RR can use the Block Delegation Request Option
to request for an fixed number of prefixes which
have an specified prefix length that lie within a
block of addresses.
It can specify two values as expected valid
lifetimes for the DR to choose from. If the RR
is not specific about lifetimes, it can set BOTH
the fields to zero.
A value for infinite valid lifetime MUST be
disallowed.
The Block Delegation Request option appears in a
PD_CPE_REQUEST message. These options MUST be
silently ignored for other messages.
Arun & Shankar Expires October 30, 2004 [Page 15]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
4.3.4. Individual Prefix Delegation Request Option
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 | Prefix Length | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 4 for Individual Prefix Information
Length 4
Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges
from 0 to 128. It denotes the length of the all
the prefixes included in this message. A value of
0 notifies the DR to use its default prefix length.
Reserved1 6-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Reserved2 32-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime 1
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix to
be valid, ie, the time in seconds until which the
RR expects the DR to route packets, which have
the associated prefix in the destination address,
to the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix.
A value of all one bits (0xffffffff) set in a
Arun & Shankar Expires October 30, 2004 [Page 16]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
ack-request message by the RR represents that it
is returning the address.
Valid Lifetime 2
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the RR expects the associated prefix to be
valid, ie, the time in seconds until which the RR
expects the DR to route packets, which have the
associated prefix in the destination address, to
the RR.
A value of all zero bits (0x00000000) set in a
request message by the RR represents that it has
no preference about the lifetime of the prefix.
Valid Lifetime 2 SHOULD be set to a value lesser
than Valid Lifetime 1.
Valid Lifetime 2 SHOULD be set to zero by the
sender and ignored by the receiver if Valid
Lifetime 1 is all-zero or all-one.
A value of all ones (0xffffffff) SHOULD NOT be
set in Valid Lifetime 2 by the sender and SHOULD
be ignored by the receiver.
Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid
leading bits in the prefix. The bits in the prefix
after the prefix length are reserved and MUST be
initialized to zero by the sender and ignored by
the receiver. A RR SHOULD send a prefix option
only for globally valid prefixes and a DR SHOULD
ignore any other prefix option.
Description
The Individual Request Prefix option lets the RR
request for multiple prefixes in one single
message. It also allows the RR to return or return
one or more prefixes.
The Individual Request Prefix option appears in a
PD_CPE_REQUEST message. These options MUST be
silently ignored for other messages.
Arun & Shankar Expires October 30, 2004 [Page 17]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
4.3.5. Block Delegation Response Option
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 | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix Address Block1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix Address Block2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 6 for Block Delegation Response Option
Length 5
Prefix Length 8-bit unsigned integer. The length of the
delegated prefix. The value ranges from 1 to 128.
It denotes the length of the all the prefixes
that are delegated as a response to this message.
Reserved 32-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the associated prefix is valid, ie, the time
in seconds until which the DR would route packets,
which have the associated prefix in the destination
address, to the RR.
A value of all one bits (0xffffffff) set in a
response message by the DR represents that it is
revoking the address.
Arun & Shankar Expires October 30, 2004 [Page 18]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Prefix Address Block 1
128-bit field. The start of an address block
(inclusive) in the IPv6 address space from where
the DR delegates its prefix(es). The Prefix Length
field contains the number of valid leading bits in
the prefix address block. The bits in the prefix
address block after the prefix length are reserved
and MUST be initialized to zero by the sender and
ignored by the receiver. An DR SHOULD delegate the
prefix option only for globally valid prefixes
and a RR SHOULD ignore any other prefix option.
Prefix Address Block 2
128-bit field. The end of an address block
(inclusive) in the IPv6 address space from where
the DR delegates its prefix(es). The Prefix Length
field contains the number of valid leading bits in
the prefix address block. The bits in the prefix
address block after the prefix length are reserved
and MUST be initialized to zero by the sender and
ignored by the receiver. An DR SHOULD delegate the
prefix option only for globally valid prefixes
and a RR SHOULD ignore any other prefix option.
Description
The DR can use the Block Delegation Response
Option to delegate a fixed number of prefixes
which have an arbitrary prefix length that lie
within a block of addresses.
A value for infinite valid lifetime is disallowed.
The Block Delegation Response option appears in a
PD_PE_RESPONSE message and PD_CPE_REQUEST message.
These options MUST be silently ignored for other
messages.
4.3.6. Individual Prefix Delegation Response Option
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 | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arun & Shankar Expires October 30, 2004 [Page 19]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Fields:
Type 5 for Individual Prefix Information
Length 3
Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges
from 1 to 128. It denotes the length of the all
the prefixes included in this message.
Reserved 6-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in
seconds (relative to the time the ack is received)
that the associated prefix is valid, ie, the time
in seconds until which the DR would route packets,
which have the associated prefix in the destination
address, to the RR.
A value of all one bits (0xffffffff) set in a
response message by the DR represents that it is
revoking the address.
Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid
leading bits in the prefix. The bits in the prefix
after the prefix length are reserved and MUST be
initialized to zero by the sender and ignored by
the receiver. A DR SHOULD NOT send a prefix
option only for globally valid prefixes and a RR
SHOULD ignore any other prefix option.
Description
The Individual Prefix option lets the
DR delegate multiple prefixes to the RR in one
single message. It also allows the DR to cancel
or revoke one or more prefixes.
The Block Delegation Response option appears in a
PD_PE_RESPONSE message and PD_CPE_REQUEST message.
These options MUST be silently ignored for other
messages.
5. Prefix Delegation Mechanism and Overview
5.1 Conceptual Data Structures
DRs will need to maintain the following information
Arun & Shankar Expires October 30, 2004 [Page 20]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Free Prefix Cache
The Free prefix cache would contain the list of available
prefixes. For each of the free prefix, the DR can have a
minimum and a maximum valid lifetime that it can delegate
it for. This would facilitate the DR to allocate set of
addresses for dynamic assignments, static assignments and
maintain band of such address pools. It should also contain
details of acceptable IP addresses for this prefix, last
allocated RR's identifier, IP address and state of the prefix.
Having the IP address of the RR would also help in handling
cases of pre-assigned prefixes.
Allocated Prefix Cache
The Allocated prefix cache would contain the list of
allocated prefixes. For each of the allocated prefixes, the
DR can have the request id for this prefix, the identifier
of the RR that has been delegated this prefix, the valid
lifetime of the prefix and a timer that would clear the
prefix from the Allocated prefix cache and return it back
to the Free prefix cache.
RRs will need to maintain the following information
Current Prefix Cache
The Current prefix cache would contain the list of all the
prefixes that are either requested for or already delegated
to the RR, Valid Lifetime(s) for the prefix, state of the
prefix.
Note that the above conceptual data structures can be implemented
using a variety of techniques. One possible implementation is to use
a single table for all of the above data structures.
Regardless of the specific implementation, it is critical that the
data be easily accessible and persistent to avoid any issues that
could result due to failures and crashes on the nodes. An
implementation is at liberty to implement such data structures in any
way it pleases.
5.2 States of Prefixes
A Prefix is said to be in one of the following states at any time
in the DR's Data Structures.
Free The Prefix is available for delegation provided
the RR meets other requirements if any.
Pending The Prefix has been delegated to a RR and is
awaiting a acknowledgement from the RR.
Delegated The Prefix has been delegated to a RR and the
RR has acknowledged the receipt of this prefix.
Deprecated The Prefix has been delegated to and
Arun & Shankar Expires October 30, 2004 [Page 21]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
acknowledged by the RR and is due to expire in
a specified time (ideally, PDDeprecateTimer).
Expired The Prefix has been delegated to and
acknowledged by the RR and the valid lifetime
has expired.
A Prefix is said to be in one of the following states at any time
in the RR's Data Structures.
Pending The Prefix has been sent as a request to the DR
and is awaiting a response from the RR.
Delegated The Prefix has been delegated to by the DR and
an acknowledgement to the receipt of this
prefix has been sent.
Deprecated The Prefix has been delegated by and an
acknowledgement sent to the DR and is due to
expire in a specified time (ideally,
PDDeprecateTimer).
Expired The Prefix has been delegated by and an
acknowledgement sent to the RR and the valid
lifetime has expired.
5.3 Conceptual Sending Algorithm
A Requesting Router(RR) sends a Prefix Solicitation(PS) message to
a Delegating Router(DR) when it finds the needs for delegating
prefixes downstream inside the customer environment. It includes all
the prefixes that it requires in the PS message using the various
options available, viz. Arbitrary Delegation(AD), Block
Delegation(BD) and Individual Delegation(ID). If a RR has arranged
for pre-assigned prefixes, it would send an empty message to the DR
to let it know that he is online and can respond to Response queries
with acknowledgements.
A DR receives a PS message from a RR and looks up for availability
of prefixes. It sends a list of all the available prefixes that
suit the RR's requirements, after considering multiple factors like
Discretionary setting and the Service-Band of the RR. After sending
a reply to the PS using a Prefix Delegation(PD) message, the DR
awaits an acknowledgement from the RR to the effect. Only after the
acknowledgement from the RR, can the DR start its billing for the
delegated prefixes and forwarding of the packets received. If it
receives an empty request message, it checks it's data structures to
see if there are preassigned prefixes for this RR, and if so,
responds with the preassigned prefixes.
The RR receives the PD message sent by the DR and checks the
prefixes that it has been delegated. It then prepares a PS message
with the ack field set and sends it to the DR acknowledging the
receipt of the prefixes. The RR can also return prefixes that have
Arun & Shankar Expires October 30, 2004 [Page 22]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
been given to it by the DR.
When the valid lifetime is about to expire for a given prefix, the
RR may choose to renew it with the DR. It sends a PS message to the
DR indicating the newer lifetimes that it requires for the given
prefixes.
When the valid lifetime is about to expire for a given prefix, the
DR does not send reminder probes to the RR to that effect. It is the
responsibility of the RR to renew a prefix on the event of it
expiring.
The DR can choose to revoke a set of prefixes that were previously
delegated to a RR before they expire. The RR sends a PD message with
the list of prefixes that are to be revoked. In such an instance, the
DR need not wait for acknowledgement. For example, a DR might choose
to revoke a prefix due to complaints of abuse of a certain prefix.
The RR can attempt to regain the prefixes by sending a PS message
containing the revoked prefixes.
6. Requesting Router Specification
A Requesting Router(RR) would be able to send Prefix Solicitation(PS)
messages and acknowledged PS messages to a Delegating Router(DR).
6.1 Prefix Solicitation by a Requesting Router
A Requesting Router(RR) finds the need for delegating prefixes
downstream and sends a Prefix Solicitation(PS) message to the
Delegating Router(DR).
6.1.1 Prefix Solicitation Header Specification
- RR sets the Type to PD_CPE_REQUEST, Code to zero and the
ICMP Checksum as mentioned in [ICMPv6].
- If the RR chooses to allow the DR to use its "discretion" in
delegating the prefixes, it sets the Discretion bit to one.
Otherwise, it is set to zero.
- In a Prefix Solicitation message, the Acknowledgement bit SHOULD
be set to zero by the RR.
- The RR SHOULD be capable of generating a 16-bit long sequence
number. This number should be randomized using a seed and SHOULD
be different than any recently generated sequence number on this
node. This sequence number SHOULD be set in the Sequence Number
field. The node can choose to implement the sequence number
generating algorithm in a way that it chooses to be appropriate.
- If the RR does not have an agreed service type and is requesting
the DR for ANY service type, it sets the Service Type field to
zero. If the RR already has an agreed service type, it SHOULD set
it in the Service Type field. If the RR wants to change its agreed
service type, it SHOULD set the new service type in the Service
Type field.
- If the RR does not have a unique identifier to identify itself
Arun & Shankar Expires October 30, 2004 [Page 23]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
with the DR, it SHOULD set the Identifier field to zero and
it SHOULD include the Source Link Layer Address(SLLA) Option. If
the RR has an already agreed identifier to identify itself with
the DR, it SHOULD set the Identifier field accordingly.
- The Reserved field should be initialized to zero.
6.1.2 Prefix Solicitation Option Specification
- It includes all the prefixes that it requires in the PS message
using the various options available, viz. Arbitrary Delegation(AD),
Block Delegation(BD) and Individual Delegation(ID).
- If the prefixes are preassigned, no options are included.
- If the RR requires a prefix with no particular preference, it
adds an AD Request Option to the PS message.
The expected length that the prefixes need to have is set in the
Prefix Length field. If there is no preference, it is set to zero.
The number of arbitrary prefixes with the aforesaid prefix length
is set in the No. of Prefixes field.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 1 field. If the RR has no preference in this
regard, the Valid Lifetime 1 field is set to zero.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 2 field. If the RR has no preference in this
regard, the Valid Lifetime 2 field is set to zero. The Valid
Lifetime 2 field SHOULD be set to a value lesser than the value
specified in Valid Lifetime 1 field.
- If the RR requires a prefix to lie within a particular block of
addresses, it adds a BD Request Option to the PS message.
The expected length that the prefixes need to have is set in the
Prefix Length field. If there is no preference, it is set to zero.
The number of prefixes with the aforesaid prefix length is set in
the No. of Prefixes field. If it is set to zero, all prefixes
within the block need to be delegated.
The Reserved field should be set to zero.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 1 field. If the RR has no preference in this
regard, the Valid Lifetime 1 field is set to zero.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 2 field. If the RR has no preference in this
regard, the Valid Lifetime 2 field is set to zero. The Valid
Lifetime 2 field SHOULD be set to a value lesser than the value
specified in Valid Lifetime 1 field.
The starting point(inclusive) of the address block within which
the RR expects the prefixes to be is set in Prefix Address Block 1.
The ending point(inclusive) of the address block within which the
RR expects the prefixes to be is set in Prefix Address Block 2.
- If the RR requires a specified prefix, it adds an ID Request
Option to the PS message.
The expected length that the prefixes need to have is set in the
Prefix Length field. If there is no preference, it is set to zero.
The Reserved fields should be set to zero.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 1 field. If the RR has no preference in this
Arun & Shankar Expires October 30, 2004 [Page 24]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
regard, the Valid Lifetime 1 field is set to zero.
The number of seconds the prefix is expected to be alive is set in
the Valid Lifetime 2 field. If the RR has no preference in this
regard, the Valid Lifetime 2 field is set to zero. The Valid
Lifetime 2 field SHOULD be set to a value lesser than the value
specified in Valid Lifetime 1 field.
The specific prefix that the RR requires is set in the Prefix
field.
6.2 Prefix Delegation Acknowledgement & Returning by a Requesting Router
When a DR delegates prefixes, the RR should acknowledge the receipt
of the prefixes. The DR would start forwarding packets only after
it receives the acknowledgement from the RR. The RR can acknowledge
the receipt of the prefixes and also return any of the delegated
prefixes using the same Block and Individual Delegation
Response options received in the DR's response.
A Return could be done as a separate message or it could be
piggy-backed with an acknowledgement. If the Returning is done in
a separate message, it would require a new sequence number. If the
RR intends to use all the prefixes that have been allocated, it
SHOULD send a acknowledgement message without options. If it intends
to reject a few prefixes, they SHOULD be included as options with
all ones (0xffffffff) as Valid Lifetime.
6.2.1 Prefix Delegation Acknowledgement Header Specification
- It sets the Type to PD_CPE_REQUEST, Code to zero and the
ICMP Checksum as mentioned in [ICMPv6].
- The discretion bit SHOULD be set to zero.
- In an Acknowledgement message, the Acknowledgement bit SHOULD
be set to one by the RR.
- The RR SHOULD use the same sequence number that was used in the
original PS message.
- The RR SHOULD use the same Service Type field of the PD message
to set the Service Type field
- The RR SHOULD use the agreed identifier to set the Identifier
field.
- The Reserved field should be initialized to zero.
6.2.2 Prefix Delegation Acknowledgement Option Specification
- Block Delegation Response Option from the PD that is acknowledged
is included on return of prefixes. If the RR chooses to return any
prefix the valid lifetime field is set to all ones (0xffffffff)
to indicate that this block of prefixes is returned.
- Individual Delegation Response Option from the PD that is
acknowledged is included on return of prefixes. If the RR chooses
to return any prefix the valid lifetime field is set to all ones
(0xffffffff) to indicate that the individual prefix is returned.
6.3 Prefix Renewal by a Requesting Router
Arun & Shankar Expires October 30, 2004 [Page 25]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
- When a prefix reaches Deprecated state, a RR could send renewal
messages to DR to extend the Valid Lifetime of the prefix. It
could do so using a PS message. The renewal message is treated
as a new solicitation message.
After sending a PS message, the state of the prefix would be
Pending.
6.3.1 Prefix Solicitation Header Specification
- It sets the Type to PD_CPE_REQUEST, Code to zero and the
ICMP Checksum as mentioned in [ICMPv6].
- If the RR chooses to allow the DR to use its "discretion" in
delegating the prefixes, it sets the Discretion bit to one.
Otherwise, it is set to zero.
- In a Prefix Solicitation message, the Acknowledgement bit SHOULD
be set to zero by the RR.
- The RR SHOULD be capable of generating a 16-bit long sequence
number. This number should be randomised using a seed and SHOULD
be different than any recently generated sequence number on this
node. This sequence number SHOULD be set in the Sequence Number
field. The node can choose to implement the sequence number
generating algorithm in a way that it chooses to be appropriate.
- If the RR does not have an agreed service type and is requesting
the DR for ANY service type, it sets the Service Type field to
zero. If the RR already has an agreed service type, it SHOULD set
it in the Service Type field. If the RR wants to change its agreed
service type, it SHOULD set the new service type in the Service
Type field.
- The RR's unique identifier should be used to set the Identifier
field.
- The Reserved field should be initialized to zero.
6.3.2 Prefix Solicitation Option Specification
- It includes all the prefixes that it requires to be renewed in the
PS message using Block Delegation(BD) and Individual
Delegation(ID). Arbitrary Delegation cannot be used since
only well-specified prefixes can be renewed.
- If the RR requires a block of continuos prefixes to be renewed, it
adds a BD Request Option to the PS message.
The length of the prefixes is set in the Prefix Length field.
The number of block prefixes which are to be renewed is set in the
No. of Prefixes field. If it is set to zero, all the prefixes
within the block need to be renewed.
The Reserved field should be set to zero.
The number of seconds the prefix is expected to be renewed is set
in the Valid Lifetime 1 field. If the RR has no preference in this
regard, the Valid Lifetime 1 field is set to zero.
The number of seconds the prefix is expected to be renewed is set
in the Valid Lifetime 2 field. If the RR has no preference in this
regard, the Valid Lifetime 2 field is set to zero. The Valid
Lifetime 2 field SHOULD be set to a value lesser than the value
specified in Valid Lifetime 1 field.
The starting point(inclusive) of the address block within which
Arun & Shankar Expires October 30, 2004 [Page 26]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
the prefixes are is set in Prefix Address Block 1.
The ending point(inclusinve) of the address block within which the
the prefixes are is set in Prefix Address Block 2.
- If the RR requires to renew a specified prefix, it adds an ID
Request Option to the PS message.
The length of the renewing prefix is set in the Prefix Length
field.
The Reserved fields should be set to zero.
The number of seconds the prefix is expected to be renewed is set
in the Valid Lifetime 1 field. If the RR has no preference in this
regard, the Valid Lifetime 1 field is set to zero.
The number of seconds the prefix is expected to be renewed is set
in the Valid Lifetime 2 field. If the RR has no preference in this
regard, the Valid Lifetime 2 field is set to zero. The Valid
Lifetime 2 field SHOULD be set to a value lesser than the value
specified in Valid Lifetime 1 field.
The specific prefix that the RR requires is set in the Prefix
field.
6.4 Prefix Delegation Message Validation by Requesting Router
A RR receives Prefix Delegation(PD) messages from the DR in response
to it's PS message.
6.4.1 Prefix Delegation Header Validation
- Verify if Type is PD_PE_RESPONSE, Code is Zero and ICMPv6 Checksum
field is correct. If not, silently ignore the message.
- If ACK field is set, ensure a solicited message with the
corresponding Sequence Number is available in the Data Structures
with prefix state Pending.
If ACK field is not set, ensure a solicited message with the
corresponding Sequence Number is available in the Data Structures
with prefix state anything other than Pending. If not, silently
ignore the message.
- If the Sequence Number field is zero, it denotes a case of
pre-assignment of prefixes. Otherwise, check if prefixes with
Pending state match the Sequence Number. If they do not match,
silently ignore the message.
- Set Service field in the data structure to Service field in the
PD header. This would be the new service band for the RR.
- If the Identifier field is zero, the message should be silently
ignored. If the Identifier value in the local data structure is
zero, set the value in the Identifier field of the message. This
SHOULD be used in all future communications. Otherwise, it should
be checked and if it does not match, the message should be silently
ignored.
- The Reserved field should be ignored.
6.4.2 Prefix Delegation Option Validation
- If the Discretion flag was not set, check if all the prefixes
requested are provided with requested Valid Lifetimes.
If not, silently ignore the message.
Arun & Shankar Expires October 30, 2004 [Page 27]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
- If the Discretion flag was set, process each option individually.
- If the options are empty, check if there are any preassigned
prefixes awaiting acknowledgement for this RR. If not, silently
ignore the message.
- If a prefix is not in Pending state, Return the prefix.
- Move the prefixes from the Pending state to Delegated State
- If the Valid Lifetimes are all-zeroes, ignore the prefix
6.5 Configurable Parameters for Requesting Router
PDCPEMaxRetries The number of retries the RR has to perform
before it gets a reply to its solicitation.
PDCPEMaxPrefixes Maximum number of prefixes that could be
requested by a RR at its next request. It
depends on the type of service that the RR
enjoys.
PDCPEDynamicThreshold
The threshold value which is used to determine
if a prefix is static or a dynamic prefix. This
can be used when the RR wishes to request for
static or a dynamic prefix.
PDCPEDeprecateTimer The value in seconds for which a prefix would
remain deprecated. When there are
PDCPEDeprecateTimer seconds for the Valid
Lifetime to expire, the RR can start sending
renewal requests for the prefix.
PDCPERetransTimer The value in seconds between two retries.
PDCPEReplayTimer The value in seconds after a which a RR allows
an old sequence number to be accepted as a valid
sequence number and not reject it as a replay.
7. Delegating Router Specification
A Delegating Router(DR) would send Prefix Delegation(PD) messages
to a Requesting Router(RR).
7.1 Prefix Delegation by a Delegating Router
A Delegating Router(DR) responds to a Prefix Solicitation(PS) message
from a RR with a PD message.
7.1.1 Prefix Delegation Header Specification
- If the Discretion bit was not set, and all prefixes with requested
valid lifetimes are not available, silently ignore the message.
- Set Type to PD_PE_RESPONSE, Code to zero and Checksum a mentioned
in [ICMPv6].
- If the message is an acknowledgement to a previously received PS
Arun & Shankar Expires October 30, 2004 [Page 28]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
message, set the ACK bit to one. Otherwise, set the ACK bit to
zero.
- If it is a case of pre-assignment of prefixes, set the Sequence
Number field to zero. Otherwise, set it to the value from the
previously received PS message.
- Set the Service field to either the current or updated Service
band of the RR
- If the Identifier field is non-zero, Set the Identifier field to
the same value. Otherwise, set it to the newly arrived Identifier
value.
- The Reserved field should be to set to zero.
7.1.2 Prefix Delegation Option Specification
- If Addresses could be allocated in a block, use Block Delegation
Response Option. Set the Prefix Length field to the prefix length
that is common to all the prefixes in the block. Set the starting
address of the prefix block (inclusive) in Prefix Address Block 1
and the ending address of the prefix block (inclusive) in Prefix
Address Block 2. Set the Valid Lifetime field to the applicable
value.
- If Addresses could not be allocated in a block, use Individual
Delegation Response Option. Set the Prefix Length field to the
prefix length of the prefix and load the prefix in the Prefix
field. Set the Valid Lifetime field to the applicable value.
7.2 Prefix Revoking by a Delegating Router
A DR can revoke the prefixes that it had delegated using a PS
message. This SHOULD NOT be piggy-backed with a current delegation
response and SHOULD be sent only as a standalone message.
7.2.1 Prefix Revoking Header Specification
- Set Type to PD_PE_RESPONSE, Code to zero and Checksum a mentioned
in [ICMPv6].
- Set the ACK bit to zero, since this is not an acknowledgement.
- If it is a case of pre-assignment of prefixes, set the Sequence
Number field to zero. Otherwise, set it to the value from the
previously received PS message which performed the delegation.
- Set the Service field to either the current Service band of the RR
- Set the Identifier field to the value of the RR.
- The Reserved field should be to set to zero.
7.2.2 Prefix Delegation Option Specification
- If Addresses could be revoked in a block, use Block Delegation
Response Option. Set the Prefix Length field to the prefix length
that is common to all the prefixes in the block. Set the starting
address of the prefix block (inclusive) in Prefix Address Block 1
and the ending address of the prefix block (inclusive) in Prefix
Address Block 2. Set the Valid Lifetime field to all ones
(0xffffffff).
Arun & Shankar Expires October 30, 2004 [Page 29]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
- If Addresses could not be revoked in a block, use Individual
Delegation Response Option. Set the Prefix Length field to the
prefix length of the prefix and load the prefix in the Prefix
field. Set the Valid Lifetime field to all ones (0xffffffff).
7.3 Prefix Solicitation Message Validation by Delegating Router
A DR receives PS messages from RRs which require prefixes.
7.3.1 Prefix Solicitation Header Validation
- Verify if Type is PD_CPE_REQUEST, Code is zero and Checksum is
correct. If not, silently ignore the message.
- If the ACK flag is set, the RR is acknowledging a previous PD
message. If the ACK flag is not set, the RR is making a fresh
request.
- If the Discretion flag is set alongside the ACK flag, ignore the
message. Otherwise, ensure that all prefixes are available with
appropriate Valid Lifetimes. If prefixes are not available,
silently ignore the message.
- If the Sequence Number field is zero and the Ack flag is not set,
silently ignore the message.
- If the Service field is zero, assign a new Service band for the RR.
If the Service field is different, assign the new Service band if
it meets the policy guidelines, if any.
- If the Identifier field is zero, check for SLLA option. If not
found, silently ignore the message. If found, use it in a
implementation-dependent hash algorithm to generate a 32-bit
identifier for the RR.
- Ignore the Reserved bits.
7.3.2 Prefix Solicitation Options Validation
- If ACK flag is set and there are no options, all the prefixes that
were allocated in the message with the appropriate Sequence Number
are acknowledged by the RR. If ACK flag is not set and there are
no options, check for a case of Pre-assigned prefixes.
- If Identifier field is non-zero, ignore the SLLA option.
- For all kinds of prefixes solicited, check if such a prefix is
in the Free state. If not, ignore the Prefix.
- If Prefix Length is set to zero in the solicitation message, the
default prefix value is taken.
- For all available prefixes, check if Valid Lifetime 1 option is
zero. If so, Ignore the Valid Lifetime 2 option and delegate the
prefix with Valid Lifetime depending on the Service Band of the
Arun & Shankar Expires October 30, 2004 [Page 30]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
Customer. Ignore the prefix if Ack bit is zero and Valid Lifetime
is all-ones (0xffffffff). If Ack bit is one and Valid Lifetime
is all-ones (0xffffffff), set the entry to Expire in the table and
ignore the Valid Lifetime 2 option.
- If Valid Lifetime 1 is non-zero and not all-ones, Check Valid
Lifetime 2 to see minimum and maximum values for Valid Lifetime.
If such a prefix matches, delegate it with Valid Lifetime based
on the Service Band of the customer. Otherwise, ignore the prefix.
- Once a prefix is delegated, Mark it as Pending. After receiving the
Ack, set it to Delegated.
7.4 Configurable Parameters for Delegating Router
PDPEMaxRetries The number of retries the DR has to perform
before it gets an Ack to its PD message.
PDPEMaxPrefixes Maximum number of prefixes that could be
delegated by a DR at its next request. It
depends on the type of service that the RR
enjoys.
PDPEDynamicThreshold
The threshold value which is used to determine
if a prefix is static or a dynamic prefix. This
can be used when the DR wishes to allocate for a
static or a dynamic prefix.
PDPEDeprecateTimer The value in seconds for which a prefix would
remain deprecated. When there are
PDPEDeprecateTimer seconds for the Valid
Lifetime to expire, the RR can start expecting
renewal requests for the prefix.
PDPERetransTimer The value in seconds between two retries.
PDPEExpireTimer The value in seconds when the DR decides that
the prefix can be freed after having expired
earlier.
PDPEDefaultPrefixLength
The default prefix length to be chosen by the PE
if the RR does not have any preference on the
prefix length.
PDPEReplayTimer The value in seconds after a which a DR allows
an old sequence number to be accepted as a valid
sequence number and not reject it as a replay.
8. IANA Considerations
IANA is requested to assign an option code to the following options
Arun & Shankar Expires October 30, 2004 [Page 31]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
from the option-code space for ICMPv6 [ICMPv6].
Option Name Value Described in
PD_CPE_SOLICIT tbd Section 4
PD_PE_RESPONSE tbd Section 4
9. Security Considerations
For point to point links, where one trusts that there is
no man in the middle, or one trusts layer two authentication,
authentication may not be necessary.
On other links, Security considerations like man in the middle
exist.
10. Normative References
[IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998
[IPv6-ADDR] Deering, S., Hinden, R., "IP Version 6 Addressing
Architecture", Work in Progress, December 1998
[ICMPv6] Conta, A., Deering, S., "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", Work in Progress, February 2004
[PDReq] Miyakawa, S., Droms, R., "Requirements for IPv6 prefix
delegation", Work in Progress, February 2004
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC2119, March 1997.
[IPv6-DISC] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC2461, December, 1998.
[ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[IPv6-AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[IPv6-ESP] Kent, S., R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
Arun & Shankar Expires October 30, 2004 [Page 32]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
11. Authors' Addresses
Arun Thulasi Shankar Raman
Hewlett-Packard, Hewlett-Packard,
29, Cunningham Road, 29, Cunningham Road,
Bangalore - 560052 Bangalore - 560052
India. India.
arun_thulasi@hp.com shankar_r@hp.com
Appendix A : Usage of Service Bands & Discretion Flag
Service Bands can be used for various reasons. A DR can use a Service
Band to distinguish between various customers. The number of prefixes
that would be delegated to a RR, the Lifetimes of those prefixes,
Revoking of prefixes and Renewal of prefixes could be streamlines
using Service Bands.
For example, a customer with a certain Service Band could be allowed
more renewals than a customer with a lower Service Band. Service
Bands serve as an important tool for the DR to apply policy based
delegation.
At the time of specifying this mechanism, the DR is eligible to
define it's own service bands. Further discussions may result in
well known Service Bands being identified.
The Discretion bit is aimed to allow complete freedom on the part of
the DR, provided the RR is okay with it. In cases, where the RR
wishes to check if this DR has a certain prefix that it requires, it
can send a PS message with the prefixes and the Discretion bit unset.
It also helps in cases when the RR is specific about having certain
Valid Lifetimes for the prefixes that it requires. In such cases, the
RR can unset the Discretion bit to let the DR know that it should not
apply it's discretion while delegating the prefixes.
If the Discretion bit is set, it also allows the DR to exercise its
discretion on Valid Lifetimes and Block of Prefixes.
Appendix B : Implementation Suggestions on Usage of Prefix States
The Deprecated State can be used as a method to block flood of
renewal messages. Unless the Prefix passes on to Deprecated State,
renewal messages would not be entertained and would be silently
ignored. This could help in preventing a DOS attack using Renewal
Messages.
Appendix C : Future Options
Future options could be added to share other information between
RRs and DRs. Some of the options that have been considered at the
time of specifying this mechanism are
- Synchronizing Global values between RR and DR
Arun & Shankar Expires October 30, 2004 [Page 33]
Internet-Draft IPv6 Prefix Delegation Using ICMPv6 April 2004
This would help in the RR and DR knowing information about each
other.
- Accounting Information Requests from DR to RR
If the DR wishes to have accounting information on the usage of
prefixes, these requests would help in it.
- Current Status of a Prefix from RR to DR
At times, a RR might want to get details about the prefixes that
it has been allocated with. It could use this option to query the
Current State and Status of the prefix.
- Reservation of a prefix by the RR with the DR
The RR might want to reserve a prefix with the DR which it would
start using after a specified amount of time. The Reservation
Option would facilitate this.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assigns.
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.
Acknowledgments
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arun & Shankar Expires October 30, 2004 [Page 34]
