RRSolicitRapid.seq - Requesting Router has sent Solicit message with Rapid Commit option
Router for DHCP Client
RRSolicitRapid.seq [-tooloption ...] -pkt RRSolicitRapid.def -tooloption : v6eval tool option
TN
| ISP site
----+-------+------- Link0
|
NUT Host
| | Customer site
-------+-------+------- Link1 3ffe:501:fffe:XXXX::/64
| TN |
Link-local |
fe80::200:ff:fe00:a0a0 |
| Ether |
00:00:00:00:a0:a0 |
| Delegate Prefix |
3ffe:501:fffe:: |
| Prefix Length |
48 |
| Host |
Link-local |
fe80::200:ff:fe00:101 |
| ether |
00:00:00:00:01:01 |
- NUT sets up Prefix Delegation with Rapid Commit option.
- 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 | |
| w/ Rapid Commit option | |
| | |
|-------------------------->| |
| DHCP Reply message | |
| w/o Rapid Commit option | |
| | |
|<--------------------------| |
| Judgment #2 | |
| DHCP Solicit message | |
| w/ Rapid Commit option | |
| | |
|-------------------------->| |
| DHCP Reply message | |
| w/ Rapid Commit option | |
| | |
| |<--------------------------|
| | Router Solicitation |
| | |
| |-------------------------->|
| | Judgment #3 |
| | Router Advertisement |
| | |
| | |
v v v
1. Wait DHCP Solicit message with Rapid Commit option
2. Send DHCP Reply message without Rapid Commit option
3. Wait DHCP Solicit message with Rapid Commit option
4. Send DHCP Reply message with Rapid Commit option
5. Send Router Solicitation
6. Wait Router Advertisement
Addresses
Solicit message
| Src |
NUT link-local address |
| Dst |
All_DHCP_Relay_Agents_and_Servers |
All_DHCP_Relay_Agents_and_Servers FF02::1:2
Reply message
| Src |
fe80::200:ff:fe00:a0a0 |
| 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 with Rapid Commit option
| 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 |
| Rapid Commit Option (MUST) |
| Option Request Option (Optional) |
DHCP Reply message without Rapid Commit 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:fffe:: |
DHCP Reply message with Rapid Commit 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:fffe:: |
| Rapid Commit Option |
1. DHCP Solicit message with Rapid Commit option is recieved.
2. NUT ignore the DHCP Reply message without Rapid Commit option. DHCP Solicit message with Rapid Commit option is recieved again.
3. Router Advertisement is recieved include delegated prefix.
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
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.
17. DHCP Server Solicitation
If the client will accept a Reply message with committed address
assignments and other resources in response to the Solicit message,
the client includes a Rapid Commit option (see section 22.14) in the
Solicit message.
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.
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.
17.1.4. Receipt of Reply Message
If the client includes a Rapid Commit option in the Solicit message,
it will expect a Reply message that includes a Rapid Commit option
in response. The client discards any Reply messages it receives
that do not include a Rapid Commit option. If the client receives
a valid Reply message that includes a Rapid Commit option, it
processes the message as described in section 18.1.8. If it does
not receive such a Reply message and does receive a valid Advertise
message, the client processes the Advertise message as described in
section 17.1.3.
18. DHCP Client-Initiated Configuration Exchange
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
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
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 * * * * *
Reply * * * * * * *
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Reply * * * * * *
perldoc V6evalTool