CDRouter DOCSIS Test Summaries (Full)

    step 1. Wait for DHCP lease to expire on CM
    step 2. Verify CM sends DHCPREQUEST for same IP address
    step 3. Reassign the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Disable DOCSIS DHCP server
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Enable DOCSIS DHCP server
    step 6. Verify CM resends DHCPREQUEST for same IP address
    step 7. Respond to request and reassign the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Disable DOCSIS DHCP server
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER
    step 6. Enable DOCSIS DHCP server
    step 7. Respond to request and reassign the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Configure DOCSIS DHCP server to respond to all DHCP requests with
            DHCPNAK
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Send DHCPNAK to CM
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER before any
            other messages
    step 6. Restore DOCSIS DHCP server's original behavior
    step 7. Respond to request and reassign the same IP address

    NOTE: Some DOCSIS CM interfaces may send a DHCPRELEASE when transitioning
    from into the restart state. This is not part of the normal RFC 2131 state
    machine, but DOCSIS 3.0 MAC and Upper Layer Protocols Interface
    Specification 10.2.5.2.4 requires a DHCPRELEASE for a reset.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.2: Client-server interaction - reusing a previously allocated network address

    If the client receives a DHCPNAK message, it cannot reuse its
    remembered network address.  It must instead request a new
    address by restarting the configuration process, this time
    using the (non-abbreviated) procedure described in section
    3.1.  This action also corresponds to the client moving to
    the INIT state in the DHCP state diagram.

    https://tools.ietf.org/html/rfc2131#section-3.2

    step  1. Configure DOCSIS DHCP server to respond to all DHCP requests with
             DHCPNAK
    step  2. Wait for DHCP lease to expire on CM
    step  3. Verify CM sends DHCPREQUEST for same IP address
    step  4. Send DHCPNAK to CM
    step  5. Verify CM DHCP client restarts and sends DHCPDISCOVER before any
             other messages
    step  6. Send DHCPOFFER to CM
    step  7. Verify CM DHCP client sends a broadcast DHCPREQUEST
    step  8. Send DHCPNAK to CM
    step  9. Verify CM DHCP client restarts and sends DHCPDISCOVER before any
             other DHCP message
    step 10. Restore DOCSIS DHCP server's original behavior
    step 11. Respond to request and reassign the same IP address

    NOTE: Some DOCSIS CM interfaces may send a DHCPRELEASE when transitioning
    from into the restart state. This is not part of the normal RFC 2131 state
    machine, but DOCSIS 3.0 MAC and Upper Layer Protocols Interface
    Specification 10.2.5.2.4 requires a DHCPRELEASE for a reset.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-server interaction - allocating a network address

    If the client receives a DHCPNAK message, the client restarts the
    configuration process.

    https://tools.ietf.org/html/rfc2131#section-3.1

    step 1. Disable DOCSIS DHCP server to force CM DHCP client back into
            DISCOVERY mode
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER
    step 6. Enable DOCSIS DHCP server with site specific options
    step 7. Verify DHCP client is able to obtain new IP address
    step 8. Restore DOCSIS DHCP server's original behavior


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Disable DOCSIS DHCP server to force CM DHCP client back into
            DISCOVERY mode
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER
    step 7. Enable DOCSIS DHCP server with 0 length site specific option
    step 8. Verify DHCP client is able to obtain an address
    step 9. Restore DOCSIS DHCP server's original behavior


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Configure DOCSIS DHCP server to send DHCP packets with corrupt UDP
            checksum
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Send DHCPOFFER with invalid UDP checksum
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER
    step 6. Verify CM DHCP client sends a second DHCPDISCOVER message
    step 7. Restore DOCSIS DHCP server's original behavior
    step 8. Verify DHCP client is able to obtain an address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Wait for DHCP lease to expire on CM
    step 2. Verify CM sends DHCPREQUEST for same IP address
    step 3. Reassign the same IP address
    step 4. Search DHCPREQUEST for expected options

    The testvars docsisDhcpClientOptionCode and docsisDhcpClientOptionData can
    be used to configure a list of DHCP options that the CM DHCP client should
    include in requests sent to the DHCP server.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

    step 1. Disable DOCSIS DHCP server
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Verify CM DHCP client restarts and sends DHCPDISCOVER
    step 6. Verify DHCPDISCOVER contains Rapid Commit option
    step 7. Enable DOCSIS DHCP server
    step 8. Respond to request and reassign the same IP address


    References:

    IETF RFC 4039 "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)" Section 3.1: Client/Server Operation

    https://tools.ietf.org/html/rfc4039#section-3.1

    step 1. Check existing DHCPv6 bindings of the CM
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify Valid and Preferred lifetimes for binding
    step 4. Verify that the binding has not expired


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17: DHCP Server Solicitation

    https://tools.ietf.org/html/rfc3315#section-17

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Verify Renew contains Server Identifier option (2) with correct
            server DUID
    step 4. Verify Renew contains IA_NA option (3) for same non-temporary
            address
    step 5. Send valid Reply to update binding


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.3: Creation and Transmission of Renew Messages

    To extend the valid and preferred lifetimes for the addresses
    associated with an IA, the client sends a Renew message to the server
    from which the client obtained the addresses in the IA containing an
    IA option for the IA.  The client includes IA Address options in the
    IA option for the addresses associated with the IA.  The server
    determines new lifetimes for the addresses in the IA according to the
    administrative configuration of the server.

    https://tools.ietf.org/html/rfc3315#section-18.1.3

    step 1. Configure the server to use an undefined server DUID format
    step 2. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 3. Do not respond to Renew or Rebind messages from client
    step 4. Verify client sends Solicit message and obtains an IPv6 address
    step 5. Repeat steps 1 - 4 for various undefined DUID server formats
    step 6. Reestablish the DHCPv6 binding using the original DUID format


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)

    https://tools.ietf.org/html/rfc3315#section-9

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains IA_NA option (3)
    step 5. Respond to first Solicit message with incorrect Client
            Identifier option(1) DUID
    step 6. Verify client restransmits Solicit message
    step 7. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Messages

    If the client does not receive any Advertise messages before the
    first RT has elapsed, it begins the retransmission mechanism
    described in section 14.  The client terminates the retransmission
    process as soon as it receives any Advertise message, and the client
    acts on the received Advertise message without waiting for any
    additional Advertise messages.

    https://tools.ietf.org/html/rfc3315#section-17.1.2

    step 1. Send invalid DHCPv6 packet with message type 0 to CM client
    step 2. Verify that client does not respond to packet transmitted
            in Step 1
    step 3. Repeat steps 1 and 2 for message types 1 through 255


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"

    https://tools.ietf.org/html/rfc3315

    step 1. Configure DHCPv6 server to use a large User Class option (15)
            to force IPv6 fragmentation
    step 2. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 3. Do not respond to Renew or Rebind messages from client
    step 4. Verify client sends Solicit message
    step 5. Respond to first Solicit message with Advertise containing
            large User Class Option (15) causing fragmentation
    step 6. Verify client sends valid Request in response to Advertise
    step 7. Disable server User Class option (15) created in Step 1
    step 8. If client fails Step 6, cleanup and wait for client to
            retransmit Solicit message
    step 9. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1: Client Behavior

    https://tools.ietf.org/html/rfc3315#section-18.1

    step 1. Configure DHCPv6 server to use bad UDP checksums
    step 2. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 3. Do not respond to Renew or Rebind messages from client
    step 4. Verify client sends Solicit message
    step 5. Respond to first Solicit message with Advertise containing
            invalid UDP checksum
    step 6. Verify client does not send valid Request in response to
            Advertise
    step 7. Configure DHCPv6 server to use valid UDP checksums
    step 8. Wait for client to retransmit Solicit message
    step 9. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"

    https://tools.ietf.org/html/rfc3315

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Inspect the composition of the DUID to ensure correctness


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)

    https://tools.ietf.org/html/rfc3315#section-9

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Verify Renew contains IA_NA option (3) for same non-temporary
            address
    step 4. Send valid DHCPv6 Reply with NoBinding status code (3)
    step 5. Verify DHCPv6 client sends Request message
    step 6. Verify Request contains IA_NA option (3) for same non-temporary
            address


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.8: Receipt of Reply Messages

    When the client receives a Reply message in response to a Renew or
    Rebind message, the client examines each IA independently.  For each
    IA in the original Renew or Rebind message, the client:

    -  sends a Request message if the IA contained a Status Code option
       with the NoBinding status (and does not send any additional
       Renew/Rebind messages)

    -  sends a Renew/Rebind if the IA is not in the Reply message

    -  otherwise accepts the information in the IA

    https://tools.ietf.org/html/rfc3315#section-18.1.8

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Verify Renew contains IA_NA option (3) for same non-temporary
            address
    step 4. Send valid DHCPv6 Reply with UnspecFail status code (1)
    step 5. Verify DHCPv6 client recovers by retransmitting Renew or
            sending Request
    step 6. Verify Renew or Request contains IA_NA option (3) for same
            non-temporary address


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.8: Receipt of Reply Messages

    If the client receives a Reply message with a Status Code containing
    UnspecFail, the server is indicating that it was unable to process
    the message due to an unspecified failure condition.  If the client
    retransmits the original message to the same server to retry the
    desired operation, the client MUST limit the rate at which it
    retransmits the message and limit the duration of the time during
    which it retransmits the message.

    https://tools.ietf.org/html/rfc3315#section-18.1.8

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            T1 to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Do not respond to Renew message
    step 4. Verify DHCPv6 client sends Rebind message
    step 5. Verify Rebind contains IA_NA option (3) for same non-temporary
            address
    step 6. Send valid Reply to update binding


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages

    At time T2 for an IA (which will only be reached if the server to
    which the Renew message was sent at time T1 has not responded), the
    client initiates a Rebind/Reply message exchange with any available
    server.  The client includes an IA option with all addresses
    currently assigned to the IA in its Rebind message.

    https://tools.ietf.org/html/rfc3315#section-18.1.4

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains IA_NA option (3)
    step 5. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages

    The message exchange is terminated when the valid lifetimes of all
    the addresses assigned to the IA expire (see section 10), at which
    time the client has several alternative actions to choose from; for
    example:

    -  The client may choose to use a Solicit message to locate a new
       DHCP server and send a Request for the expired IA to the new
       server.

    -  The client may have other addresses in other IAs, so the client
       may choose to discard the expired IA and use the addresses in the
       other IAs.

    https://tools.ietf.org/html/rfc3315#section-18.1.4

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains IA_NA option (3)
    step 5. Do not respond to first Solicit message
    step 6. Verify client restransmits Solicit message
    step 7. Verify retransmitted Solicit message contains same transaction
            ID as first Solicit message
    step 8. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.1: Use of Transaction IDs

    The "transaction-id" field holds a value used by clients and servers
    to synchronize server responses to client messages.  A client SHOULD
    generate a random number that cannot easily be guessed or predicted
    to use as the transaction ID for each new message it sends.  Note
    that if a client generates easily predictable transaction
    identifiers, it may become more vulnerable to certain kinds of
    attacks from off-path intruders.  A client MUST leave the transaction
    ID unchanged in retransmissions of a message.

    https://tools.ietf.org/html/rfc3315#section-15.1

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Messages

    If the client does not receive any Advertise messages before the
    first RT has elapsed, it begins the retransmission mechanism
    described in section 14.  The client terminates the retransmission
    process as soon as it receives any Advertise message, and the client
    acts on the received Advertise message without waiting for any
    additional Advertise messages.

    https://tools.ietf.org/html/rfc3315#section-17.1.2

    step 1.  Wait for DHCPv6 client's current non-temporary address binding
             to expire
    step 2.  Do not respond to Renew or Rebind messages from client
    step 3.  Verify client sends Solicit message
    step 4.  Verify Solicit contains IA_NA option (3)
    step 5.  Send valid Advertise message
    step 6.  Verify client sends Request message containing IA_NA option (3)
    step 7.  Do not respond to Request message
    step 8.  Verify client retransmists Request message
    step 9.  Verify retransmitted Request message contains same transaction
             ID as first Request message
    step 10. Send valid Advertise message and wait for transaction to
             finish

    NOTE: This test will not work if Rapid-Commit is used!


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 14: Reliability of Client Initiated Message Exchanges

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in sections 17 and 18.
    If a DHCP client fails to receive an expected response from a server,
    the client must retransmit its message.  This section describes the
    retransmission strategy to be used by clients in client-initiated
    message exchanges.

    https://tools.ietf.org/html/rfc3315#section-14

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.1: Use of Transaction IDs

    The "transaction-id" field holds a value used by clients and servers
    to synchronize server responses to client messages.  A client SHOULD
    generate a random number that cannot easily be guessed or predicted
    to use as the transaction ID for each new message it sends.  Note
    that if a client generates easily predictable transaction
    identifiers, it may become more vulnerable to certain kinds of
    attacks from off-path intruders.  A client MUST leave the transaction
    ID unchanged in retransmissions of a message.

    https://tools.ietf.org/html/rfc3315#section-15.1

    step 1. Configure DHCPv6 server to use unknown DHCPv6 option type
    step 2. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 3. Do not respond to Renew or Rebind messages from client
    step 4. Verify client sends Solicit message
    step 5. Respond to first Solicit message with Advertise containing
            unknown DHCPv6 option type
    step 6. Verify client sends valid Request in response to Advertise
    step 7. Disable unknown DHCPv6 server option
    step 8. If client fails Step 6, cleanup and wait for client to
            retransmit Solicit message
    step 9. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1: Client Behavior

    https://tools.ietf.org/html/rfc3315#section-18.1

    step 1. Configure DHCPv6 server to use unknown DHCPv6 option type
            with invalid length
    step 2. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 3. Do not respond to Renew or Rebind messages from client
    step 4. Verify client sends Solicit message
    step 5. Respond to first Solicit message with Advertise containing
            unknown DHCPv6 option type
    step 6. Verify client does not send valid Request in response to
            Advertise
    step 7. Disable unknown DHCPv6 server option
    step 8. Wait for client to retransmit Solicit message
    step 9. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1: Client Behavior

    https://tools.ietf.org/html/rfc3315#section-18.1

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains IA_NA option (3)
    step 5. Verify Solicit contains Elapsed Time option (8) with value of 0
    step 6. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.9: Elapsed Time Option

    A client MUST include an Elapsed Time option in messages to indicate
    how long the client has been trying to complete a DHCP message
    exchange.  The elapsed time is measured from the time at which the
    client sent the first message in the message exchange, and the
    elapsed-time field is set to 0 in the first message in the message
    exchange.

    https://tools.ietf.org/html/rfc3315#section-22.9

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains IA_NA option (3)
    step 5. Verify Solicit contains Elapsed Time option (8) with value of 0
    step 6. Do not respond to Solicit
    step 7. Verify client retransmists Solicit message
    step 8. Verify retransmitted Solicit message contains Elapsed Time option
            (8) with a value greater than 0
    step 9. Send valid Advertise message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.9: Elapsed Time Option

    A client MUST include an Elapsed Time option in messages to indicate
    how long the client has been trying to complete a DHCP message
    exchange.  The elapsed time is measured from the time at which the
    client sent the first message in the message exchange, and the
    elapsed-time field is set to 0 in the first message in the message
    exchange.

    https://tools.ietf.org/html/rfc3315#section-22.9

    step 1.  Configure DHCPv6 server to use Server Unicast Option (12)
    step 2.  Wait for DHCPv6 client's current non-temporary address binding
             to expire
    step 3.  Do not respond to Renew or Rebind messages from client
    step 4.  Verify client sends Solicit message
    step 5.  Respond to first Solicit message with Advertise containing
             Server Unicast Option (12)
    step 6.  Verify client sends valid Renew message
    step 7.  Verify Renew message in Step 6 is sent to the address in
             the Server Unicast Option (12)
    step 8.  Disable Server Unicast option (12) created in Step 1
    step 9.  If client fails Step 6, cleanup and wait for client to
             retransmit Solicit message
    step 10. Send valid Advertise message and wait for transaction to
             finish

    Reference: IETF RFC 3315 Section 22.12 "Server Unicast Option"


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.12: Server Unicast Option

    https://tools.ietf.org/html/rfc3315#section-22.12

    step 1.  Configure DHCPv6 server to use Max Solicit Timeout Option (82)
    step 2.  Wait for DHCPv6 client's current non-temporary address binding
             to expire
    step 3.  Do not respond to Renew, Rebind or Solicit messages from
             client
    step 4.  Verify client sends Solicit message
    step 5.  Verify client uses the value of the Max
             Solicit Timeout option returned by the DHCPv6 server to
             limit the maximum delay for retransmissions of its
             Solicit message


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 14: Reliability of Client Initiated Message Exchanges

    https://tools.ietf.org/html/rfc3315#section-14

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Messages

    https://tools.ietf.org/html/rfc3315#section-17.1.2

    IETF RFC 7083 "DHCPv6 SOL_MAX_RT Option" Section 6: Updates for SOL_MAX_RT and INF_MAX_RT Options to RFC 3315

    https://tools.ietf.org/html/rfc7083#section-6

    step 1. Wait for DHCPv6 client to renew address
    step 2. Search DHCPv6 Renew message from client for expected options

    The testvars docsisDhcpv6ClientOptionCode and docsisDhcpv6ClientOptionData can be
    used to configure a list of DHCP options that the client should include in
    requests sent to the DHCP server.


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"

    https://tools.ietf.org/html/rfc3315

    step 1. Wait for DHCPv6 client's current non-temporary address binding
            to expire
    step 2. Do not respond to Renew or Rebind messages from client
    step 3. Verify client sends Solicit message
    step 4. Verify Solicit contains the 'Rapid Commit' option
    step 5. Send valid Reply message and wait for transaction to
            finish


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.14: Rapid Commit Option

    A client MAY include this option in a Solicit message if the client
    is prepared to perform the Solicit-Reply message exchange described
    in section 17.1.1.

    A server MUST include this option in a Reply message sent in response
    to a Solicit message when completing the Solicit-Reply message
    exchange.

    https://tools.ietf.org/html/rfc3315#section-22.14

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetNextRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr OID
    step 3. Verify that the SNMP agent responds to the GetNextRequest
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for OIDs
            SNMPv2-MIB::sysDescr, SNMPv2-MIB::sysObjectID and
            SNMPv2-MIB::sysUpTimeInstance
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Send a large GetRequest PDU to the SNMP agent for the first
            100 OIDs returned in step 2; this GetRequest should be large
            enough to span multiple packets
    step 4. Verify that the SNMP agent responds to the fragmented
            GetRequest sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-only
            SNMPv2-MIB::sysDescr.0 OID
    step 3. Verify that the SNMP agent does not change the value of the
            specified OID


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for the
            non-existent OID .1.3.6.1.2.1.1.1.0.0
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager with a 'no such instance' error


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's interface MIB by sending consecutive GetNextRequest
            PDUs for the IF-MIB::ifIndex, IF-MIB::ifDescr, and
            IF-MIB::ifType OIDs
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's interface MIB table by sending a GetBulkRequest PDU
            for the IF-MIB::ifTable OID
    step 3. Verify that the SNMP agent responds to the GetBulkRequests
            sent by the SNMP manager
    step 4. Find the DUT's CM interface in the IF-MIB::ifTable output
            and record the current unicast outbound packet counter value
    step 5. Send 10 UDP echo packets from LAN to WAN
    step 6. Repeat steps 2 through 4
    step 7. Wait snmpUpdateDelay seconds
    step 8. Verify that the CM unicast outbound packet counter has
            incremented by at least 10 in IF-MIB::ifTable output


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to query the DUT's
            system uptime by sending a GetRequest PDU for the
            SNMPv2-MIB::sysUpTime.0 OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager and record the current system uptime
    step 4. Wait 10 seconds
    step 5. Repeat steps 2 and 3
    step 6. Verify that the system uptime has increased by at least 10
            seconds


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v1/2c user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB when a valid community string is specified
    step 3. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid community string is specified
    step 4. Repeat steps 1 and 2 for all configured SNMP v1/2c users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v3 user
    step 2. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication username is
            specified
    step 3. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication password is
            specified
    step 4. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid privacy password is specified
    step 5. Repeat steps 1 through 4 for all configured SNMP v3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v3 user
    step 2. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication protocol is used
    step 3. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid privacy protocol is used
    step 4. Repeat steps 1 through 3 for all configured SNMP v3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v2c/3 user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetBulkRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetBulkRequest
            sent by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP v2c/3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v2c/3 user
    step 2. Send an GetBulkRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr.0 OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP v2c/3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-write
            SNMPv2-MIB::sysName.0 OID
    step 3. Verify that the SNMP agent changes the value of sysName.0 by
            performing a SNMP GetResponse on the OID.

    NOTE: If the snmpAccess for the default SNMP user is read-only, do
    not consider this test a failure if the SNMP SetRequest fails.


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-write
            docsDevResetNow OID

    NOTE: If the snmpAccess for the default SNMP user is read-only, do
    not consider this test a failure if the SNMP SetRequest fails.


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetNextRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr OID
    step 3. Verify that the SNMP agent responds to the GetNextRequest
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for OIDs
            SNMPv2-MIB::sysDescr, SNMPv2-MIB::sysObjectID and
            SNMPv2-MIB::sysUpTimeInstance
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Send a large GetRequest PDU to the SNMP agent for the first
            100 OIDs returned in step 2; this GetRequest should be large
            enough to span multiple packets
    step 4. Verify that the SNMP agent responds to the fragmented
            GetRequest sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-only
            SNMPv2-MIB::sysDescr.0 OID
    step 3. Verify that the SNMP agent does not change the value of the
            specified OID


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for the
            non-existent OID .1.3.6.1.2.1.1.1.0.0
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager with a 'no such instance' error


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's interface MIB by sending consecutive GetNextRequest
            PDUs for the IF-MIB::ifIndex, IF-MIB::ifDescr, and
            IF-MIB::ifType OIDs
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's interface MIB table by sending a GetBulkRequest PDU
            for the IF-MIB::ifTable OID
    step 3. Verify that the SNMP agent responds to the GetBulkRequests
            sent by the SNMP manager
    step 4. Find the DUT's CM interface in the IF-MIB::ifTable output
            and record the current unicast outbound packet counter value
    step 5. Send 10 UDP echo packets from LAN to WAN
    step 6. Repeat steps 2 through 4
    step 7. Wait snmpUpdateDelay seconds
    step 8. Verify that the CM unicast outbound packet counter has
            incremented by at least 10 in IF-MIB::ifTable output


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to query the DUT's
            system uptime by sending a GetRequest PDU for the
            SNMPv2-MIB::sysUpTime.0 OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager and record the current system uptime
    step 4. Wait 10 seconds
    step 5. Repeat steps 2 and 3
    step 6. Verify that the system uptime has increased by at least 10
            seconds


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v1/2c user
    step 2. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid community string is specified
    step 3. Repeat steps 1 and 2 for all configured SNMP v1/2c users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v3 user
    step 2. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication username is
            specified
    step 3. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication password is
            specified
    step 4. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid privacy password is specified
    step 5. Repeat steps 1 through 4 for all configured SNMP v3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v3 user
    step 2. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid authentication protocol is used
    step 3. Verify that the SNMP manager is unable to walk the SNMP
            agent's MIB when an invalid privacy protocol is used
    step 4. Repeat steps 1 through 3 for all configured SNMP v3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v2c/3 user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetBulkRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetBulkRequest
            sent by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP v2c/3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the CM using the settings and
            options defined for the first SNMP v2c/3 user
    step 2. Send an GetBulkRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr.0 OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager
    step 4. Repeat steps 1 through 3 for all configured SNMP v2c/3 users


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-write
            SNMPv2-MIB::sysName.0 OID
    step 3. Verify that the SNMP agent changes the value of sysName.0 by
            performing a SNMP GetResponse on the OID.

    NOTE: If the snmpAccess for the default SNMP user is read-only, do
    not consider this test a failure if the SNMP SetRequest fails.


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Send a SetRequest PDU to the SNMP agent for read-write
            docsDevResetNow OID

    NOTE: If the snmpAccess for the default SNMP user is read-only, do
    not consider this test a failure if the SNMP SetRequest fails.


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

    step 1. Initiate an ICMP ping from a WAN client to the CM IP
    step 2. Verify a ICMP response is received

    step 1. Initiate an ICMP ping from a LAN client to the CM IP
    step 2. Verify a ICMP response is received

    step 1. Initiate a DNS request from the LAN client to a known host
    step 2. Verify a valid DNS response is received
    step 3. Initiate a DNS request from remoteHost to the router's WAN IP
            for the same host name
    step 4. Verify that a DNS response is not received

    NOTE: This test case will be skipped if the router has a UDP
    virtual service configured on the DNS port 53.

    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Send TCP SYN packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisTcpClosedPorts' and 'docsisTcpOpenPorts' testvars:

    testvar docsisTcpClosedPorts "2323"
    testvar docsisTcpOpenPorts "22 443"

    step 1. Send ARP replys for all LAN hosts and static LAN hosts
    step 2. Send UDP packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify no ICMP Destination Unreachable messages or UDP Echo Replies
            are received unless UDP port is configured as an open or close port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisUdpClosedPorts' and 'docsisUdpOpenPorts' testvars:

    testvar docsisUdpClosedPorts "2323"
    testvar docsisUdpOpenPorts "22 443"

    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Set the IPv4 fragmentation size to 28 bytes
    step 3. Send TCP SYN packets from WAN to each port in the port scan range
    step 4. Verify packets are not forwarded to LAN
    step 5. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 6. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisTcpClosedPorts' and 'docsisTcpOpenPorts' testvars:

    testvar docsisTcpClosedPorts "2323"
    testvar docsisTcpOpenPorts "22 443"

    step 1. Initiate an ICMP ping from a WAN client to the CM IP
    step 2. Verify a ICMP response is received

    step 1. Initiate an ICMP ping from a LAN client to the CM IP
    step 2. Verify a ICMP response is received

    step 1. Initiate a DNS request from the LAN client to a known host
    step 2. Verify a valid DNS response is received
    step 3. Initiate a DNS request from remoteHost to the router's WAN IP
            for the same host name
    step 4. Verify that a DNS response is not received

    NOTE: This test case will be skipped if the router has a UDP
    virtual service configured on the DNS port 53.

    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Send TCP SYN packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisIpv6TcpClosedPorts' and 'docsisIpv6TcpOpenPorts' testvars:

    testvar docsisIpv6TcpClosedPorts "2323"
    testvar docsisIpv6TcpOpenPorts "22 443"

    step 1. Send ARP replys for all LAN hosts and static LAN hosts
    step 2. Send UDP packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify no ICMP Destination Unreachable messages or UDP Echo Replies
            are received unless UDP port is configured as an open or close port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisIpv6UdpClosedPorts' and 'docsisIpv6UdpOpenPorts' testvars:

    testvar docsisIpv6UdpClosedPorts "2323"
    testvar docsisIpv6UdpOpenPorts "22 443"

    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Set the IPv4 fragmentation size to 28 bytes
    step 3. Send TCP SYN packets from WAN to each port in the port scan range
    step 4. Verify packets are not forwarded to LAN
    step 5. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 6. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'docsisIpv6TcpClosedPorts' and 'docsisIpv6TcpOpenPorts' testvars:

    testvar docsisIpv6TcpClosedPorts "2323"
    testvar docsisIpv6TcpOpenPorts "22 443"

    step 1. Initiate a Nmap IPv4 TCP Connect scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP Syn scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP Fin scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP Null scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP XMAS scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP PSH scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP URG scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP FIN+URG scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP FIN+PSH scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP Maimon scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 TCP ACK scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 UDP scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 SCTP Init scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 SCTP Cookie scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 scan for OS detection from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv4 scan for OS detection with version detection from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP Connect scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP Syn scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP Fin scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP Null scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP XMAS scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP PSH scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP URG scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP FIN+URG scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP FIN+PSH scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP Maimon scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 TCP ACK scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 UDP scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 SCTP Init scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 SCTP Cookie scan from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 scan for OS detection from the WAN
    step 2. Display the final Nmap report

    step 1. Initiate a Nmap IPv6 scan for OS detection with version detection from the WAN
    step 2. Display the final Nmap report