S_RFC3315_21.4.5.2_InfoReqInvalid.seq - Receiving invalid Information-Request message and discard
Server
S_RFC3315_21.4.5.2_InfoReqInvalid.seq[-tooloption ...]
-pkt S_RFC3315_21.4.5.2_InfoReqInvalid.def
-tooloption: v6eval tool option. See also DHCPv6.def
TN(Client1)
|
Link0 -------+-----------+--------------- 3ffe:501:ffff:100::/64
|
NUT(Server1)
The server uses the key identified in the message and validates the
message as specified in section 21.4.2. If the message fails to pass
the validation test or the server does not know the key identified by
the 'key ID' field, the server MUST discard the message and MAY
choose to log the validation failure.
- Configuration
Enable Delayed Authenticaion Protocol Service
Authenticaion parameter
- DHCP realm: DHCPv6.TEST.EXAMPLE.COM
- Client DUID: 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2
- Key id: 1
- Shared secret key: TAHITEST_VALID12
| Device Name |
Device Type |
I/F |
Assigned Prefix |
Link Local Addr |
MAC Addr |
| Server1 |
NUT |
Link0 |
3ffe:501:ffff:100::/64 |
NUT's Linklocal address |
NUT's MAC address |
| Client1 |
TN |
Link0 |
3ffe:501:ffff:100::/64 |
fe80::200:ff:fe00:a2a2 |
00:00:00:00:a2:a2 |
NUT TN
| |
| | initialize NUT (as a DHCPv6 Server)
| |
| <---- | Release (w/ Authentication Option replay detection field short (length = 32 bit))
| --->X | No Reply (w/ Authentication Optin that includes Authentication information) (*1)
| |
(*1) PASS: If NUT received Information-Request message, the message faild the validation test,
the NUT MUST discard the message.
N/A
see also RFC3315
21.4.5 Server Considerations for Delayed Authentication protocol
21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages
and Sending Reply Messages
22.11 Authentication Option
perldoc V6evalTool