# NAME

recvNsInvalid - Verify that NUT ignores invalid NSs

# TARGET

Host and Router

# SYNOPSIS

      recvNsInvalid.seq [-tooloption ...] -p recvNsInvalid.def

# INITIALIZATION

      Clear NC state for TN.

# TEST PROCEDURE

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.

# JUDGMENT

      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.

# TERMINATION

      N/A

# NOTE

      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.

# SEE ALSO

      perldoc V6evalTool
      perldoc V6evalRemote