C_RFC3315_21.4.4.3_SendConf.seq - Sending Confirm message
Client
C_RFC3315_21.4.4.3_SendConf.seq [-tooloption...]
-pkt C_RFC3315_21.4.4.3_SendConf.def
-tooloption : v6eval tool option
See Also DHCPv6.def
NUT(Client)
|
|
Link0 --+--------+------------------------ 3ffe:501:ffff:100::/64
|
|
TN(Server)
If the client authenticated the Advertise message through which the
client selected the server, the client MUST generate authentication
information for subsequent Confirm messages sent to the server.
When the client sends a subsequent message, it MUST use the same key
used by the server to generate the authentication information.
- Configurations
Enable Delayed Authenticaion Protocol Service
Authenticaion parameter
- DHCP realm: DHCPv6.TEST.EXAMPLE.COM
- Client DUID: ANY
- Key id: 1
- Shared secret key: TAHITEST_VALID12
| Device Name |
Device Type |
Interface |
Assigned Prefix |
Link Local Addr |
MAC Addr |
| Client |
NUT |
Link0 |
|
NUT's Linklocal address |
NUT's MAC address |
| Server |
TN |
Link0 |
3ffe:501:ffff:100:200:ff:fe00:a1a1 |
fe80::200:ff:fe00:a1a1 |
00:00:00:00:a1:a1 |
NUT TN
| |
| |Initialize NUT (as a DHCPv6 client)
| |
| ----> |Solicit w/ Authentication Option
| <---- |Advertise w/ Authentication Option
| ----> |Request w/ Authentication Option
| <---- |Reply w/ Authentication Option
| |
| <---- |Echo Request
| ----> |Echo Reply
| |
| |Restart NUT
| |
| ----> |Confirm (7*)
| <---- |Reply
| |
| <---- |Echo Request
| ----> |Echo Reply (10*)
| |
(7*)PASS: TN receives Confirm w/ Authentication Option from NUT.
(10*)PASS: NUT should send Echo Reply to TN.
N/A
see also RFC3315
21.4.4 Client Considerations for Delayed Authentication protocol
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
Messages
perldoc V6evalTool