RRSolicit.seq - Requesting Router behavior for Prefix Delegation
Router for DHCP client
RRSolicit.seq [-tooloption ...] -pkt RRSolicit.def
-tooloption : v6eval tool option
TN TN1 TN2
| | | ISP site
--+----+---+---+------- Link0
|
NUT Host
| | Customer site
-------+-------+------- Link1 3ffe:501:ffff:XXXX::/64
| TN |
Link-local |
fe80::200:ff:fe00:a0a0 |
| Ether |
00:00:00:00:a0:a0 |
| Delegate Prefix |
3ffe:501:ffff:: |
| Prefix Length |
48 |
| TN1 |
Link-local |
fe80::200:ff:fe00:a1a1 |
| Ether |
00:00:00:00:a1:a1 |
| Delegate Prefix |
3ffe:501:ffff:: |
| Prefix Length |
48 |
| TN2 |
Link-local |
fe80::200:ff:fe00:a2a2 |
| Ether |
00:00:00:00:a2:a2 |
| Delegate Prefix |
3ffe:501:ffff:: |
| Prefix Length |
48 |
| Host |
Link-local |
fe80::200:ff:fe00:101 |
| ether |
00:00:00:00:01:01 |
- NUT sets up Prefix Delegation.
- NUT sets up Router Advertisement to the interface by the side of downstream.
Tester as Server Target as Client Tester as Host
| | |
| | |
|<--------------------------| |
| Judgment #1 | |
| DHCP Solicit message | |
| | |
| | |
|-------------------------->| |
| DHCP Advertise message 1| |
| DHCP Advertise message 2| |
| DHCP Advertise message 3| |
| | |
|<--------------------------| |
| Judgment #2 | |
| DHCP Request message | |
| | |
| | |
|-------------------------->| |
| DHCP Reply message | |
| | |
| |<--------------------------|
| | Router Solicitation |
| | |
| |-------------------------->|
| | Judgment #3 |
| | Router Advertisement |
| | w/ delegated prefix |
| | |
|-------------------------->| |
| Router Solicitation | |
| | |
|(<------------------------)| |
| Judgment #4 | |
| No Router Advertisement | |
| w/ delegated prefix | |
| | |
v v v
1. Wait DHCP Solicit message
2. Send DHCP Advertise message 1, 2 and 3
3. Wait DHCP Request message
4. Send DHCP Reply message
5. Send Router Solicitation
6. Wait Router Advertisement
7. Send Router Solicitation from DHCP administrative domain.
8. No Router Advertisement
Addresses
Solicit, Request messages
| Src |
NUT link-local address |
| Dst |
All_DHCP_Relay_Agents_and_Servers |
All_DHCP_Relay_Agents_and_Servers FF02::1:2
Advertise message 1, Reply message
| Src |
fe80::200:ff:fe00:a0a0 |
| Dst |
NUT link-local address |
Advertise message 2
| Src |
fe80::200:ff:fe00:a1a1 |
| Dst |
NUT link-local address |
Advertise message 3
| Src |
fe80::200:ff:fe00:a1a1 |
| Dst |
NUT link-local address |
UDP Ports
Clients listen for DHCP messages on UDP port 546
Server listen for DHCP messages on UDP port 547
DHCP Messages
DHCP Solicit message
| msg-type |
SOLICIT(1) |
| transaction-id |
The transaction ID for this message exchange |
| options |
| Client Identifier Option (MUST) |
| IA_PD Option (MUST) |
| |
Code |
33 (TBD) |
| |
IAID |
The unique identifier which client specified |
| |
T1 |
ANY |
| |
T2 |
ANY |
| Elapsed Time Option (MUST) |
| |
elapsed-time |
ANY |
| Option Request Option (Optional) |
DHCP Advertise message 1, 2 and 3 doesn't include preference option.
As for the message, only Server Identifier Option differ.
DHCP Advertise message 1
| msg-type |
ADVERTISE(2) |
| transaction-id |
The same transaction ID previous message |
| options |
| Client Identifier Option |
| Server Identifier Option |
| |
DUID Contents type |
1 Link-layer address plus time |
| |
hardware type |
1 Ether |
| |
time |
Time which the server included |
| |
link-layer address |
00:00:00:00:a0:a0 |
| IA_PD Option |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
300 |
| |
T2 |
480 |
| |
IA_PD Prefix Option |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
600 |
| |
|
valid-lifetime |
1200 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:ffff:: |
DHCP Advertise message 2
| msg-type |
ADVERTISE(2) |
| transaction-id |
The same transaction ID previous message |
| options |
| Client Identifier Option |
| Server Identifier Option |
| |
DUID Contents type |
1 Link-layer address plus time |
| |
hardware type |
1 Ether |
| |
time |
Time which the server included |
| |
link-layer address |
00:00:00:00:a1:a1 |
| IA_PD Option |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
300 |
| |
T2 |
480 |
| |
IA_PD Prefix Option |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
600 |
| |
|
valid-lifetime |
1200 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:ffff:: |
DHCP Advertise message 3
| msg-type |
ADVERTISE(2) |
| transaction-id |
The same transaction ID previous message |
| options |
| Client Identifier Option |
| Server Identifier Option |
| |
DUID Contents type |
1 Link-layer address plus time |
| |
hardware type |
1 Ether |
| |
time |
Time which the server included |
| |
link-layer address |
00:00:00:00:a2:a2 |
| IA_PD Option |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
300 |
| |
T2 |
480 |
| |
IA_PD Prefix Option |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
600 |
| |
|
valid-lifetime |
1200 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:ffff:: |
DHCP Request message with IA_PD option
| msg-type |
REQUEST(3) |
| transaction-id |
The transaction ID for this message exchange |
| options |
| Client Identifier Option (MUST) |
| Server Identifier Option (MUST) |
| |
DUID Contents type |
1 Link-layer address plus time |
| |
hardware type |
1 Ether |
| |
time |
Time which the server included |
| |
link-layer address |
00:00:00:00:a0:a0 |
| IA_PD Option (MUST) |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
ANY |
| |
T2 |
ANY |
| |
IA_PD Prefix Option (Optional) |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
ANY |
| |
|
valid-lifetime |
ANY |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:ffff:: |
| Elapsed Time Option (MUST) |
| |
elapsed-time |
ANY |
| Option Request Option (Optional) |
DHCP Reply message with IA_PD option including IA_Prefix option
| msg-type |
REPLY(7) |
| transaction-id |
The same transaction ID previous message |
| options |
| Client Identifier Option |
| Server Identifier Option |
| |
DUID Contents type |
1 Link-layer address plus time |
| |
hardware type |
1 Ether |
| |
time |
Time which the server included |
| |
link-layer address |
00:00:00:00:a0:a0 |
| IA_PD Option |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
300 |
| |
T2 |
480 |
| |
IA_PD Prefix Option |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
600 |
| |
|
valid-lifetime |
1200 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:ffff:: |
1. DHCP Solicit message is recieved
2. DHCP Request message is recieved
3. Router Advertisement is recieved include delegated prefix, validlifietime less than validlifetime of IA_PD prefix option and prefix-length logner than delegated prefix-length
4. Router Advertisement is not received on PE side link.
N/A
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt
10. Delegating Router Solicitation
The requesting router locates and selects a delegating router in the
same way as described in section "DHCP Server Solicitation" of the
DHCP specification [6]. The details of the solicitation process are
described in this section.
10.1 Requesting router behaviour
The requesting router creates and transmits a Solicit message as
described in sections "Creation of Solicit Messages" and
"Transmission of Solicit Messages" of the DHCP specification [6].
The requesting router creates an IA_PD and assigns it an IAID. The
requesting router MUST include the IA_PD option in the Solicit
message.
11. Requesting router initiated prefix delegation
A requesting router uses the same message exchanges as described in
section "DHCP Client-Initiated Configuration Exchange" of the DHCP
specification [6] to obtain or update prefix(es) from a delegating
router. The requesting router and the delegating router use the
IA_PD Prefix option to exchange information about prefix(es) in much
the same way IA Address options are used for assigned addresses.
11.1 Requesting router behaviour
The requesting router uses a Request message to populate IA_PDs with
prefixes. The requesting router includes one or more IA_PD options
in the Request message. The delegating router then returns the
prefixes for the IA_PDs to the requesting router in IA_PD options in
a Reply message.
Upon the receipt of a valid Reply message, the requesting router
assigns a subnet from each of the delegated prefixes to each of the
links to which it is attached, with the following exception: the
requesting router MUST NOT assign any delegated prefixes or subnets
from the delegated prefix(es) to the link through which it received
the DHCP message from the delegating router.
If the requesting router assigns a delegated prefix to a link to
which the router is attached, and begins to send router
advertisements for the prefix on the link, the requesting router MUST
set the valid lifetime in those advertisements to be no later than
the valid lifetime specified in the IA_PD Prefix option. A
requesting router MAY use the preferred lifetime specified in the
IA_PD Prefix option.
draft-ietf-dhc-dhcpv6-28.txt
14. Reliability of Client Initiated Message Exchanges
see the retransmission mechanism
15. Message Validation
15.2. Solicit Message
Clients MUST discard any received Solicit messages.
Servers MUST discard any Solicit messages that do not include a
Client Identifier option or that do include a Server Identifier
option.
15.4. Request Message
Clients MUST discard any received Request messages.
Servers MUST discard any received Request message that meet any of
the following conditions:
- the message does not include a Server Identifier option
- the contents of the Server Identifier option do not match the
server's DUID
- the message does not include a Client Identifier option
17. DHCP Server Solicitation
17.1.1. Creation of Solicit Messages
The client sets the "msg-type" field to SOLICIT. The client generates
a transaction ID and inserts this value in the "transaction-id"
field.
The client MUST include a Client Identifier option to identify itself
to the server. The client includes IA options for any IAs to which
it wants the server to assign addresses. The client MAY include
addresses in the IAs as a hint to the server about addresses for
which the client has a preference. The client MUST NOT include any
other options in the Solicit message except as specifically allowed
in the definition of individual options.
The client uses IA_NA options to request the assignment of
non-temporary addresses and uses IA_TA options to request the
assignment of temporary addresses. Either IA_NA or IA_TA options, or
a combination of both can be included in DHCP messages.
The client SHOULD include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY additionally include instances of those options that are
identified in the Option Request option with data values as hints
to the server about parameter values the client would like to have
returned.
The client includes a Reconfigure Accept option (see section 22.20)
if the client is willing to accept Reconfigure messages from the
server.
17.1.2. Transmission of Solicit Messages
The first Solicit message from the client on the interface MUST be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. In
the case of a Solicit message transmitted when DHCP is initiated
by IPv6 Neighbor Discovery, the delay gives the amount of time to
wait after IPv6 Neighbor Discovery causes the client to invoke the
stateful address autoconfiguration protocol (see section 5.5.3 of
RFC2462). This random delay desynchronizes clients which start at
the same time (for example, after a power outage).
The client transmits the message according to section 14, using the
following parameters:
IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
If the client is waiting for an Advertise message, the mechanism in
section 14 is modified as follows for use in the transmission of
Solicit messages. The message exchange is not terminated by the
receipt of an Advertise before the first RT has elapsed. Rather, the
client collects Advertise messages until the first RT has elapsed.
Also, the first RT MUST be selected to be strictly greater than IRT
by choosing RAND to be strictly greater than 0.
A client MUST collect Advertise messages for the first RT seconds,
unless it receives an Advertise message with a preference value
of 255. The preference value is carried in the Preference option
(section 22.8). Any Advertise that does not include a Preference
option is considered to have a preference value of 0. If the client
receives an Advertise message that includes a Preference option
with a preference value of 255, the client immediately begins a
client-initiated message exchange (as described in section 18) by
sending a Request message to the server from which the Advertise
message was received. If the client receives an Advertise message
that does not include a Preference option with a preference value of
255, the client continues to wait until the first RT elapses. If the
first RT elapses and the client has received an Advertise message,
the client SHOULD continue with a client-initiated message exchange
by sending a Request message.
If the client does not receive any Advertise messages before
the first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and the client
acts on the received Advertise message without waiting for any
additional Advertise messages.
18. DHCP Client-Initiated Configuration Exchange
18.1.1. Creation and Transmission of Request Messages
The client uses a Request message to populate IAs with addresses and
obtain other configuration information. The client includes one or
more IA options in the Request message. The server then returns
addresses and other information about the IAs to the client in IA
options in a Reply message.
The client generates a transaction ID and inserts this value in the
"transaction-id" field.
The client places the identifier of the destination server in a
Server Identifier option.
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any other appropriate options,
including one or more IA options (if the client is requesting that
the server assign it some network addresses).
The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.
The client includes a Reconfigure Accept option (see section
indicating whether or not the client is willing to accept Reconfigure
messages from the server.
The client transmits the message according to section 14, using the
following parameters:
IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
MRD 0
18.1.8. Receipt of Reply Messages
Upon the receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, the client extracts the configuration
information contained in the Reply. The client MAY choose to report
any status code or message from the status code option in the Reply
message.
The client SHOULD perform duplicate address detection [21] on each
of the addresses in any IAs it receives in the Reply message before
using that address for traffic. If any of the addresses are found
to be in use on the link, the client sends a Decline message to the
server as described in section 18.1.7.
If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client updates
the information it has recorded about IAs from the IA options
contained in the Reply message:
- Record T1 and T2 times
- Add any new addresses in the IA option to the IA as recorded by
the client
- Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA
- Discard any addresses from the IA as recorded by the client that
have a valid lifetime of 0 in the IA Address option
5.5. Transmission and Retransmission Parameters
This section presents a table of values used to describe the message
transmission behavior of clients and servers.
Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
24.2. DHCP Message Types
IANA is requested to record the following message types (defined
in section 5.3). IANA is requested to maintain a registry of DHCP
message types.
SOLICIT 1
ADVERTISE 2
REQUEST 3
REPLY 7
A. Appearance of Options in Message Types
The following table indicates with a "*" the options are allowed in
each DHCP message type:
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * * *
Request * * * * * *
Reply * * * * * * *
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Reply * * * * * *
perldoc V6evalTool