CDRouter Test Summaries (Full)

    step 1. Send an ARP request to LAN client's default gateway
    step 2. Verify that a valid ARP response is received

    step 1. Send an ARP request for router's WAN IP address
    step 2. Verify that a valid ARP reply is received
    step 3. Verify that the MAC address in the ARP reply matches expected MAC
            address of the DUT's WAN interface

    NOTE: This test is only run if the WAN interface mode supports ARP. This
    test is skipped for wanMode PPPoE.

    NOTE: To configure the expected MAC address of the DUT's WAN interface,
    configure the testvar "wanDutMac". If this testvar is not defined, Step 3
    will be skipped.

    step 1. Start new DHCP client on LAN interface
    step 2. Verify the received DHCP options match the WAN configuration
    step 3. Verify network mask matches configured network mask
    step 4. Verify gateway is router's LAN IP address
    step 5. Verify DNS server is one of the following values:

            a. WAN ISP DNS server, if the testvar DNStoDHCP is set to 'yes'
            b. A user defined DNS server if the testvar lanDnsServer is enabled
               and the testvar DNStoDHCP is set to 'no'
            c. The DUT's LAN IP if the testvar lanDnsServer is disabled and the
              testvar DNStoDHCP is set to 'no'

    step 6. If the WAN is running DHCP, verify domain is WAN ISP domain name

    step 1. Send an ICMP Echo Request from the LAN to the remote host IPv4
    step 2. Verify that an ICMP Echo Request is received on the WAN
    step 3. Verify that the source MAC address in the ICMP Echo Request received
            on the WAN matches the expected MAC address of DUT's WAN interface

    NOTE: To configure the expected MAC address of the DUT's WAN interface,
    configure the testvar "wanDutMac". If this testvar is not defined, this test
    case will be skipped.

    step 1. Reboot the DUT
    step 2. Verify that WAN is fully online
    step 3. Verify that LAN is fully online

    NOTE: To run this test, configure the testvar RestartDut and cpeRebootMode.
    If not defined, this test case will be skipped. Additionally, configure
    startTimeout and RestartDutDelay testvars as needed to accomodate DUT reboot
    time.

    step 1. Confirm connectivity between LAN client and host on WAN
    step 2. Set link DOWN on CDRouter's WAN interface.
    step 3. Confirm lost connectivity between LAN client and host on WAN
    step 4. Set link UP on CDRouter's WAN interface.
    step 5. Confirm connectivity restored between LAN client and host on WAN

    This test brings the link layer of CDRouter's WAN interface DOWN and
    validates loss of connectivity. Then the test brings the link layer back UP
    and validates connectivity is restored.

    step 1. Confirm connectivity between LAN client and host on WAN
    step 2. Set link DOWN on CDRouter's LAN interface.
    step 3. Confirm lost connectivity between LAN client and host on WAN
    step 4. Set link UP on CDRouter's LAN interface.
    step 5. Confirm connectivity restored between LAN client and host on WAN

    This test brings the link layer of CDRouter's LAN interface DOWN and
    validates loss of connectivity. Then the test brings the link layer back UP
    and validates connectivity is restored.

    step 1. Confirm connectivity between LAN client and host on WAN

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

    step 1. Wait for DHCP lease to expire
    step 2. Verify WAN client sends DHCPREQUEST for same IP address
    step 3. Do not respond to request
    step 4. Verify WAN client resends DHCPREQUEST for same IP address
    step 5. Respond to request

        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER

    

        step 1. Configure DHCP server to respond to all DHCP requests with
        DHCPNAK
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Send DHCPNAK to WAN client
        step 5. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        before any other DHCP message
        step 6. Restore DHCP server's original behavior


    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 DHCP server to respond to all DHCP requests with
        DHCPNAK
        step  2. Wait for DHCP lease to expire for WAN DHCP client
        step  3. Send DHCPNAK to WAN client
        step  4. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        step  5. Send DHCPOFFER to WAN client
        step  6. Verify WAN client sends a broadcast DHCPREQUEST
        step  7. Send DHCPNAK to WAN client
        step  8. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        before any other DHCP message
        step  9. Restore DHCP server's original behavior
        step 10. Verify WAN client is assigned an IP address


    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 DHCP server to force client back to DISCOVERY mode
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER
        step 7. Enable DHCP server with site specific options
        step 8. Verify DHCP client is able to obtain new IP address

    

        step 1. Disable DHCP server to force client back to DISCOVERY mode
        step 2. Wait for WAN DHCP client lease to expire
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER
        step 7. Enable DHCP server
        step 8. Add site specific option with length 0
        step 9. Verify client is able to obtain new IP address

    

        step 1. Configure DHCP server to send DHCP packets with corrupt UDP checksum
        step 2. Wait for WAN client DHCP lease to expire
        step 3. Verify WAN client sends DHCPREQUEST
        step 4. Verify server responds with invalid UDP checksum
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Verify WAN client sends a second DHCPDISCOVER
        step 7. Configure DHCP server to send valid UDP checksums
        step 8. Verify WAN client can now obtain an IP address

    

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

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

    

        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST
        step 4. Do not respond to request
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Verify DHCPDISCOVER contains Rapid Commit option


    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. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using client nonce
        step 3. Verify WAN client sends DHCPREQUEST packet


    References:

    IETF RFC 3203 "DHCP reconfigure extension" Section 2.2: Force renew procedures

    https://tools.ietf.org/html/rfc3203#section-2.2

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

        step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using client nonce without
        Authentication option
        step 3. Verify WAN client does not send DHCPREQUEST packet


    References:

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations

    https://tools.ietf.org/html/rfc6704#section-5

        step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using incorrect client nonce
        step 3. Verify WAN client does not send DHCPREQUEST packet

        Reference:

        IETF RFC 6704 Section 3.1.4 "Client Considerations for Forcerenew Nonce Authentication"
        IETF RFC 6704 Section 5 "Security Considerations"


    References:

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations

    https://tools.ietf.org/html/rfc6704#section-5

    step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
            exists
    step 2. Send DHCPFORCERENEW to the client on port 67
    step 3. Verify WAN client does not send DHCPREQUEST packet


    References:

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations

    https://tools.ietf.org/html/rfc6704#section-5

    step 1. Wait for the DHCP lease to expire on the DUT
    step 2. Configure the DHCP server to send a DHCPNACK
    step 3. Wait for the DUT to send a DHCPDISCOVER
    step 4. Send a DHCPOFFER to port 67
    step 5. Verify the DUT doesn't respond with a DHCPREQUEST


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4: Constructing and sending DHCP messages

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

    step 1.  Disable DHCP server
    step 2.  Wait for DHCP lease to expire for WAN DHCP client
    step 3.  Verify WAN client eventually sends DHCPDISCOVER
    step 4.  Record the DHCP Parameter Request List option in DHCPDISCOVER
    step 5.  Enable DHCP server
    step 6.  Verify WAN client sends DHCPREQUEST
    step 7.  Record the DHCP Parameter Request List in DHCPREQUEST
    step 8.  Verify WAN client sends DHCPREQUEST to renew lease
    step 9.  Record the DHCP Parameter Request List in DHCPREQUEST sent during
             renewal
    step 10. Verify DHCP Parameter Request List option contents are consistent
             across DHCP messages (verify that the steps 4, 7, and 9)


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

    If the client included a list of requested parameters in a DHCPDISCOVER
    message, it MUST include that list in all subsequent messages.

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

    step 1. Disable DHCP server
    step 2. Wait for DHCP lease to expire for WAN DHCP client
    step 3. Verify WAN client eventually sends DHCPDISCOVER
    step 4. Record the DHCP ClientID
    step 5. Enable DHCP server
    step 6. Verify WAN client sends DHCPREQUEST
    step 7. Record the DHCP ClientID
    step 8. Verify WAN client sends DHCPREQUEST for renewal
    step 9. Record the DHCP ClientID
    step 10. Verify DHCP ClientID is consistent across DHCP messages


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

    If the client uses a 'client identifier' in one message, it MUST use that
    same identifier in all subsequent messages, to ensure that all servers
    correctly identify the client.

    If the client does not use the DHCP Client ID option 61, the client ID will
    be the src MAC address.

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

    step 1. Disable DHCP server
    step 2. Wait for DHCP lease to expire for WAN DHCP client
    step 3. Verify WAN client sends DHCPREQUEST
    step 4. Do not respond to request
    step 5. Verify WAN client eventually sends DHCPDISCOVER
    step 6. Do not respond to discover
    step 7. Verify WAN client continues to retransmit DHCPDISCOVER
            using a randomized exponential backoff algorithm


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

    DHCP clients are responsible for all message retransmission.  The
    client MUST adopt a retransmission strategy that incorporates a
    randomized exponential backoff algorithm to determine the delay
    between retransmissions.  The delay between retransmissions SHOULD be
    chosen to allow sufficient time for replies from the server to be
    delivered based on the characteristics of the internetwork between
    the client and the server.  For example, in a 10Mb/sec Ethernet
    internetwork, the delay before the first retransmission SHOULD be 4
    seconds randomized by the value of a uniform random number chosen
    from the range -1 to +1.  Clients with clocks that provide resolution
    granularity of less than one second may choose a non-integer
    randomization value.  The delay before the next retransmission SHOULD
    be 8 seconds randomized by the value of a uniform number chosen from
    the range -1 to +1.  The retransmission delay SHOULD be doubled with
    subsequent retransmissions up to a maximum of 64 seconds.  The client
    MAY provide an indication of retransmission attempts to the user as
    an indication of the progress of the configuration process.

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

    step 1. Wait for WAN DHCP client to renew DHCP lease
    step 2. DHCP server sets lease time to 1200 seconds
    step 3. Disable DHCP server
    step 4. Wait for time T1 which is .5 of the lease time
    step 5. Verify WAN client sends unicast DHCPREQUEST at time T1
    step 6. Do not respond to request
    step 7. Wait for 50% of time between T1 & T2
    step 8. Verify WAN client retransmits unicast DHCPREQUEST
    step 9. Repeat steps 7 & 8 until time is less than 60 seconds
    step 10. Wait for time T2 which is 87.5% of lease time
    step 11. Verify WAN client sends broadcast DHCPREQUEST
    step 12. Do not respond to request
    step 13. Wait for 50% of time between T2 and lease expiration
    step 14. Verify WAN client retransmits broadcast DHCPREQUEST
    step 15. Repeat steps 13 & 14 until time is less than 60 seconds
    step 16. Wait for lease to expire
    step 17. Verify WAN client sends DHCPDISCOVER

    NOTE: This test case takes approximately 30 minutes to run succesfully


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.4.5: Reacquisition and expiration

    In both RENEWING and REBINDING states, if the client receives no
    response to its DHCPREQUEST message, the client SHOULD wait one-half
    of the remaining time until T2 (in RENEWING state) and one-half of
    the remaining lease time (in REBINDING state), down to a minimum of
    60 seconds, before retransmitting the DHCPREQUEST message.

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

        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Do not respond to request
        step 7. Configure DHCP server to delay all responses
        step 8. Verify WAN client sends a second DHCPDISCOVER
        step 9. Verify WAN client can now obtain an IP address

        NOTE: The testvar dhcpServerResponseDelay can be used to
        specify the delay used by CDRouter's DHCP server on the WAN
        for this testcase.

    

        step 1.  Disable the DHCP server
        step 2.  Wait for the DUT to send a DHCPREQUEST to renew its lease
        step 3.  Ignore the DUT's requests and allow it to enter the REBINDING state
        step 4.  Verify that the DUT is in the REBIND state by checking that it
                 is broadcasting DHCPREQUESTs
        step 5.  Reconfigure the DHCP server to a new IP address and enable it
        step 6.  Allow the DHCP server to respond with an DHCPACK to the client
        step 7.  Send an ARP request to the client
        step 8.  Verify it was able to renew its original address by responding
                 to the ARP request
        step 9.  If a LAN client is configured ping a remote host from a LAN client
        step 10. Verify that traffic is correctly transmitted and the DUT is using
                 the new gateway
        step 11. Wait for another address renew from the DUT
        step 12. Verify the DUT has learned the new DHCP server address
        step 13. Verify that at no point did the DUT fall back into the INIT
                 state and broadcast DISCOVERY messages

        NOTE: steps 9 and 10 are optional and only performed if there
              is a LAN client configured.

    
    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

    DHCPREQUEST generated during REBINDING state:

    In this situation, the client is completely
    configured, and is trying to extend its lease. This message MUST
    be broadcast to the 0xffffffff IP broadcast address.  The DHCP
    server SHOULD check 'ciaddr' for correctness before replying to
    the DHCPREQUEST.

    The DHCPREQUEST from a REBINDING client is intended to accommodate
    sites that have multiple DHCP servers and a mechanism for
    maintaining consistency among leases managed by multiple servers.
    A DHCP server MAY extend a client's lease only if it has local
    administrative authority to do so.

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

    step 1. Turn off PPP LCP Echo-Reply on PPPoE server
    step 2. PPP client should send an LCP Echo-Request
    step 3. PPP client will not receive an LCP Echo-Reply
    step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
            (wait up to 5 minutes for LCP to failover)
    step 5. Verify PPPoE client brings new PPPoE session up

    NOTE: Most PPPoE clients will terminate the existing PPPoE session after
    several LCP Echo-Requests have failed. However, some routers will
    simply initiate a new PPPoE session without sending a PADT. This
    test case does not FAIL the test if the existing PPPoE session is not
    terminated before starting a new PPPoE session. However, a warning
    will be issued.

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).

    NOTE: By default, CDRouter will still respond to ICMP Echo
    Requests during this test. This allows the test to verify failure
    occurs because of PPP and not the ICMP Echo Replies. However, you
    can configure CDRouter to also ignore ICMP Echo Requests during
    this test by setting the testvar pppFailUsesICMP to yes.

    step 1. Check the current PPPoE session is established
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. Verify PPPoE client brings new PPPoE session up

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).

    step 1. Send 5 LCP Echo-Requests
    step 2. Verify LCP Echo-Replies are received
    step 3. Verify LCP Echo-Request data is echoed back in response

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    NOTE: CDRouter does not fail this test if the PPPoE PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automtically.


    References:

    IETF RFC 1548 "The Point-to-Point Protocol (PPP)" Section 5.8: Echo-Request and Echo-Reply

    https://tools.ietf.org/html/rfc1548#section-5.8

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 3. Verify PPPoE client brings new PPPoE session up
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Send pings from LAN side to WAN side to force link to reestablish
    step 8. Verify PPP link is reestablished in 300 seconds (pppRestartTimeout)

    NOTE: This test supports PAP, CHAP, and MSCHAP authentication.

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).

    step 1. Send LCP Configure-Request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. If the PPPoE link is terminated, issue ping to reestablish link
    step 5. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP can cause some PPP implementations to terminate
    the PPP link or the PPPoE link. This test does not fail the DUT if this
    happens, but it does issue a warning if the PPPoE session is restarted.

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).

    step 1. Send out LCP Echo-Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo-Request
    step 3. Verify PPP is still functioning using ICMP Echo

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo-Request, but it is not considered a failure if
    the device does not respond.

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 3. Do not respond to the PADR packet from client
    step 4. Continue to ignore any PPPoE packets from the client until
            the client sends a new PADI packet
    step 5. Restore PPPoE server to normal operation
    step 6. Verify PPPoE client session recovers

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section 8: Other Considerations

    If the Host is waiting to receive a PADS packet, a similar timeout
    mechanism SHOULD be used, with the Host re-sending the PADR.  After
    a specified number of retries, the Host SHOULD then resend a PADI
    packet.

    https://tools.ietf.org/html/rfc2516#section-8

    step 1. Configure PPPoE server to use AC-Cookie Tag in PADO responses
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. Send AC-Cookie Tag in PADO
    step 5. Verify PADR from client contains AC-Cookie with the same cookie data


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: AC-Cookie

    If a Host receives this TAG, it MUST return the TAG
    unmodified in the following PADR.

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

    step 1. Configure PPPoE server to use Relay-Session-Id in PADO responses
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. If the PADI already contains a Relay-Session-Id from an actual
            PPPoE Relay server, configure the PPPoE server to use the same
            tag value
    step 5. Send Relay-Session-Id Tag in PADO
    step 6. Verify PADR from client contains Relay-Session-Id tag with the same cookie data

    NOTE: Normally, CDRouter does not expect a PPPoE relay server to be present
    between the PPPoE client and CDRouter. However, this test does check for
    an existing Relay-Session-Id in the PADI and will use this tag value
    for the test instead of generating a unique value. This allows the test
    to work with an existing PPPoE relay server on the WAN.


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: Relay-Session-Id

    If either the Host or Access Concentrator receives this TAG they
    MUST include it unmodified in any discovery packet they send as a response.

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

    step 1. Ping from LAN to WAN to refresh idle timeout
    step 2. Disable LAN client to prevent LAN to WAN traffic
    step 3. Verify PPPoE client sends PADT packet after a configured
            period of inactivity

    NOTE: The amount of time the test waits to for the PADT packet can
    be configured by adjusting the testvar pppoeIdleTimeout.  This
    variable contains the number of seconds to wait for PPPoE
    connections to timeout when idling. The default is 60 seconds.

    NOTE: This test is skipped if the testvar pppoeConnectOnDemand is
    set to no.

    step 1. Turn off PPP LCP Echo-Reply on PPPoE server
    step 2. PPP client should send an LCP Echo-Request
    step 3. PPP client will not receive an LCP Echo-Reply
    step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
            (wait up to 5 minutes for LCP to failover)
    step 5. Verify the PADI contains a PPP-Max-Payload tag whose value
            matches that of the testvar pppoeMaxPayload.
    step 6. Verify PPPoE client brings new PPPoE session up


    References:

    IETF RFC 4638 "Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)"

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

    step 1. Turn off PPTP Echo Replies on PPTP server
    step 2. Verify WAN PPTP client closes PPTP TCP connection
            (wait up to 5 minutes for PPTP to failover)
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id

    NOTE: By default, CDRouter will still respond to ICMP Echo
    Requests during this test. This allows the test to verify failure
    occures because of PPP and not the ICMP Echo Replies. However, you
    can configure CDRouter to also ignore ICMP Echo Requests during
    this test by setting the testvar pppFailUsesICMP to yes:


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPTP client closes PPTP TCP session
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

    step 1. Initiate TCP close on PPTP control session by sending TCP FIN
    step 2. Verify WAN PPTP client closes PPTP TCP connection
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id

    NOTE: The behavior of the router when the PPTP TCP control session is
    lost is not well defined by RFC 2637. On some implementations, this
    causes the PPTP client to restart its control session. In the worst
    case, the PPTP client should detect a dead connection through PPTP
    Echo Request failires. At this point, the PPTP control session should
    be restarted.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

    step 1. Send TCP RST for PPTP control session
    step 2. Continue to send data from LAN to WAN to initiate new connection
    step 3. Verify PPTP client establishes new PPTP control session
    step 4. Verify PPTP client establishes new PPTP outbound call session
    step 5. Verify LAN side can reach WAN using new PPTP call id

    NOTE: The behavior of the router when the PPTP TCP control session is
    lost is not well defined by RFC 2637. On some implementations, this
    causes the PPTP client to restart its control session. In the worst
    case, the PPTP client should detect a dead connection through PPTP
    Echo Request failires. At this point, the PPTP control session should
    be restarted.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

    step 1. Send PPTP Call-Disconnect-Notify for existing Call ID
    step 2. Continue to send data from LAN to WAN to initiate new call
    step 3. Verify PPTP client establishes new PPTP outbound call
    step 4. Verify LAN side can reach WAN using new PPTP call id

    NOTE: Some implementations may close the PPTP control session if
    the PPTP call is disconnected. This test does not consider this a
    failure as long as a valid PPTP outbound call is reestablished.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

    step 1. Send 5 LCP Echo Requests
    step 2. Verify LCP Echo Replies are received
    step 3. Verify LCP Echo Request data is echoed back in response

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    RFC 1548 The Point-to-Point Protocol
    5.8 Echo-Request and Echo-Reply

    NOTE: CDRouter does not fail this test if the PPTP PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automtically.

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify PPTP client closes current PPTP control session
    step 3. Continue to send data from LAN to WAN
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Verify PPP link is reestablished in 120 seconds

    Note: This test supports PAP and CHAP authentication.

    step 1. Send out LCP Configure-Request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
    the PPP link or the PPTP link. This test does not fail the DUT if this
    happens, but it does issue a warning if the PPTP session is restarted.

    step 1. Send LCP Echo Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo Request
    step 3. Verify PPP is still functioning using ICMP echo

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo Request, but its not considered a failure if
    the device does not respond.

    step 1. Turn off L2TP Hello Replies on L2TP server
    step 2. Halt traffic on the L2TP tunnel
    step 3. Verify the L2TP client sends L2TP Hello Requests to the server
    step 4. Verify WAN L2TP client closes L2TP tunnel
    step 5. Continue to send data from LAN to WAN to initiate new connection
    step 6. Verify L2TP client establishes new L2TP session
    step 7. Verify LAN side can reach WAN using new L2TP session


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN L2TP client closes L2TP TCP session
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify L2TP client establishes new L2TP session
    step 5. Verify LAN side can reach WAN using new L2TP call id


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1.  Send the StopCCN command to close the active L2TP tunnel
    step 2.  Continue to send data from the LAN to WAN to initiate a new tunnel
    step 3.  Verify L2TP client establishes a new L2TP tunnel
    step 4.  Verify LAN side can reach WAN using new L2TP tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Send Call-Disconnect-Notify for the L2TP session
    step 2. Send StopCCN for L2TP tunnel
    step 3. Continue to send data from LAN to WAN to initiate new tunnel
    step 4. Verify L2TP client establishes new L2TP tunnel
    step 5. Verify LAN side can reach WAN using new L2TP tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Stop PPP from passing traffic to the WAN
    step 2. Continue to send data from LAN to WAN
    step 3. Verify L2TP sends HELLO message to L2TP server
    step 4. Respond to HELLO
    step 5. Reestablish PPP traffic from WAN
    step 6. Verify LAN-WAN communication resumes


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Send 5 LCP Echo Requests
    step 2. Verify LCP Echo Replies are received
    step 3. Verify LCP Echo Request data is echoed back in reply


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    RFC 1548 The Point-to-Point Protocol
    5.8 Echo-Request and Echo-Reply

    NOTE: CDRouter does not fail this test if the L2TP PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automatically.

    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify L2TP client closes current L2TP control session
    step 3. Continue to send data from LAN to WAN
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Verify PPP link is reestablished in 120 seconds

    Note: This test supports PAP and CHAP authentication.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Send LCP config request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
    the PPP link or the L2TP link. This test does not fail the DUT if this
    happens, but it does issue a warning if the L2TP session is restarted.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Send LCP Echo Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo Request
    step 3. Verify PPP is still functioning using ICMP Echo Request

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo Request, but its not considered a failure if
    the device does not respond.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Set the new CHAP secret length to a new value (24 37 78 112 255)
    step 3. Verify PPPoE, PPTP, or L2TP client restarts the link
    step 4. Once LCP is up, send a new CHAP Challenge to peer
    step 5. Verify correct CHAP Response is received
    step 6. Repeat for each key length generating a new secret each time


    References:

    IETF RFC 1994 "PPP Challenge Handshake Authentication Protocol (CHAP)"

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

    step 1. Send CHAP Challenge to PPP client
    step 2. Verify CHAP Response is received in 10 seconds
    step 3. Repeat for 30 CHAP Challenges will link remains active


    References:

    IETF RFC 1994 "PPP Challenge Handshake Authentication Protocol (CHAP)"

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

    step 1. Send a DHCPREQUEST for the current IP address
    step 2. Verify DHCP server sends DHCPACK


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include invalid 'Requested IP
            Address' option
    step 3. Restart DHCP client on LAN
    step 4. Wait for DHCPOFFER from DHCP server and send DHCPREQUEST with
            invalid 'Requested IP Address' option configured in step 2
    step 5. Verify DHCP server sends DHCPNAK
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

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

    step 1. Build a list of DHCP address reservations
    step 2. Start new DHCP client on LAN interface using reserved client MAC
    step 3. Verify DHCP client obtains expected reserved IP address
    step 4. Repeat for each DHCP address reservation identified in step 1

    NOTE: Many DHCP server implementations allow addresses within the DHCP pool
    to be reserved for specific clients based on the client's MAC address. This
    test verifies that the DHCP server honors any configured client MAC to IP
    address reservations as defined by the testvars 'dhcpClientReservedIp'
    and 'dhcpClientReservedMac'.

    Example for two reserved addresses:

    testvar dhcpClientReservedIp1   192.168.1.10
    testvar dhcpClientReservedMac1  00:11:22:33:33:44

    testvar dhcpClientReservedIp2   192.168.1.15
    testvar dhcpClientReservedMac2  00:11:22:33:33:55

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Restart DHCP client on LAN
    step 3. Verify DHCP client receives an address from within the configured
            DHCP pool

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Restart DHCP client on LAN
    step 3. Verify DHCP client receives an address with the expected lease time

    Note: The expected DHCP lease time is configured using the testvar
    dhcpClientLeaseTime. This testvar should match the value configured on the
    DUT's DHCP server.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Send DHCPDISCOVER to restart DHCP client on LAN
    step 2. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Configure DHCP client to use Requested IP Address option (DHCP
            option 50) with current IP address as value
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Configure DHCP client to use Requested IP Address option (DHCP
            option 50) with current IP address as value
    step 2. Send DHCPRELEASE to release DHCP client address on LAN
    step 3. Send DHCPDISCOVER to restart DHCP client on LAN using Requested IP
            Address option in DHCPDISCOVER
    step 4. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Create a new host with a unique MAC address on the LAN
    step 2. Configure new host to use Requested IP Address option (DHCP option
            50) with a valid, unallocated address from within the configured LAN
            DHCP pool
    step 3. Start DHCP client on new host
    step 4. Verify DHCP client receives the address included in the Requested
            IP Address option


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Create a new host with a unique MAC address on the LAN
    step 2. Configure new host to use Requested IP Address option (DHCP option
            50) with the IP address of the existing LAN interface
    step 3. Start DHCP client on new host
    step 4. Verify DHCP client does not receive the address included in the
            Requested IP Address option since it has already been allocated


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the expected options

    The testvars lanDhcpClientOptionCode and lanDhcpClientOptionData can
    be used to configure a list of DHCP options that the client should
    receive from the DHCP server.

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to use the Rapid Commit option
    step 3. Restart DHCP client on LAN
    step 4. Wait for DHCPACK from DHCP server
    step 5. Verify DHCP server sends DHCPACK including Rapid Commit option
    step 6. Verify DHCP client receives a valid address
    step 7. Restore original behavior
    step 8. Restart DHCP client on LAN and verify that client receives a
            valid 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. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to LAN DHCP server using port 68
    step 3. Verify DHCP server ignores the DHCPDISCOVER.
    step 4. Restart DHCP client on LAN allowing the client to obtain an address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to not use minimum size DHCP packets
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: RFC 2131 allows clients to send DHCP packets that are not padded
    out to a minimum length. Older servers based on RFC 1541 may require
    a minimum IP length of 576 for DHCP packets. This test verifies that the
    DHCP server will interoperate with newer clients based on RFC 2131.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

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

    step 1. Create a new DHCP client on LAN
    step 2. Verify new client obtains a valid IP address
    step 3. Attempt to renew the new client's lease using the IP address of
            another client in 'Client IP Address' option
    step 4. Verify DHCP server sends DHCPNAK
    step 5. Remove DHCP client created in step 1 from LAN


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include site specific options
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include a 0 length option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to send corrupted UDP checksums
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client does not receive a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    step 1. Create a new DHCP client on LAN
    step 2. Configure new client with the same hostname as the primary LAN client
    step 3. Verify new client obtains a valid IP address
    step 4. Remove DHCP client created in step 1 from LAN

    Note: This test checks that two DHCP clients configured with the same
    hostname can still receive a DHCP address. The hostname is set using
    DHCP Option 12.

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to set the broadcast bit in
            its DHCPDISCOVER message
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

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

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

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

    step 1. Create a new DHCP client on LAN
    step 2. Watch all ARP and ICMP Echo requests from the router's LAN interface
    step 3. Verify DHCP client receives a valid address
    step 4. Verify router and/or DHCP server sends ARP or ICMP Echo request
            for DHCP client's address before assigning it
    step 5. Remove DHCP client created in step 1 from LAN

    NOTE: Each DHCP server may use a different technique to probe
    an IPv4 address before assigning it to a client. For example,
    send an ARP Request, ICMP ping, etc. This test verifies that
    the router attempts to resolve an ARP Request for the IPv4
    address or send an ICMP Echo Request before the address is
    assigned to a DHCP client.

    NOTE: In most cases the default router and DHCP server will be the same
    IPv4 address. However, this test allows them to be different.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-Server Interaction

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request WINS server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the WINS
            server option
    step 5. Verify WINS server address(es) provided by the DHCP server match
            the expected value(s)
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request NTP server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the NTP
            server option
    step 5. Verify NTP server address(es) provided by the DHCP server match
            the expected value(s)
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: CDRouter automatically announces ntpServer1 and ntpServer2
    via DHCP on the WAN. This test verifies that the NTP server(s)
    received via DHCP on the LAN match the ntpServer1 and ntpServer2
    addresses. If both ntpServer1 and ntpServer2 are configured, this
    test will verify that the LAN client received both addresses. If
    only one NTP server is configured, this test will verify that the
    LAN client received only the expected address. This test is only
    run if the testvar 'dhcpClientRequestNtp' is set to 'yes'.

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request the 'client identifier'
            option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives client identifier option in all
            DHCP response packets from the server
    step 5. Verify client identifier option contains client's MAC address
    step 6. Verify DHCP client receives IP address

    If the 'client identifier' option is present in a message received
    from a client, the server MUST return the 'client identifier' option,
    unaltered, in its response message.


    References:

    IETF RFC 6842 "Client Identifier Option in DHCP Server Replies" Section 3: Modification to RFC 2131

    https://tools.ietf.org/html/rfc6842#section-3

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request DNS server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the DNS
            server option
    step 5. Verify DNS server address(es) provided by the DHCP server match
            the expected value(s)

    NOTE: CDRouter automatically announces wanDnsServer, wanBackupDnsServer, and
    optionally wanBackupDnsServer2 and wanBackupDnsServer3 via DHCP on the WAN.
    If the testvar “DNStoDHCP“ is set to “yes”, CDRouter will verify that its
    LAN DHCP client receives the same DNS servers that have either been learned
    dynamically by the DUT on the WAN or configured manually on the DUT. If the
    testvar “DNStoDHCP” is set to “no”, CDRouter will verify that its LAN DHCP
    client receives the DNS server specified by the testvar “lanDnsServer”
    instead.

    step 1. Send a unicast DHCPINFORM message to the DHCP server
            including DNS Servers (Option 6) and Domain Name (Option 15)
            in the parameter request list
    step 2. Verify DHCP server sends DHCPACK
    step 3. Verify the DHCPACK does not contain a lease time
    step 4. Verify the DHCPACK contains the correct DNS servers (Option 6)
    step 5. Verify the DHCPACK contains the correct domain name (Option 15)
            NOTE: Domain Name is only checked when the wanMode is DHCP
                  and if the testvar lanDomainName is not set to 'none'.
    step 6. Repeat test by sending broadcast DHCPINFOM message

    NOTE: If your DUT does not respond with the Domain Name DHCP option (15),
    then ensure that the testvar lanDomainName is set to the keyword 'none'.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.4: Obtaining parameters with externally configured network address

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request V-I Vendor-Specific
            Information option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: This test verifies that new LAN side CPE devices with TR-111 support
    can still operate behind an IGD device that may not support TR-069. The IGD
    device should ignore the unknown DHCP options if they are not supported.


    References:

    IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request V-I Vendor Class option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: This test verifies that new LAN side CPE devices using Vendor Class
    options to identify themselves can still operate behind an IGD device
    that may not recognize Vendor Class options.


    References:

    IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"

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

    step 1. Send DHCPDISCOVER to restart DHCP client on LAN
    step 2. Verify DHCP client receives an address from within the configured
            DHCP pool
    step 3. Repeat steps 1 and 2 N times, where N is equal to 2 times the DHCP
            pool size

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives an address from within the configured
            DHCP pool
    step 4. Repeat steps 1 through 3 N times, where N is equal to 2 times the
            DHCP pool size

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Initiate an outbound TCP connection to HTTP server
    step 2. Verify the connection is established
    step 3. Send HTTP GET request to server
    step 4. Verify HTTP response is received
    step 5. Verify the IPv4 source address on the WAN side is the router's address
    step 6. Close TCP connection from LAN side


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Initiate an outbound UDP connection (UDP Echo)
    step 2. Verify the udp is received on WAN side
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Initiate an outbound TCP connection
    step 2. Verify the connection is established
    step 3. Send HTTP GET on TCP connection
    step 4. Verify the source address on the WAN side is the router's address
    step 5. Continue creating sessions up to the maximum number supported


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Configure additional LAN host
    step 2. Configure the new LAN host so that its TCP source ports will be the
            same as the original LAN host
    step 3. Initiate outbound TCP connections for both LAN hosts
    step 4. Verify the connections are established
    step 5. Continue to create up to 10 connections per host


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Initiate an outbound TCP connection to HTTP server
    step 2. Verify the connection is established
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Initiate an outbound UDP connection using same source port (UDP Echo)
    step 5. Verify the UDP packet is received on the WAN
    step 6. Send a return UDP packet back to the LAN host
    step 7. Verify return UDP packet is received on the LAN
    step 8. Close TCP connection from LAN side


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Set the next TCP source port to 65535
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the connection is established
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side
    step 8. Repeat using TCP source ports 65534, 0, 1, and 2


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Initiate an outbound TCP connection to TCP server
    step 2. Verify the connection is established and operational
    step 3. Initiate a TCP active close from the WAN side
    step 4. Initiate a TCP passive close from the LAN side
    step 5. Initiate a new outbound TCP connection using the same TCP source port
    step 6. Verify the connection is established and operational

    NOTES: The NAPT implementation should allow new TCP connections to reuse the
    same source port if the TCP connection on the LAN side is closed through
    a passive TCP close operation.

    The amount of time to wait before attempting to resue the Tcp port can
    be configured using testvar 'natTcpPortDelay'. It defaults to 1 second. Setting
    this value too high may defeat the test since the port mapping may be
    deleted before the port is reused.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Initiate an outbound UDP connection
    step 2. Verify the the UDP packet is received on the WAN
    step 3. Verify the source address on the WAN side is the router's address
    step 4. Send return UDP packet back to the LAN
    step 5. Verify the return UDP packet is received on the LAN
    step 6. Continue creating sessions up to the maximum number supported
    step 7. Once all sessions are established, loop through each session
            again and forward a UDP packet from the WAN to the LAN using
            the port mappings that were established for each connection
    step 8. Verify that each UDP connection is still forwarding traffic
            from WAN to LAN.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Configure additional LAN host
    step 2. Configure the new LAN host so that its UDP source ports will be the
            same as the original LAN host
    step 3. Initiate outbound UDP connections for both LAN hosts (UDP Echo)
    step 4. Verify the UDP Echo requests are answered
    step 5. Continue to create up to 10 UDP connections per host


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Forward a packet back from the WAN to the same LAN client
    step 3. Verify packet is received
    step 4. Forward a packet using a different source IP address to LAN
    step 5. Verify the packet is not forwarded onto the LAN or if
            the natType or dsliteFirewallMode is full-cone, verify
            the packet is forwarded to the LAN.

    NOTE: The exact behavior of this test depends on the type of NAT that
    is implemented by the device. The testvar natMode can be used to
    configure either full-cone, address-restricted, or port-restricted NAT.

    NOTE: When DS-Lite is enabled, NAT is not normally applied on the CPE.
    The CPE may still apply a firewall. The mode of the firewall can be
    configured using the dsliteFirewallMode testvar.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Forward a UDP packet from a LAN client to the WAN with
            UDP checksum equal to 0
    step 2. Verify packet is received
    step 3. Verify received UDP checksum on WAN side is 0


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 4.1: IP, TCP, UDP and ICMP Header Manipulations

    https://tools.ietf.org/html/rfc3022#section-4.1

    step 1. Enable LAN client and remote host to include the router alert
            IP option in every IPv4 packet
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the connection is established
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Enable LAN client and remote host to include the router alert
            IP option every IPv4 packet
    step 2. Initiate an outbound UDP connection (UDP Echo)
    step 3. Verify the UDP is received on WAN side
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Send UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN
    step 3. Verify source port on WAN matches the parity of original LAN port
    step 4. Repeat for incremental ports

    If port parity is not supported, this test can be skipped by configuring
    the testvar 'natPortParity' to 'no'. The default is yes.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.2: Port Parity

    https://tools.ietf.org/html/rfc4787#section-4.2.2

    step 1. Send UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send UDP response from WAN to LAN
    step 5. Verify UDP response is received on LAN since NAPT mapping is still working

    NOTE: Receipt of any sort of ICMP message must not destroy the NAT mapping.
    This is REQ-12 from RFC 4787.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 9: ICMP Destination Unreachable Behavior

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

    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMP Destination Unreachable message from the WAN for the connection
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send TCP data segment from WAN to LAN for the session
    step 5. Verify TCP data segment is received on LAN since NAPT mapping is still working


    References:

    IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.3: ICMP Responses to TCP Packets

    REQ-10:  Receipt of any sort of ICMP message MUST NOT terminate the
       NAT mapping or TCP connection for which the ICMP was generated.

    Justification:  This is necessary for reliably performing TCP
       simultaneous-open where a remote NAT may temporarily signal an
       ICMP error.

    https://tools.ietf.org/html/rfc5382#section-7.3

    step 1. Set the TCP MSS size to 1460
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the received MSS on the LAN and WAN matches
            the expected MSS size
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side

    NOTE: The expected MSS size for MSS clamping can be configured
    using the testvar 'mssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar mssClampingInValue.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.

    step 1. Set the TCP options to resemble a Windows TCP client
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the received MSS on the LAN and WAN matches
            the expected MSS size
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side
    step 8. Repeat testing using TCP options for a Linux TCP client
    step 9. Repeat testing using TCP options for a Mac OS X TCP client

    NOTE: The expected MSS size for MSS clamping can be configured
    using the testvar 'mssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar mssClampingInValue.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.

    step 1. Set the TCP MSS size to 512
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the received MSS on the LAN and WAN is stil 512
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side

    NOTE: In order to pass this test, the router's expected MSS Clamping value
    must be greater than 512. When the router detects a MSS value smaller than its
    own MSS clamping value, it should leave the MSS unchanged. The expected MSS
    size for MSS clamping can be configured using the testvar 'mssClampingValue'.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.

    step 1. Initiate an outbound TCP connection to server 1 on the WAN
    step 2. Initiate a second outbound TCP connection to server 2 on the WAN
    step 3. Verify outgoing source port on the WAN side is the same for both connections
    step 4. Close both connections

    RFC 3022 Section 3.1 states that NAT implementations may use the same
    binding for TCP or UDP sessions when the source IP and port are the same.
    This technique is used by peer-to-peer applications to establish a
    connection through NAT. This is also known as Cone NAT.

    NOTE: IETF draft-ford-midcom-p2p-03.txt
    Section 5.1. Deprecate the use of symmetric NATs

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding

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

    IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs

    https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1

    step 1. Initiate an outbound UDP connection to server 1 on the WAN
    step 2. Initiate a second outbound UDP connection to server 2 on the WAN
    step 3. Verify outgoing source port on the WAN side is the same for both connections

    RFC 3022 Section 3.1 states that NAT implementations may use the same
    binding for TCP or UDP sessions when the source IP and port are the same.
    This technique is used by peer-to-peer applications to establish a
    connection through NAT. This is also known as Cone NAT.

    NOTE: IETF draft-ford-midcom-p2p-03.txt
    Section 5.1. Deprecate the use of symmetric NATs

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding

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

    IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs

    https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1

    step 1. Initiate an outbound TCP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound TCP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both TCP connections
    step 4. Send TCP SYN from LAN source port A to public IP and source port for connection 2
    step 5. Send TCP SYN from LAN source port B to public IP and source port for connection 1

    step 6. Send TCP SYN from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.

    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and TCP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the TCP source port is not preserved.

    step 9. Send TCP SYN-ACK from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the TCP SYN packet to work with implementations
            that do not preserve the TCP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and TCP port are translated to public IPv4 and port

    NOTES: This test scenario should work for all Cone NAT implementations - Full
    Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
    of each type of Cone NAT, please see RFC 3489.

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.2: Hairpinning behavior

    https://tools.ietf.org/html/rfc5382#section-7.2

    step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both UDP connections
    step 4. Send UDP from LAN source port A to public IP and source port for connection 2
    step 5. Send UDP from LAN source port B to public IP and source port for connection 1

    step 6. Send UDP from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.

    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the UDP source port is not preserved.

    step 9. Send UDP from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the incoming UDP packet to work with
            implementations that do not preserve the UDP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port

    NOTES: This test scenario should work for all Cone NAT implementations - Full
    Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
    of each type of Cone NAT, please see RFC 3489.

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior

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

    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received
    step 3. Follow the steps below based on the value of the natMode testvar:

    For Full-Cone NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Address-Restricted NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is not forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Port-Restricted NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is not forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    NOTE: Most NAPT routers use either Port-Restricted NAT, Address-Restricted NAT,
    or Full-Cone NAT. By default, CDRouter assumes Port-Restricted NAT, but the type
    of NAPT in use can be configured using the testvar 'natMode'.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    step 1. Configure a LAN client to set the TCP window scale option using value '4'
            and a TCP window size of 65535
    step 2. Configure a WAN server to set the TCP window scale option using value '4'
            and a TCP window size of 65535
    step 3. Initiate a outbound TCP connection from the LAN client to the WAN client
    step 4. Verify both TCP connections received the same TCP window scale option
            with the same scaling factor '4'. The TCP window scale option should
            not be modified. Stop the test here if the window scale option is modified.
    step 5. Send a data block from the LAN to the WAN at the start of the data sequence
    step 6. Move the sequence ahead (65535 * 3) so that it would be outside of the
            current window if TCP window scaling is not being applied
    step 7. Send a new data block from the LAN to the WAN and verify the WAN server
            can echo back the data block.
    step 8. Repeat the Steps 5 and 6 until 5 data blocks have been sent
    step 9. Send a data block from the WAN to the LAN using current data sequence
    step 10. Move the sequence ahead (65535 * 3) so that it would be outside of the
             current window if TCP window scaling is not being applied
    step 11. Send a new data block from the WAN to the LAN and verify the LAN client
             can echo back the data block.
    step 12. Repeat the Steps 9 and 10 until 5 data blocks have been sent
    step 13. Close the TCP connection

    NOTE: If a firewall/NAT device is tracking the sequence number of TCP data, it
    needs to understand the TCP window scale option. This test is designed to find
    issues with devices that are not applying the TCP window scale factor to the
    the TCP window. If a device is not maintaining any TCP sequence number state,
    the TCP connection should not experience any problems.


    References:

    IETF RFC 1323 "TCP Extensions for High Performance"

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

    step 1. Configure a LAN client to enable TCP Fast Open support
    step 2. Configure WAN server to enable TCP Fast Open support
    step 3. Initiate an outbound TCP connection from the LAN client to
            the WAN server.  Client includes a TCP Fast Open cookie
            request option in its initial SYN packet.
    step 4. Verify LAN client received a TCP Fast Open cookie option
            in the SYN+ACK from the WAN server during the normal TCP
            three-way handshake.
    step 5. Verify TCP connection was established successfully.
    step 6. Close the TCP connection

    NOTE: TCP Fast Open does not currently have an officially assigned
    IANA TCP option value.  Therefore, this test uses the experimental
    TCP option value 0xfe and prepends the magic value 0xf989 to each
    cookie in order to distinguish TFO cookie request/TFO cookie
    options from other experimental TCP options.  The fact that these
    are not official IANA values should not be a factor in this
    NAT-style test since CDRouter is acting as both the client and
    server.


    References:

    IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"

    https://tools.ietf.org/html/draft-ietf-tcpm-fastopen

    step 1. Configure a LAN client to enable TCP Fast Open support
    step 2. Configure WAN server to enable TCP Fast Open support
    step 3. Initiate an outbound TCP connection from the LAN client to
            the WAN server.  Client includes a TCP Fast Open cookie
            request option in its initial SYN packet.
    step 4. Verify LAN client received a TCP Fast Open cookie option
            in the SYN+ACK from the WAN server during the normal TCP
            three-way handshake.
    step 5. Verify TCP connection was established successfully.
    step 6. Close the TCP connection
    step 7. Initiate an outbound TCP connection from the LAN client to
            the WAN server, client includes data along with the TCP
            Fast Open cookie from step 4 in its SYN packet.
    step 8. WAN server sends its response data in an extra ACK between
            the server's SYN+ACK and the client's ACK during the
            normal TCP three-way handshake.
    step 9. Verify TCP connection was established successfully
    step 10. Verify LAN client received expected server data
    step 11. Verify WAN server received expected client data
    step 12. Close the TCP connection

    NOTE: TCP Fast Open does not currently have an officially assigned
    IANA TCP option value.  Therefore, this test uses the experimental
    TCP option value 0xfe and prepends the magic value 0xf989 to each
    cookie in order to distinguish TFO cookie request/TFO cookie
    options from other experimental TCP options.  The fact that these
    are not official IANA values should not be a factor in this
    NAT-style test since CDRouter is acting as both the client and
    server.


    References:

    IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"

    https://tools.ietf.org/html/draft-ietf-tcpm-fastopen

    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Close the TCP connection using FIN from WAN
    step 4. Wait for natFinTimeout to expire
    step 5. Retransmit the last TCP segment from the WAN to LAN
    step 6. Verify TCP packet from the WAN is not forwarded to LAN
    step 7. Initiate a second outbound TCP connection to same TCP port
    step 8. Verify the connection is established
    step 9. Close the TCP connection using FIN from WAN
    step 10. Wait for natFinTimeout - 5 seconds
    step 11. Retransmit the last TCP segment from the WAN to LAN
    step 12. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    TCP connection that has been closed for 'natFinTimeout' seconds. The
    natFinTimeout setting is configured in the configuration file
    using the testvar natFinTimeout.

    NOTE: There are two mains types of implementations of the natFinTimeout
    timer. Some implementations delete the NAT entry after a FIN event
    occurs and the natFinTimeout occurs. Other implementations reset the
    timeout each time a packet is seen. This test case uses 2 TCP sessions
    to verify the behavior since sending TCP data to verify the timeout can
    cause some implementations to reset the timeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Close the TCP connection using RST from LAN
    step 4. Wait for natRstTimeout to expire
    step 5. Retransmit the last TCP segment from the WAN to LAN
    step 6. Verify TCP packet from the WAN is not forwarded to LAN
    step 7. Initiate a second outbound TCP connection to same TCP port
    step 8. Verify the connection is established
    step 9. Close the TCP connection using RST from LAN
    step 10. Wait for natRstTimeout - 5 seconds
    step 11. Retransmit the last TCP segment from the WAN to LAN
    step 12. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    TCP connection that has been closed for 'natRstTimeout' seconds. The
    natRstTimeout setting is configured in the configuration file
    using the testvar natRstTimeout.

    NOTE: There are two mains types of implementations of the natRstTimeout
    timer. Some implementations delete the NAT entry after an RST event
    occurs and the natRstTimeout occurs. Other implementations reset the
    timeout each time a packet is seen. This test case uses 2 TCP sessions
    to verify the behavior since sending TCP data to verify the timeout can
    cause some implementations to reset the timeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Wait for natTcpTimeout to expire
    step 4. Retransmit the last TCP segment from the WAN to LAN
    step 5. Verify TCP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound TCP connection to same TCP port
    step 7. Verify the connection is established
    step 8. Wait for natTcpTimeout - 5 seconds
    step 9. Retransmit the last TCP segment from the WAN to LAN
    step 10. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router deletes the NAT entry
    for a TCP session that has been inactive for 'natTcpTimeout'
    seconds. The natTcpTimeout can be configured using the testvar
    natTcpTimeout.

    NOTE: The default natTcpTimeout on most NAT devices can be quite long.
    Some devices default to 24 hours (86400). This test can be quite
    time consuming with long timeout values.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Send outbound TCP SYN to next TCP port
    step 2. Wait for natSynTimeout to expire
    step 3. Send TCP SYN-ACK from WAN back to LAN host
    step 4. Verify TCP packet from the WAN is not forwarded to LAN
    step 5. Send a second outbound TCP SYN to same TCP port
    step 6. Wait for natSynTimeout - 5 seconds
    step 7. Send TCP SYN-ACK from WAN back to LAN host
    step 8. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    partially open TCP connection for 'natSynTimeout' seconds. The
    natSynTimeout setting is configured in the configuration file
    using the testvar natSynTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound UDP Echo
    step 2. Verify the UDP packet is received on the WAN
    step 3. Wait for natUdpTimeout seconds
    step 4. Transmit the UDP response from the WAN to LAN
    step 5. Verify UDP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound UDP Echo
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natUdpTimeout - 5 seconds
    step 9. Transmit the UDP response from the WAN to LAN
    step 10. Verify UDP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    UDP connections for 'natUdpTimeout' seconds. The natUdpTimeout
    setting is configured in the configuration file using the testvar
    natUdpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound DNS query
    step 2. Verify the DNS packet is received on the WAN
    step 3. Wait for natDnsTimeout seconds
    step 4. Transmit the DNS response from the WAN to LAN
    step 5. Verify DNS packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound DNS query
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natDnsTimeout - 5 seconds
    step 9. Transmit the DNS response from the WAN to LAN
    step 10. Verify DNS packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for
    a DNS connection for 'natDnsTimeout' seconds. The natDnsTimeout
    setting is configured in the configuration file using the testvar
    natDnsTimeout. If the implementation does not make any
    distintiction between DNS and generic UDP, this timeout should be
    set to the same value as the natUdpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound ICMP Echo Request
    step 2. Verify the packet is received on the WAN
    step 3. Wait for natIcmpTimeout seconds
    step 4. Transmit the Echo Reply from the WAN to LAN
    step 5. Verify ICMP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound ICMP Echo Request
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natIcmpTimeout - 5 seconds
    step 9. Transmit the Echo Reply from the WAN to LAN
    step 10. Verify ICMP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    ICMP connections for 'natIcmpTimeout' seconds. The
    natIcmpTimeout setting is configured in the configuration file
    using the testvar natIcmpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

    step 1. Initiate an outbound RTSP connection
    step 2. Verify the connection is established
    step 3. Wait for natRtspTimeout to expire
    step 4. Verify RTP and RTCP packets from the WAN are not forwarded to LAN
    step 5. Initiate a second outbound RTSP connection
    step 6. Verify the connection is established
    step 7. Wait for natRtspTimeout - 5 seconds
    step 8. Verify RTP and RTCP packets from the WAN are forwarded to LAN

    NOTE: This test verifies that the router deletes the RTSP entry
    for a RTSP session that has been inactive for 'natRtspTimeout'
    seconds. The natRtspTimeout can be configured using the testvar
    natRtspTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.

    step 1. Initiate an outbound TCP connection
    step 2. Set outgoing MTU to 108 bytes to force fragmentation
    step 3. Send a fragmented TCP data segment
    step 4. Verify the TCP data is received on WAN side
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN
    step 7. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

    step 1. Initiate an outbound TCP connection
    step 2. Set outgoing MTU to 108 bytes to force fragmentation
    step 3. Send a fragmented TCP data segment with fragments in reverse order
    step 4. Verify the TCP data is received on WAN side
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN
    step 7. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

    step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
    step 2. Verify the udp is received on WAN side
    step 3. Send a return response back to LAN
    step 4. Verify return packet is received on the LAN
    step 5. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

    step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
    step 2. Send fragments in reverse order
    step 3. Verify the udp is received on WAN side
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN
    step 6. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

    step 1. Initiate an outbound ICMP request with large fragmented packet
    step 2. Verify the udp is received on WAN side
    step 3. Send a return response back to LAN
    step 4. Verify return packet is received on the LAN
    step 5. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

    step 1. Initiate an outbound ICMP request with large fragmented packet
    step 2. Send fragments in reverse order
    step 3. Verify the ICMP is received on WAN side
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN
    step 6. Repeat for multiple packet sizes


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

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

    IETF RFC 8900 "IP Fragmentation Considered Fragile" Section 3.3: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation
    (NAT) devices.  When a NAT device detects a new, outbound flow, it
    maps that flow's source port and IP address to another source port
    and IP address.  Having created that mapping, the NAT device
    translates:

    *  The source IP address and source port on each outbound packet.

    *  The destination IP address and destination port on each inbound
       packet.

    A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
    NAT strategies.  In both approaches, the NAT device must virtually
    reassemble fragmented packets in order to translate and forward each
    fragment.

    https://tools.ietf.org/html/rfc8900#section-3.3

     step 1.  Change the wanIspAssignIp address to a new address
     step 2.  Wait for DHCP lease to expire on WAN interface
     step 3.  Verify WAN client sends DHCPREQUEST for same IP address
     step 4.  Send DHCPNAK for that address
     step 5.  Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
     step 6.  Verify new address responds to ping from LAN
     step 7.  Verify the old address no longer responds to ping from LAN
     step 8.  Verify new address responds to ARP request from WAN
     step 9.  Verify LAN client can ping remote host using new address
     step 10. Restore original IP address
     step 11. Verify LAN client can ping remote host

     NOTE: Step 8 will be skipped if testvar IPv4HopCount > 1 or testvar
     wanIspAssignGateway is defined as this indicates that the WAN client and
     WAN server are not on the same subnet.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Wait for DHCP lease to expire on WAN interface
    step 4. Verify WAN client sends DHCPREQUEST for same IP address
    step 5. Send DHCPNAK for that address
    step 6. Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
    step 7. Verify new address responds to ping from LAN
    step 8. Verify the old address no longer responds to ping from LAN
    step 9. Initiate same TCP connection from LAN to WAN
    step 10. Verify TCP connection works
    step 11. Reset wanIspAssignIp to its original value and wait for a DHCP renew
    step 12. Verify the remoteHost responds to ping from the LAN


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Change the DNS server address
    step 2. Wait for WAN client to renew lease and learn new DNS Server
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new DNS server address
    step 5. Reset the WAN client's DNS server address
    step 6. Verify the LAN client can ping a remote host


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Change the DNS domain name to a longer domain name
    step 2. Wait for WAN client to renew lease and learn new domain name
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new domain name
    step 5. Reset the WAN client's DNS domain name
    step 6. Verify the LAN client can ping a remote host
    
    This test checks that the router correctly handles changes to the domain
    when it is modified. QACafe has seen cases where domain names passed on to
    DHCP clients were corrupted when changed after the WAN side renewed its DHCP
    lease.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Change the DNS domain name to a shorter name
    step 2. Wait for WAN client to renew lease and learn new domain name
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new domain name
    step 5. Reset the WAN client's DNS domain name
    step 6. Verify the LAN client can ping a remote host

    This test checks that the router correctly handles changes to the domain
    when it is modified. QACafe has seen cases where domain names passed on to
    DHCP clients were corrupted when changed after the WAN side renewed its DHCP
    lease.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Change the default gateway that the DHCP server will assign
            to a new IPv4 address based on testvar wanIspNextIp
    step 2. Wait for DHCP lease to expire on WAN interface
    step 3. Verify WAN client sends DHCPREQUEST for same IP address
    step 4. Send DHCPACK that contains the new IP gateway
    step 5. Wait 5 seconds for CPE to update the default gateway
    step 6. Initiate TCP connection from LAN to WAN
    step 7. Verify TCP connection works using the new gateway
    step 8. Reset the WAN client's default gateway
    step 9. Verify the LAN client can ping a remote host

    NOTE: By default, this test case will wait 5 seconds after the DHCP client
    has updated before checking that the new gateway is working. This time
    interval can be adjusted using the testvar dhcpGatewayCache.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

    step 1. Add two more DNS servers to WAN side DHCP server
    step 2. Wait for WAN client to renew lease and learn new DNS servers
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives two new DNS servers

    NOTE: The router under test must support at least three DNS servers in order
    to pass this test. Some routers will only include one or two DNS servers in
    the DHCP DNS option offered to DHCP clients.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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