recvNsInvalid - Verify that NUT ignores invalid NSs
Host and Router
recvNsInvalid.seq [-tooloption ...] -p recvNsInvalid.def
Clear NC state for TN.
recvNsInvalid verifies that NUT ignores invalid NSs.
TN NUT ----------------------
State: NONCE
==== invalid NS ===>
Judgment #2: Not to capture any packet from NUT within 5 sec.
1. NUT must ignore the following NS:
Source |Destination |Hop|Target |SLL ============+====================+===+===================+====== link-local link-local 255 *all-node multicast exist ------------+--------------------+---+-------------------+------ *unspecified *link-local 255 link-local none ------------+--------------------+---+-------------------+------ *unspecified sol-node[link-local] 255 link-local *exist ------------+--------------------+---+-------------------+------ link *sol-node[link-local]255 link-local *none ------------+--------------------+---+-------------------+------ link-local link-local *2 link-local exist ============+====================+===+===================+====== 2. NUT does not sends any packet.
N/A
1. The test does not invoke any remote command.
2. An implementation may send a NA in response to the NS (src=unspecified, with SLLA option) because of backward compatibility with RFC1970. RFC defined the NS as valid, whereas RFC2461 defined the NS as invalid. In such case, this test judges "WARN" that never means the implementation is wrong. The test intends to inform such behavior.
RFC1970
4.3. Neighbor Solicitation Message Format
IP Fields:
Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address.
Possible options:
Source link-layer address The link-layer address for the sender. On link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations.
RFC2461
4.3. Neighbor Solicitation Message Format
Possible options:
Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations.
3. An implementation may send a NA in response to the NS (src=solicited-node multicast, without SLLA option). The NS is not invalid as a receiver side, whereas it is invalid as a sender side (please see the following). In such case, this test judges "WARN" that never means the implementation is wrong. The test intends to inform such behavior.
RFC2461 Sender side:
4.3. Neighbor Solicitation Message Format
Possible options:
Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations.
RFC2461 Receiver side:
7.1.1. Validation of Neighbor Solicitations
A node must silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- If the message includes an IP Authentication Header, the message authenticates correctly.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- Target Address is not a multicast address.
- All included options have a length that is greater than zero.
- If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address.
- If the IP source address is the unspecified address, there is no source link-layer address option in the message.
perldoc V6evalTool perldoc V6evalRemote