RRRebindPhysical.seq - Requesting router performs Rebind/Reply message exchange when the requesting router is physically disconnected from a wired connection.
Router for DHCP client
TN
| ISP site
--+----+--------------- Link0
|
NUT Host
| | Customer site
-------+-------+------- Link1 3ffe:501:fffa:XXXX::/64
| TN |
Link-local |
fe80::200:ff:fe00:a0a0 |
| Ether |
00:00:00:00:a0:a0 |
| Delegate Prefix |
3ffe:501:fffa:: |
| 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
| | |
|<--------------------------| |
| DHCP Solicit message | |
| | |
|-------------------------->| |
| DHCP Advertise message | |
| | |
|<--------------------------| |
| DHCP Request message | |
| | |
|-------------------------->| |
| DHCP Reply message | |
| | |
| | |
1. Wait DHCP Solicit message
2. Send DHCP Advertise message
3. Wait DHCP Request message
4. Send DHCP Reply message
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, 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
| 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
| 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 |
40 |
| |
T2 |
64 |
| |
IA_PD Prefix Option |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
80 |
| |
|
valid-lifetime |
120 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:fffa:: |
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:fffa:: |
| 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 |
40 |
| |
T2 |
64 |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
80 |
| |
|
valid-lifetime |
120 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:fffa:: |
Tester as PE Target as CPE Tester as client
| | |
| Upstream Link is | |
| down and up | |
| | |
|<--------------------------| |
| Judgment #1 | |
| DHCP Rebind message | |
| | |
|-------------------------->| |
| DHCP Reply message | |
| | |
| |<--------------------------|
| | Router Solicitation |
| | |
| |-------------------------> |
| | Judgment #2 |
| | Router Advertisement |
| | |
| | |
v v
1. Wait DHCP Rebind message
2. Send DHCP Reply message including updated information about the IA_PD
3. Send Router Solicitation
4. Wait Router Advertisement including updated prefix information
Addresses
Rebind 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 Rebind message with IA_PD option including IA_PD Prefix option
| msg-type |
REBIND(6) |
| transaction-id |
The transaction ID for this message exchange |
| options |
| Client Identifier Option (MUST) |
| IA_PD Option (MUST) |
| |
Code |
33 (TBD) |
| |
IAID |
Unique identifier which client specified |
| |
T1 |
ANY |
| |
T2 |
ANY |
| |
IA_PD Prefix Option (MUST) |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
ANY |
| |
|
valid-lifetime |
ANY |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:fffa:: |
| Elapsed Time Option (MUST) |
| |
elapsed-time |
ANY |
| Option Request Option (Optional) |
DHCP Reply message updated information about the IA_PD
| 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 |
80 |
| |
T2 |
192 |
| |
|
Code |
34 (TBD) |
| |
|
preferred-lifetime |
160 |
| |
|
valid-lifetime |
240 |
| |
|
prefix-length |
48 |
| |
|
IPv6 prefix |
3ffe:501:fffa:: |
1. DHCP Rebind message is recieved
2. Router Advertisement is recieved updated information
N/A
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
12. 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.
12.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.
The requesting router includes IA_PD options in any Renew, or Rebind
messages sent by the requesting router. The IA_PD option includes
all of the prefixes the requesting router currently has associated
with that IA_PD.
In some circumstances the requesting router may need verification
that the delegating router still has a valid binding for the
requesting router. Examples of times when a requesting router may
ask for such verification include:
o The requesting router reboots.
o The requesting router's upstream link flaps.
o The requesting router is physically disconnected from a wired
connection.
If such verification is needed the requesting router MUST initiate a
Rebind/Reply message exchange as described in the section "Creation
and Transmission of Rebind Messages" of the DHCP specification [6],
with the exception that the retransmission parameters should be set
as for the Confirm message, described in the section "Creation and
Transmission of Confirm Messages" of the DHCP specification [6]. The
requesting router includes any IA_PDs, along with prefixes associated
with those IA_PDs in its Rebind message.
Each prefix has valid and preferred lifetimes whose durations are
specified in the IA_PD Prefix option for that prefix. The requesting
router uses Renew and Rebind messages to request the extension of the
lifetimes of a delegated prefix.
The requesting router uses a Release message to return a delegated
prefix to a delegating router. The prefixes to be released MUST be
included in the IA_PDs.
The Confirm and Decline message types are not used with Prefix
Delegation.
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
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.
When a requesting router subnets a delegated prefix, it must assign
additional bits to the prefix to generate unique, longer prefixes.
For example, if the requesting router in Figure 1 were delegated
3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
network. If the requesting router were delegated 3FFE:FFFF:0::/48
and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and
3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and
3FFE:FFFF:5:2::/64 for assignment to the other link.
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.
RFC3315
14. Reliability of Client Initiated Message Exchanges
see the retransmission mechanism
15. Message Validation
15.7. Rebind Message
Clients MUST discard any received Rebind messages.
Servers MUST discard any received Rebind messages that do not include
a Client Identifier option or that do include a Server Identifier
option.
18. DHCP Client-Initiated Configuration Exchange
A client initiates a message exchange with a server or servers
to acquire or update configuration information of interest. The
client may initiate the configuration exchange as part of the
operating system configuration process, when requested to do
so by the application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address
(Renew and Rebind messages).
18.1. Client Behavior
A client uses Request, Renew, Rebind, Release and Decline messages
during the normal life cycle of addresses. It uses Confirm to
validate addresses when it may have moved to a new link. It uses
Information-Request messages when it needs configuration information
but no addresses.
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 22.12) from the server, the client
SHOULD unicast any Request, Renew, Release and Decline messages to
the server.
DISCUSSION:
Use of unicast may avoid delays due to relaying of messages
by relay agents as well as avoid overhead and duplicate
responses by servers due to delivery of client messages to
multiple servers. Requiring the client to relay all DHCP
messages through a relay agent enables the inclusion of
relay agent options in all messages sent by the client. The
server should enable the use of unicast only when relay
agent options will not be used.
18.1.4. Creation and Transmission of Rebind Messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
The client sets the "msg-type" field to REBIND. 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 adds any appropriate options,
including one or more IA options. The client MUST include the list
of addresses the client currently has associated with the IAs in the
Rebind message.
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 transmits the message according to section 14, using the
following parameters:
IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Remaining time until valid lifetimes of all addresses have
expired
The message exchange is terminated when the valid lifetimes of all of
the addresses assigned to the IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:
- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs
18.1.2. Creation and Transmission of Confirm Messages
The first Confirm message from the client on the interface MUST be
delayed by a random amount of time between 0 and CNF_MAX_DELAY. The
client transmits the message according to section 14, using the
following parameters:
IRT CNF_TIMEOUT
MRT CNF_MAX_RT
MRC 0
MRD CNF_MAX_RD
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
-------------------------------------
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
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
REBIND 6
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.
Rebind * * * * *
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Rebind * * * *
perldoc V6evalTool