CDRouter Multiport Test Summaries (Full)

    step 1. Open a TCP connection from the LAN client to the WAN ISP
            IP address of the first WAN link
    step 2. Verify the TCP connection is established
    step 3. Verify the source IP address is the assigned WAN address
            for this WAN interface
    step 4. Repeat for all WAN interfaces

    NOTE: By default, this test opens a TCP connection to port 50000. The
    port number can be modified by configuring the testvar 'defaultTcpEchoPort'.

    Example:

    testvar defaultTcpEchoPort 50000


    References:

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

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

    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IP on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Verify the source IP address is the assigned WAN address
            for this WAN interface
    step 4. Repeat for all WAN interfaces

    NOTE: By default, this test opens a UDP connection to port 50000. The
    port number can be modified by configuring the testvar 'defaultUdpEchoPort'.

    Example:

    testvar defaultUdpEchoPort 50000


    References:

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

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

    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound TCP connection to HTTP server on the
            remoteHost
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Verify HTTP traffic succeeds (return TCP traffic will use different WAN port)
    step 5. Close TCP connection from LAN side
    step 6. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.


    References:

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

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

    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound UDP connection
    step 3. Verify the UDP packet 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 using different WAN port
    step 6. Verify return packet is received on the LAN
    step 7. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.

    NOTE: The UDP port used for this test can be configured using:

    Example:

    testvar defaultUdpEchoPort 50000

    It defaults to UDP port 50000.


    References:

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

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

    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound ICMP Echo Request
    step 3. Verify the ICMP Echo Request is received on WAN side
    step 4. Send an ICMP Echo Reply back to LAN using different WAN port
    step 5. Verify ICMP Echo Reply is received on the LAN
    step 6. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.


    References:

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

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

    step 1. Listen for RIP reply on each WAN interface
    step 2. Verify RIP version
    step 3. Verify source address of RIP reply

    NOTE: This test is only run if the 'ripSupported' configuration is
    set to 'yes'. The RIP version used for the test can be configured
    using the 'ripVersion' testvar in your configuration file.


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 route with metric 5 from all WAN
            interfaces except the last WAN interface
    step 2. Announce the same RIPv1/v2 route with a metric of 2 from
            the last wan interface
    step 3. Forward UDP packet from LAN client to IP address within the
            new RIPv1/v2 route range
    step 4. Verify the packet is forwarded to WAN interface with the
            lowest metric


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Listen for RIP updates for 1 minute
    step 2. Verify RIP route for LAN network is not announced as reachable


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 route with metric 12 from the first WAN
            interface
    step 2. Verify traffic is forwarded from LAN to WAN correctly
    step 3. Announce the same RIPv1/v2 route with a metric of 2 from
            the next WAN interface
    step 4. Verify traffic is forwarded from LAN to WAN correctly using
            the new WAN interface
    step 5. Repeat for each WAN interface using a new RIPv1/v2 route


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Wait for RIP update on first WAN interface
    step 2. Announce new RIPv1/v2 route with metric 1 from first WAN interface
    step 3. Verify triggered RIP update is sent to additional WAN interfaces
    step 4. Verify metric for triggered update route is the original metric + 1
    step 5. Verify the packet is forwarded from LAN to correct WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 route with metric 1 from second WAN interface
    step 2. Originate UDP packet from first WAN interface with destination
            inside new RIP route
    step 3. Verify the packet is forwarded from first WAN interface to
            second WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Send RIP Request from new UDP source port to RIP destination address
    step 2. Verify router returns a RIP response
    step 3. Verify the response is sent to the correct UDP port
    step 4. Verify the response is sent using unicast IP destination
    step 5. Repeat for each WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 route with metric 1 from first
            WAN interface
    step 2. Wait for RIP route timer to expire
    step 3. Verify RIP route is announced on other WAN interfaces with
            a metric of 16
    step 4. Wait for the RIP garbage collection timer to expire
    step 5. Verify the RIP route is no longer announced on other WAN
            interfaces


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 route with metric 1 from first WAN interface
    step 2. Terminate PPP link using PPP LCP Terminate (PPPoE or PPTP)
    step 3. Wait up to 15 seconds for triggered update on second WAN interface
    step 4. Verify the route is announced with metric 16 on second WAN interface

    NOTE: This test is only supported if the first WAN interface uses PPP
    to connect. This includes PPPoE and PPTP.


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Terminate PPP link using PPP LCP Terminate (PPPoE or PPTP)
    step 2. Wait up to 90 seconds for router to send RIP request to learn
            initial routing table

    NOTE: This test is only supported if the first WAN interface uses PPP
    to connect. This includes PPPoE and PPTP.


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Announce new RIPv1/v2 routes with metric 1 from each WAN interface

            NOTE: The 'ripMaxRoutes' testvar in your configuration file
            determines the number of RIPv1/v2 routes that are announced. This
            number is divided by the number of WAN interfaces to determine
            how many RIPv1/2 routes to announce on each WAN interface.

    step 2. Forward from original LAN client to IP address within the
            each new route range
    step 3. Verify packets are forwarded to correct WAN interface
    step 4. Repeat for each RIP route that was announced


    References:

    IETF RFC 2453 "RIP Version 2"

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

    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Close the TCP connection
    step 5. Configure the used WAN link to drop all incoming packets
    step 6. Continue to initiate a new TCP connection to the remoteHost
    step 7. Wait for connection to establish or wanFailoverTimeout to expire

    step 1. Configure all WAN links to drop incoming packets
    step 2. Wait for wanFailoverTimeout to expire
    step 3. Enable all WAN links
    step 4. Initiate an outbound TCP connection to remoteHost port 6000
    step 5. Verify the TCP connection succeeds

    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Close the TCP connection
    step 5. Disable the DHCP server on the WAN
    step 6. Wait for the DHCP lease to expire on the LAN
    step 7. Continue to initiate a new TCP connection to the remoteHost
    step 8. Wait for connection to establish on other WAN interface
            or wanFailoverTimeout to expire

    NOTE: This test verifies that the router fails over to a second WAN interface
    when the DHCP lease cannot be renewed.

    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Configure the used WAN link to drop all incoming packets
    step 5. Continue to initiate a new TCP connection to the remoteHost
            until the link fails over
    step 6. Wait for connection to establish or wanFailoverTimeout to expire
    step 7. Verify that the original TCP connection can still pass data (or)
            verify that the original TCP connection is reset by the remoteHost

    NOTE: The behavior of existing TCP connections when a WAN interface fails
    is dependent on the type of NAT in use. Typically, when a TCP session fails
    from one WAN interface to another, the TCP packets sent out the second
    WAN interface use a different NAPT source address. In these cases, the
    remote end of the TCP connection will detect an invalid TCP session state
    with the new IP address and Reset the connection. It is also possible to
    configure some devices to use the same NAPT IP address on all WAN links.

    step 1. Initiate a DNS query to the router's LAN IP address
    step 2. Verify the query is received by real DNS server on the WAN side
    step 3. Send a return response back to LAN
    step 4. Verify the response is received by LAN client
    step 5. Disable the outbound WAN interface
    step 6. Continue to send a DNS query to the router's LAN IP address
    step 7. Wait for DNS query response or wanFailoverTimeout to expire

    NOTE: In order to pass this test, the router must relay all DNS requests
    sent to its LAN IP address onto the current DNS server for one of the
    WAN interfaces. If multiple WAN links are connected to multiple ISPs,
    each ISP will assign a DNS server for use on the WAN connection.

    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IP on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Send UDP packet from LAN to next WAN interface
    step 4. Repeat for all WAN interfaces
    step 5. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar 'lanMtu'.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

    step 1. Initiate an outbound UDP connection to each WAN IP address to
            establish an initial NAT port mapping
    step 2. Send an inbound UDP packet with UDP data length 0 from WAN host
            on first WAN port to router's public IP address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Send UDP packet from next WAN interface to LAN
    step 5. Repeat for all WAN interfaces
    step 6. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar lanMtu.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

    step 1. Send an outbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from LAN host to ISP IP on first WAN
            port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 4. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

    step 1. Initiate an outbound UDP connection to first WAN IP address to
            establish an initial NAT port mapping that utilizes the maximum
            supported standard mtu of both interfaces
    step 2. Send an inbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from WAN host on first WAN port to
            router's public IP address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 5. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

    step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
            GRE network to a host on the LAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet from a host on the LAN to a host within the
            remote GRE network on the WAN
    step 2. Verify that the IPv4 over GRE packet is received on the WAN
    step 3. Verify the following GRE header fields within the received packet:

            Checksum Present (bit 0):      May be 0 or 1
            Reserved0 (bits 1-12):         Must be set to 0
            Version Number (bits 13-15):   Must be set to 0


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)" Section 2.1: GRE Header

    https://tools.ietf.org/html/rfc2784#section-2.1

    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation
    step 2. Verify that the packet and any fragments are received on the WAN
    step 3. Reassemble the packet and verify the original contents
    step 4. Repeat steps 1 through 3 with IPv4 packets that range in size from
            1490 bytes to 1500 bytes (these packets have a UDP payload size of
            1462 to 1472 bytes)


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation with DF=1
    step 2. Verify that the DUT sends an ICMPv4 Destination Unreachable
    step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'


    References:

    IETF RFC 1191 "Path MTU Discovery" Section 2: Protocol overview

    In this memo, we describe a technique for using the Don't Fragment
    (DF) bit in the IP header to dynamically discover the PMTU of a path.
    The basic idea is that a source host initially assumes that the PMTU
    of a path is the (known) MTU of its first hop, and sends all
    datagrams on that path with the DF bit set.  If any of the datagrams
    are too large to be forwarded without fragmentation by some router
    along the path, that router will discard them and return ICMP
    Destination Unreachable messages with a code meaning "fragmentation
    needed and DF set" [7].  Upon receipt of such a message (henceforth
    called a "Datagram Too Big" message), the source host reduces its
    assumed PMTU for the path.

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

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that does not require fragmentation; send the packet as
            two IPv4 fragments
    step 2. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the GRE host on the WAN


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 1470 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            as two IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            1470 to 1480


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 7997 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            using multiple IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            7997 to 8000


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP Echo packet from the LAN to a remote GRE host on
            the WAN
    step 2. Send an IPv4 UDP Echo response packet from the remote GRE host on
            the WAN to the LAN host; fragment the packet and send the fragments
            in reverse order
    step 3. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send an IPv4 UDP packet to a remote GRE host on the WAN with the DF
            flag set to 0
    step 2. Verify packet is received by remote GRE host on the WAN
    step 3. Verify the DF flag in the GRE header based on the testvar greDFflag:

            When payload DF=0:

                "inherit" - the DF flag should be 0
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

            When payload DF=1

                "inherit" - the DF flag should be 1
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

    step 4. Repeat steps 1 through 3 for DF flag set to 1


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    IETF RFC 7588 "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem" Section 3.3.2.1: Tunneling GRE over IPv4

    By default, the GRE ingress node does not fragment delivery packets.
    However, the GRE ingress node includes a configuration option that
    allows delivery packet fragmentation.

    By default, the GRE ingress node sets the DF bit in the delivery
    header to 1 (Don't Fragment).  However, the GRE ingress node also
    supports a configuration option that invokes the following behavior:

    o  When the GRE payload is IPv6, the DF bit on the delivery header is
      set to 0 (Fragments Allowed).

    o  When the GRE payload is IPv4, the DF bit is copied from the
       payload header to the delivery header.

    When the DF bit on an IPv4 delivery header is set to 0, the GRE
    delivery packet can be fragmented by any router between the GRE
    ingress and egress nodes.

    https://tools.ietf.org/html/rfc7588#section-3.3.2.1

    step 1. Initiate an outbound ICMPv4 Echo Request from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Send an invalid ICMPv4 Echo Reply packet with a shortened GRE header
    step 3. Verify that the ICMPv4 Echo Reply packet is not forwarded to the LAN
    step 4. Repeat


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
            remoteVpn host over the L2GRE tunnel
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process two more times until an ICMP Destination
            Unreachable is received, or all 3 packets are sent
    step 4. If an ICMP Destination Unreachable was sent, verify the
            the code value is 4 and verify MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMP Destination Unreachable is sent
    step 6. When a packet size is found that does not generate an
            ICMP Destination Unreachable, verify packets can be forwarded over
            L2GRE tunnel using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMP Destination Unreachable packet

    NOTE: Some devices rate limit the number of ICMP packets that may be
          sent. This test will sent 3 UDP packets over a 15 second window
          in order to generate an ICMP unreachable packet. If your device
          uses rate limiting on ICMP packets, it must allow at least 1
          ICMP packet every 10 seconds.


    References:

    IETF RFC 1191 "Path MTU Discovery"

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

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    step 1. Initiate ARP broadcast request from first LAN interface to next LAN
    step 2. Repeat ARP request for each LAN interface
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify ARP broadcast succeeds for each LAN to LAN combination

    step 1. Initiate IGMP Join request from first LAN interface
    step 2. Attempt to forward layer 2 multicast from second LAN interface to first
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify IGMP multicast succeeds for each LAN to LAN combination

    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Verify ICMP Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination

    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Send ICMP Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMP Echo Reply is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.

    step 1. Initiate HTTP Get from first LAN interface to next LAN
    step 2. Send HTTP Get using the destination MAC address of router's LAN interface
    step 3. Verify HTTP Response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.

    step 1. Initiate UDP Echo from first LAN interface to next LAN
    step 2. Send UDP Echo request using the destination MAC address of router's LAN interface
    step 3. Verify UDP Echo response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.

    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Send ICMP Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMP Echo Reply is received by second host
    step 4. Verify IPv4 TTL is decremented by 1
    step 5. Move to the second LAN interface and repeat
    step 6. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.

    Test Procedure:

    Step 1. For all LAN clients, send an IGMP join to the DUT to subscribe to
            multicast messages on a group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send an IGMP leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.

    Test Procedure:

    Step 1. For all LAN clients, send an IGMP join to the DUT to subscribe to
            multicast messages on a group within the multicast pool.
    Step 2. Send a multicast message to the group from a host on the WAN.
    Step 3. Send an IGMP leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.

    step 1. Loop through all static NAT hosts with public IP on the same network as the WAN
    step 2. Send ARP Request for static NAT public IP
    step 3. Verify valid ARP Reply is returned

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


    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 on WAN
    step 2. Verify the connection is established
    step 3. Compare the src port on the LAN and WAN sides of the connection
    step 4. Verify the TCP src port does not change when going through static NAT
    step 5. 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 to UDP server on WAN
    step 2. Verify the UDP packet is received on the WAN
    step 3. Compare the src port on the LAN and WAN sides of the connection
    step 4. Verify the UDP src port does not change when going through static NAT


    References:

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

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

    step 1. Verify the client on Guest LAN can ping a remote host.

    step 2. Verify the client on Guest LAN can establish a TCP connection
            with a remote host.

    step 3. Verify that the client on the Guest LAN cannot ping the client
            on the Main LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that a ICMP Echo sent by the client on
               the Guest LAN is not received by the client on the Main LAN.

    step 4. Verify that the client on the Main LAN cannot ping the client
            on the Guest LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that a ICMP Echo sent by the client on
               the Main LAN is not received by the client on the Guest LAN.

    step 5. Verify that the client on the Guest LAN cannot establish a TCP
            session with the client on the Main LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that the client on the Guest LAN cannot
               establish a TCP session with the client on the Main LAN.

    step 6. Verify that the client on the Main LAN cannot establish a TCP
            session with the client on the Guest LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that the client on the Main LAN cannot
               establish a TCP session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a broadcast ARP request from the client on the Main LAN
            looking for the MAC Address of the client on the Guest LAN.

    step 2. Verify that the ARP request is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a broadcast ARP request from the client on the Guest LAN
            looking for the MAC Address of the client on the Main LAN.

    step 2. Verify that the ARP request is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Add static ARP entry for client on Guest LAN into ARP table of
            client on the Main LAN.

    step 2. Add static ARP entry for client on Main LAN into ARP table of
            client on the Guest LAN.

    step 3. Send a unicast frame from the client on the Main LAN to the IP
            address of the client on the Guest LAN.

    step 4. Verify that the unicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Add static ARP entry for client on Guest LAN into ARP table of
            client on the Main LAN.

    step 2. Add static ARP entry for client on Main LAN into ARP table of
            client on the Guest LAN.

    step 3. Send a unicast frame from the client on the Guest LAN to the IP
            address of the client on the Main LAN.

    step 4. Verify that the unicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a broadcast frame from the client on the Main LAN.

    step 2. Verify that the broadcast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a broadcast frame from the client on the Guest LAN.

    step 2. Verify that the broadcast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a multicast frame from the client on the Main LAN.

    step 2. Verify that the multicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Send a multicast frame from the client on the Guest LAN.

    step 2. Verify that the multicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Add static ARP entry of the LAN gateway's MAC to represent the
            client on Guest LAN into ARP table of client on the Main LAN.

    step 2. Add static ARP entry of the LAN gateway's MAC to represent the
            client on Main LAN into ARP table of client on the Guest LAN.

    step 3. Verify the client on Guest LAN can ping a remote host.

    step 4. Verify the client on Guest LAN can establish a TCP connection
            with a remote host.

    step 5. Verify that the client on the Guest LAN cannot ping the client
            on the Main LAN.

    step 6. Verify that the client on the Main LAN cannot ping the client
            on the Guest LAN.

    step 7. Verify that the client on the Guest LAN cannot establish a TCP
            session with the client on the Main LAN.

    step 8. Verify that the client on the Main LAN cannot establish a TCP
            session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.

    step 1. Initiate a Nmap IPv4 scan for OS detection with version
            detection from the LAN using the first port in
            dutMgmtPort.

    step 2. Display the Nmap report.

    step 3. Repeat steps 1 and 2 for each port in dutMgmtPort.

    NOTE: The list of the DUT's management ports is taken from the
          testvar dutMgmtPort.  Please read the documentation for
          dutMgmtPort for more information its usage.

    step 1. Send a broadcast ARP request from client1 on Guest LAN looking for
            the MAC Address of client2 on the Guest LAN.

    step 2. Verify that the ARP request is not received by client2 on the Guest
            LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Add static ARP entry for client1 on the Guest LAN into ARP table of
            client2 on the Guest LAN.

    step 2. Add static ARP entry for client2 on the Guest LAN into ARP table of
            client1 on the Guest LAN.

    step 3. Send a unicast frame from client1 on the Guest LAN to the IP address
            of client2 on the Guest LAN.

    step 4. Verify that the unicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Send a broadcast frame from client1 on the Guest LAN.

    step 2. Verify that the broadcast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Send a multicast frame from client1 on the Guest LAN.

    step 2. Verify that the multicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Initiate MLD Report for new IPv6 multicast group from first LAN interface
    step 2. Attempt to forward layer 2 multicast from second LAN interface to first
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify IPv6 multicast succeeds for each LAN to LAN combination

    NOTE: Multicast IPv6 addresses are allocated using the IPv6 Multicast Address
    pool that is configured using testvar ipv6MulticastPoolStart and testvar
    ipv6MulticastPoolStop.

    For example:

    testvar ipv6MulticastPoolStart ff0e::1
    testvar ipv6MulticastPoolStop  ff0f::0

    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Verify ICMPv6 Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination

    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Send ICMPv6 Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMPv6 Echo Reply is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.

    step 1. Initiate HTTP Get from first LAN interface to next LAN
    step 2. Send HTTP Get using the destination MAC address of router's LAN interface
    step 3. Verify HTTP response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.

    step 1. Initiate UDP Echo from first LAN interface to next LAN
    step 2. Send UDP Echo using the destination MAC address of router's LAN interface
    step 3. Verify UDP Echo response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.

    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Send ICMPv6 Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMPv6 Echo Reply is received by second host
    step 4. Verify IPv6 Hop-Limit is decremented by 1
    step 5. Move to the second LAN interface and repeat
    step 6. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.

    step 1. Initiate ICMPv6 Echo Request using unique local addresses from first
            LAN interface to next LAN
    step 2. Verify ICMPv6 Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination

    Test Procedure:

    Step 1. For all LAN clients, send an MLD join to the DUT to subscribe to
            multicast messages on group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send a MLD leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.

    Test Procedure:

    Step 1. For all LAN clients, send an MLD join to the DUT to subscribe to
            multicast messages on group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send a MLD leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.

    step 1. Listen for RIPng reply on each WAN interface
    step 2. Verify RIPng version
    step 3. Verify source address of RIPng reply

    NOTE: This test is only run if the 'supportsRIPng' configuration
    is set to 'yes'.

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.3: Timers

    https://tools.ietf.org/html/rfc2080#section-2.3

    step 1. Announce new RIPng route with metric 5 from all WAN
            interfaces except the last WAN interface
    step 2. Announce the same RIPng route with a metric of 2 from
            the last wan interface
    step 3. Forward UDP packet from LAN client to IP address within the
            new RIPng route range
    step 4. Verify the packet is forwarded to WAN interface with the
            lowest metric

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

    step 1. Listen for RIPng updates for 1 minute
    step 2. Verify RIPng route for ULA prefixes is not announced as reachable

    NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
    expected unique local prefix advertised by the DUT.

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.2: Generating Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.5.2

    step 1. Announce new RIPng route with metric 12 from the first WAN
            interface
    step 2. Verify traffic is forwarded from LAN to WAN correctly
    step 3. Announce the same RIPng route with a metric of 2 from
            the next WAN interface
    step 4. Verify traffic is forwarded from LAN to WAN correctly using
            the new WAN interface
    step 5. Repeat for each WAN interface using a new RIPng route

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

    step 1. Wait for RIPng update on first WAN interface
    step 2. Announce new RIPng route with metric 1 from first WAN interface
    step 3. Verify triggered RIPng update is sent to additional WAN interfaces
    step 4. Verify metric for triggered update route is the original metric + 1
    step 5. Verify the packet is forwarded from LAN to correct WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.1: Triggered Updates

    https://tools.ietf.org/html/rfc2080#section-2.5.1

    step 1. Announce new RIPng route with metric 1 from second WAN interface
    step 2. Originate UDP packet from first WAN interface with destination
            inside new RIPng route
    step 3. Verify the packet is forwarded from first WAN interface to
            second WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

    step 1. Send RIPng Request from new UDP source port to RIPng destination address
    step 2. Verify router returns a RIPng response
    step 3. Verify the response is sent to the correct UDP port
    step 4. Verify the response is sent using unicast IP destination
    step 5. Repeat for each WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

    step 1. Announce new RIPng route with metric 1 from first
            WAN interface
    step 2. Wait for RIPng route timer to expire
    step 3. Verify RIPng route is announced on other WAN interfaces with
            a metric of 16
    step 4. Wait for the RIPng garbage collection timer to expire
    step 5. Verify the RIPng route is no longer announced on other WAN
            interfaces

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.3: Timers

    https://tools.ietf.org/html/rfc2080#section-2.3

    step 1. Announce new RIPng route with metric 1 from first WAN interface
    step 2. Bring down WAN link
    step 3. Wait up to 15 seconds for triggered update on second WAN interface
    step 4. Verify the route is announced with metric 16 on second WAN interface
    step 5. Bring up WAN link

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.1: Tiggered Updates

    https://tools.ietf.org/html/rfc2080#section-2.5.1

    step 1. Bring down WAN link
    step 2. Wait up to 90 seconds for router to send RIPng request to learn
            initial routing table
    step 3. Bring up WAN link

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.1: Request Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.1

    step 1. Announce new RIPng routes with metric 1 from each WAN interface

            NOTE: The 'ripMaxRoutes' testvar in your configuration file
            determines the number of RIPng routes that are announced. This
            number is divided by the number of WAN interfaces to determine
            how many RIPng routes to announce on each WAN interface.

    step 2. Forward from original LAN client to IP address within the
            each new route range
    step 3. Verify packets are forwarded to correct WAN interface
    step 4. Repeat for each RIPng route that was announced

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.1: Message Format

    https://tools.ietf.org/html/rfc2080#section-2.1

    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IPv6 on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Send UDP packet from LAN to next WAN interface
    step 4. Repeat for all WAN interfaces
    step 5. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar 'lanMtu'.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of
    the first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

    step 1. Initiate an outbound UDP connection to each WAN IPv6 address to
            establish an initial firewall mapping
    step 2. Send an inbound UDP packet with UDP data length 0 from WAN host
            on first WAN port to LAN client's global IPv6 address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Send UDP packet from next WAN interface to LAN
    step 5. Repeat for all WAN interfaces
    step 6. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar lanMtu.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

    step 1. Send an outbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from LAN host to ISP IPv6 on first
            WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 4. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

    step 1. Initiate an outbound UDP connection to first WAN IPv6 address to
            establish an initial firewall mapping that utilizes the maximum
            supported standard mtu of both interfaces
    step 2. Send an inbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from WAN host on first WAN port to
            LAN client's global IPv6 address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 5. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

    step 1. Verify the IPv6 client on Guest LAN can ping an IPv6 remote host.

    step 2. Verify the IPv6 client on Guest LAN can establish a TCP connection
            with an IPv6 remote host.

    step 3. Verify that the IPv6 client on the Guest LAN cannot ping the IPv6
            client on the Main LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that a ICMPv6 Echo sent by the client on
               the Guest LAN is not received by the client on the Main LAN.

    step 4. Verify that the IPv6 client on the Main LAN cannot ping the IPv6
            client on the Guest LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that a ICMPv6 Echo sent by the client on
               the Main LAN is not received by the client on the Guest LAN.

    step 5. Verify that the IPv6 client on the Guest LAN cannot establish a TCP
            session with the IPv6 client on the Main LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that the client on the Guest LAN cannot
               establish a TCP session with the client on the Main LAN.

    step 6. Verify that the IPv6 client on the Main LAN cannot establish a TCP
            session with the IPv6 client on the Guest LAN.

            a) Verify that a multicast Neighbor Solicitation from the client on
               the Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that the client on the Main LAN cannot
               establish a TCP session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Send a multicast Neighbor Solicitation from the IPv6 client on the
            Main LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            the IPv6 client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Send a multicast Neighbor Solicitation from the IPv6 client on the
            Guest LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            the IPv6 client on the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Add static MAC and neighbor cache entry for the IPv6 client on
            Guest LAN into neighbor cache of IPv6 client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for the IPv6 client on
            Main LAN into neighbor cache of IPv6 client on the Guest LAN.

    step 3. Send a V6 unicast frame from the client on the Main LAN to the IPv6
            address of the client on the Guest LAN.

    step 4. Verify that the V6 unicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Add static MAC and neighbor cache entry for the IPv6 client on
            Guest LAN into neighbor cache of the IPv6 client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for the IPV6 client on
            Main LAN into neighbor cache of the IPv6 client on the Guest LAN.

    step 3. Send a V6 unicast frame from the client on the Guest LAN to the IPv6
            address of the client on the Main LAN.

    step 4. Verify that the V6 unicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Send a V6 multicast frame from the client on the Main LAN.

    step 2. Verify that the V6 multicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Send a V6 multicast frame from the client on the Guest LAN.

    step 2. Verify that the V6 multicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Add static MAC and neighbor cache entry for client on Guest LAN
            into neighbor cache of client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for client on Main LAN
            into neighbor cache of client on the Guest LAN.

    step 3. Verify the client on Guest LAN can ping a IPv6 remote host.

    step 4. Verify the client on Guest LAN can establish a TCP connection
            with a IPv6 remote host.

    step 5. Verify that the V6 client on the Guest LAN cannot ping the V6 client
            on the Main LAN.

    step 6. Verify that the V6 client on the Main LAN cannot ping the V6 client
            on the Guest LAN.

    step 7. Verify that the V6 client on the Guest LAN cannot establish a TCP
            session with the V6 client on the Main LAN.

    step 8. Verify that the V6 client on the Main LAN cannot establish a TCP
            session with the V6 client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.

    step 1. Initiate a Nmap IPv6 scan for OS detection with version
            detection from the LAN using the first port in
            dutMgmtPort.

    step 2. Display the Nmap report.

    step 3. Repeat steps 1 and 2 for each port in dutMgmtPort.

    NOTE: The list of the DUT's management ports is taken from the
          testvar dutMgmtPort.  Please read the documentation for
          dutMgmtPort for more information its usage.

    step 1. Send a multicast Neighbor Solicitation from IPv6 client1 on the
            Guest LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            IPv6 client2 on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Add static MAC and neighbor cache entry for IPv6 client1 on Guest
            LAN into neighbor cache of IPv6 client2 on the Guest LAN.

    step 2. Add static MAC and neighbor cache entry for IPv6 client2 on Guest
            LAN into neighbor cache of IPv6 client1 on the Guest LAN.

    step 3. Send a V6 unicast frame from client1 on the Guest LAN to the IPv6
            address of client2 on the Guest LAN.

    step 4. Verify that the V6 unicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.

    step 1. Send a V6 multicast frame from client1 on the Guest LAN.

    step 2. Verify that the V6 multicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.