# NAME

routerRecvRa - TBD

# TARGET

Router only

# SYNOPSIS

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

# INITIALIZATION

      Clear NC state for TN.

# TEST PROCEDURE

routerRecvRa verifies that state transition for a NUT in NONCE state when receiving a RA.

      TN               NUT
      ----------------------

      State: NONCE (for TN)

      ==== RA ===>

      Judgment: Examining NUT's neighbor cache state

# JUDGMENT

      =================+=============================
      RA               | Neighbor Cache
                       +---------+-------+-----------
                       | Current | New   | LLA
      =================+=========+=======+===========
      w/o TLLA         | NONCE   | NONCE | unchanged
      -----------------+---------+-------+-----------
      w/  TLLA         | NONCE   | NONCE | unchanged
      -----------------+---------+-------+-----------
      w/ TLLA          | NONCE   | NONCE | unchanged
      src!=link-local  |         |       |
      (INVALID)        |         |       |
      -----------------+---------+-------+-----------
      w/ TLLA          | NONCE   | NONCE | unchanged
      hoplimit!=255    |         |       |
      (INVALID)        |         |       |
      -----------------+---------+-------+-----------
      w/ TLLA          | NONCE   | NONCE | unchanged
      invalid checksum |         |       |
      (INVALID)        |         |       |
      -----------------+---------+-------+-----------
      w/ TLLA          | NONCE   | NONCE | unchanged
      icmp code!=0     |         |       |
      (INVALID)        |         |       |
      =================+=========+=======+===========

# TERMINATION

      N/A

# NOTE

      RFC2461 does not describes an NCE state transition in a router when receiving RAs.
      However, it seems to be better that any RA should not affect the state.

# REFERENCE

    RFC2461

    6.2.7.  Router Advertisement Consistency

       Routers SHOULD inspect valid Router Advertisements sent by other
       routers and verify that the routers are advertising consistent
       information on a link.  Detected inconsistencies indicate that one or
       more routers might be misconfigured and SHOULD be logged to system or
       network management.  The minimum set of information to check
       includes:

        - Cur Hop Limit values (except for the unspecified value of zero).

        - Values of the M or O flags.

        - Reachable Time values (except for the unspecified value of zero).

        - Retrans Timer values (except for the unspecified value of zero).

        - Values in the MTU options.

        - Preferred and Valid Lifetimes for the same prefix.  If
          AdvPreferredLifetime and/or AdvValidLifetime decrement in real
          time as specified in section 6.2.7 then the comparison of the
          lifetimes can not compare the content of the fields in the Router
          Advertisement but must instead compare the time at which the
          prefix will become deprecated and invalidated, respectively.  Due
          to link propagation delays and potentially poorly synchronized
          clocks between the routers such comparison SHOULD allow some time
          skew.

       Note that it is not an error for different routers to advertise
       different sets of prefixes.  Also, some routers might leave some
       fields as unspecified, i.e., with the value zero, while other routers
       specify values.  The logging of errors SHOULD be restricted to
       conflicting information that causes hosts to switch from one value to
       another with each received advertisement.

       Any other action on reception of Router Advertisement messages by a
       router is beyond the scope of this document.

# SEE ALSO

      perldoc V6evalTool
      perldoc V6evalRemote