CDRouter Support

CDRouter IPv6 Test Summaries (Full)

test-summary version 13.3

Test Case Descriptions

  • Modules: 42
  • Test Cases: 655

Below is a full description of the testcases in each module


basic-v6.tcl

Basic IPv6 extension header processing tests

Test Module Name Synopsis
Verify DUT forwards packets with multiple extension headers basic-v6.tcl ipv6_basic_1 Verify DUT forwards packets with multiple extension headers


    step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
    Options and Destination Options extension headers using the PadN and Pad1
    options, respectively

            Hop-by-Hop Options Header:
              Next Header        = 0x3c (Destination Options)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Destination Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)

    step 2. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
            using the extension headers generated in Step 1
    step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers

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

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    https://tools.ietf.org/html/rfc2460#section-4.2

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.3: Hop-by-Hop Options Header

    https://tools.ietf.org/html/rfc2460#section-4.3

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.6: Destination Options Header

    https://tools.ietf.org/html/rfc2460#section-4.6

Test Module Name Synopsis
Verify DUT responds to packets with multiple extension headers basic-v6.tcl ipv6_basic_2 Verify DUT responds to packets with multiple extension headers


    step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
            Options and Destination Options extension headers using the PadN and
            Pad1 options, respectively

            Hop-by-Hop Options Header:
              Next Header        = 0x3c (Destination Options)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Destination Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)

    step 2. Initiate an ICMPv6 Echo Request to the DUT's LAN-side IPv6
            link-local address using the extension headers generated in Step 1
    step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers

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

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    https://tools.ietf.org/html/rfc2460#section-4.2

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.3: Hop-by-Hop Options Header

    https://tools.ietf.org/html/rfc2460#section-4.3

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.6: Destination Options Header

    https://tools.ietf.org/html/rfc2460#section-4.6

Test Module Name Synopsis
Verify DUT discards packets with unknown extension headers basic-v6.tcl ipv6_basic_3 Verify DUT discards packets with unknown extension headers


    step 1. Generate an ICMPv6 Echo Request packet containing a IPv6 Hop-by-Hop
            Options extension header with a Next Header value of 200 (IP
            protocol type 200 is currently unassigned)

            Hop-by-Hop Options Header:
              Next Header        = 0xc8 (IP protocol type 200, unknown)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Unrecognized Next Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)

    step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
            link-local address using the extension headers generated in Step 1
    step 3. Verify that the packet transmitted in Step 2 is discarded by
            ensuring that no ICMPv6 Echo Reply packets are received within 3
            seconds
    step 4. Optional - if an ICMPv6 Parameter Problem packet is received, verify
            that the ICMPv6 Parameter Problem message contains a value of 1 in
            the Code field
    step 5. Optional - if an ICMPv6 Parameter Problem packet is received, verify
            that the ICMPv6 Parameter Problem message contains a value of 40 in
            the Pointer field


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers

    If, as a result of processing a header, a node is required to proceed
    to the next header but the Next Header value in the current header is
    unrecognized by the node, it should discard the packet and send an
    ICMP Parameter Problem message to the source of the packet, with an
    ICMP Code value of 1 ("unrecognized Next Header type encountered")
    and the ICMP Pointer field containing the offset of the unrecognized
    value within the original packet.  The same action should be taken if
    a node encounters a Next Header value of zero in any header other
    than an IPv6 header.

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

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.4: Parameter Problem Message

    If an IPv6 node processing a packet finds a problem with a field in
    the IPv6 header or extension headers such that it cannot complete
    processing the packet, it MUST discard the packet and SHOULD send an
    ICMPv6 Parameter Problem message to the packet's source, indicating
    the type and location of the problem.

    Codes 1 and 2 are more informative subsets of Code 0.

    The pointer identifies the octet of the original packet's header
    where the error was detected. For example, an ICMPv6 message with
    Type field = 4, Code field = 1, and Pointer field = 40 would indicate
    that the IPv6 extension header following the IPv6 header of the
    original packet holds an unrecognized Next Header field value.

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

Test Module Name Synopsis
Verify DUT discards packets with Next Header value of zero in extension header basic-v6.tcl ipv6_basic_4 Verify DUT discards packets with Next Header value of zero in extension header


    step 1. Generate an ICMPv6 Echo Request packet containing the IPv6
            Hop-by-Hop Options extension header with a Next Header value of 0

            Hop-by-Hop Options Header:
              Next Header        = 0x00 (HOPOPT)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Next Extension Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)

    step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
            link-local address using the extension headers generated in Step 1
    step 3. Verify that the packet transmitted in Step 2 is discarded by
            ensuring that no ICMPv6 Echo Reply packets are received within 3
            seconds
    step 4. Optional - if an ICMPv6 Parameter Problem packet is received, verify
            that the ICMPv6 Parameter Problem message contains a value of 1 in
            the Code field
    step 5. Optional - if an ICMPv6 Parameter Problem packet is received, verify
            that the ICMPv6 Parameter Problem message contains a value of 40 in
            the Pointer field


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers

    If, as a result of processing a header, a node is required to proceed
    to the next header but the Next Header value in the current header is
    unrecognized by the node, it should discard the packet and send an
    ICMP Parameter Problem message to the source of the packet, with an
    ICMP Code value of 1 ("unrecognized Next Header type encountered")
    and the ICMP Pointer field containing the offset of the unrecognized
    value within the original packet.  The same action should be taken if
    a node encounters a Next Header value of zero in any header other
    than an IPv6 header.

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

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.4: Parameter Problem Message

    If an IPv6 node processing a packet finds a problem with a field in
    the IPv6 header or extension headers such that it cannot complete
    processing the packet, it MUST discard the packet and SHOULD send an
    ICMPv6 Parameter Problem message to the packet's source, indicating
    the type and location of the problem.

    Codes 1 and 2 are more informative subsets of Code 0.

    The pointer identifies the octet of the original packet's header
    where the error was detected. For example, an ICMPv6 message with
    Type field = 4, Code field = 1, and Pointer field = 40 would indicate
    that the IPv6 extension header following the IPv6 header of the
    original packet holds an unrecognized Next Header field value.

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

Test Module Name Synopsis
Verify DUT ignores packets with extension header containing 'No Next Header' basic-v6.tcl ipv6_basic_5 Verify DUT ignores packets with extension header containing ‘No Next Header’


    step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
            Options and Destination Options extension headers. The Hop-by-Hop
            Options extension header will have a Next Header value of 59 (no
            Next Header).

            Hop-by-Hop Options Header:
              Next Header        = 0x3b (no Next Header)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Destination Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
            link-local address using the extension header generated in Step 1
    step 3. Verify that the DUT ignores the ICMPv6 Echo Request packet by
            ensuring that no ICMPv6 Echo Reply packets are received within 3
            seconds


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.7: No Next Header

    The value 59 in the Next Header field of an IPv6 header or any
    extension header indicates that there is nothing following that
    header.  If the Payload Length field of the IPv6 header indicates the
    presence of octets past the end of a header whose Next Header field
    contains 59, those octets must be ignored, and passed on unchanged if
    the packet is forwarded.

    https://tools.ietf.org/html/rfc2460#section-4.7

Test Module Name Synopsis
Verify DUT forwards packets with extension headers containing 'No Next Header' basic-v6.tcl ipv6_basic_6 Verify DUT forwards packets with extension headers containing ‘No Next Header’


    step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
            Options and Destination Options extension headers. The Hop-by-Hop
            Options extension header will have a Next Header value of 59 (no
            Next Header).

            Hop-by-Hop Options Header:
              Next Header        = 0x3b (no Next Header)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Destination Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an ICMPv6 Echo Request (ping) to a WAN IPv6 destination
            address using the extension header generated in Step 1
    step 3. Verify that the WAN host receives the packet transmitted in Step 2
    step 4. Verify that the ICMPv6 Echo Request packet received by the WAN host
            is identical to the packet that was transmitted. Note that the
            ICMPv6 Echo Request packet may be displayed as as an IPv6 protocol
            type 0 packet (Hop-by-Hop Options) due to the inclusion of the no
            Next Header field in the Hop-by-Hop Options extension header. The
            data portion of the received IPv6 packet on the WAN should be
            analayzed for the original ICMPv6 Echo Request.


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.7: No Next Header

    The value 59 in the Next Header field of an IPv6 header or any
    extension header indicates that there is nothing following that
    header.  If the Payload Length field of the IPv6 header indicates the
    presence of octets past the end of a header whose Next Header field
    contains 59, those octets must be ignored, and passed on unchanged if
    the packet is forwarded.

    https://tools.ietf.org/html/rfc2460#section-4.7

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 00 high order bits basic-v6.tcl ipv6_basic_10 Verify DUT properly processes unknown Option Type identifiers with 00 high order bits


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 17 (0x11). Option Type 17 contains high order bits of
            00.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x11 (type 17 unknown, 00 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            a WAN IPv6 destination using the extension header generated in
            Step 1
    step 3. Verify that the DUT ignores the unknown Option Type by ensuring that
            an ICMPv6 Echo Reply (ping response) packet is received


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 01 high order bits basic-v6.tcl ipv6_basic_11 Verify DUT properly processes unknown Option Type identifiers with 01 high order bits


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 71 (0x47). Option Type 71 contains high order bits of
            01.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x47 (type 71 unknown, 01 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            a WAN IPv6 destination using the extension header generated in
            Step 1
    step 3. Verify that the DUT silently discards the packet transmitted in Step
            2 be ensuring that it does not forward an ICMPv6 Echo Request packet
            to the WAN IPv6 destination within 3 seconds
    step 4. Repeat Step 2
    step 5. Verify that the DUT silently discards the packet transmitted in Step
            4 by ensuring that it does not send an ICMPv6 Parameter Problem
            packet to the LAN source within 3 seconds


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - unicast destination basic-v6.tcl ipv6_basic_12 Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - unicast destination


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 135 (0x87). Option Type 135 contains high order bits
            of 10.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x87 (type 135 unknown, 10 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            a WAN IPv6 destination using the extension header generated in
            Step 1
    step 3. Verify that the DUT discards the packet transmitted in Step 2 by
            ensuring that it does not forward an ICMPv6 Echo Request packet to
            the WAN IPv6 destination within 3 seconds
    step 4. Repeat Step 2
    step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
            source in response to the packet transmitted in Step 4 within 3
            seconds
    step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
            2 in the Code field
    step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
            42 in the Pointer field


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - multicast destination basic-v6.tcl ipv6_basic_13 Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - multicast destination


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 135 (0x87). Option Type 135 contains high order bits
            of 10.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x87 (type 135 unknown, 10 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            the all routers multicast destination using the extension header
            generated in Step 1
    step 3. Verify that the DUT discards the packet transmitted in Step 2 be
            ensuring that it does not forward an ICMPv6 Echo Request packet to
            the LAN host within 3 seconds
    step 4. Repeat Step 2
    step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
            source in response to the packet transmitted in Step 4 within 3
            seconds
    step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
            2 in the Code field
    step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
            42 in the Pointer field


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - unicast destination basic-v6.tcl ipv6_basic_14 Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - unicast destination


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 199 (0xc7). Option Type 199 contains high order bits
            of 11.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0xc7 (type 199 unknown, 11 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            a WAN IPv6 destination using the extension header generated in
            Step 1
    step 3. Verify that the DUT discards the packet transmitted in Step 2 be
            ensuring that it does not forward an ICMPv6 Echo Request packet to
            the WAN IPv6 destination within 3 seconds
    step 4. Repeat Step 2
    step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
            source in response to the packet transmitted in Step 4 within 3
            seconds
    step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
            2 in the Code field
    step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
            42 in the Pointer field


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - multicast destination basic-v6.tcl ipv6_basic_15 Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - multicast destination


    step 1. Generate a Hop-by-Hop Options extension header with an unknown
            Option Type of 199 (0xc7). Option Type 199 contains high order bits
            of 11.

            Hop-by-Hop Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0xc7 (type 199 unknown, 11 high order bits)
              Option Data Length = 0x04 (4 bytes)
              Option Data        = 0x00000000

    step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
            the all routers multicast destination using the extension header
            generated in Step 1
    step 3. Verify that the DUT discards the packet transmitted in Step 2 and
            does not send an ICMPv6 Parameter Problem packet to the source


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

    https://tools.ietf.org/html/rfc2460#section-4.2

Test Module Name Synopsis
Verify DUT discards packets with Type 0 Routing Extension Header as an Intermediary Node basic-v6.tcl ipv6_basic_20 Verify DUT discards packets with Type 0 Routing Extension Header as an Intermediary Node


    step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
            extension header. The destination address is the gateway's global
            address, which forces header processing. The segment is set to the
            RemoteHost's IPv6 address.

            Routing Extension Header:
              Next Header        = 0x3a (ICMPv6)
              Length             = 0x06 (56 bytes)
              Routing Type       = 0x00 (Source Routing)
              Segments Left:     = 0x01

    step 2. The RemoteHost is inspected to verify the gateway did not resend the
            packet
    step 3. The packet is resent
    step 4. ICMPv6 Parameter Problem packet is verified as delivered to the LAN
            client


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 5095 "Deprecation of Type 0 Routing Headers in IPv6" Section 3: Deprecation of RH0

    An IPv6 node that receives a packet with a destination address
    assigned to it and that contains an RH0 extension header MUST NOT
    execute the algorithm specified in the latter part of Section 4.4 of
    [RFC2460] for RH0.  Instead, such packets MUST be processed according
    to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
    that includes an unrecognised Routing Type value, namely:

       If Segments Left is zero, the node must ignore the Routing header
       and proceed to process the next header in the packet, whose type
       is identified by the Next Header field in the Routing header.

       If Segments Left is non-zero, the node must discard the packet and
       send an ICMP Parameter Problem, Code 0, message to the packet's
       Source Address, pointing to the unrecognized Routing Type.

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

Test Module Name Synopsis
Verify DUT processes packets with Type 0 Routing Extension Header as an End Node basic-v6.tcl ipv6_basic_21 Verify DUT processes packets with Type 0 Routing Extension Header as an End Node


    step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
            extension header. The destination address is the gateway's global
            address, which forces header processing. The segment is set to the
            RemoteHost's IPv6 address.

            Routing Extension Header:
              Next Header        = 0x3a (ICMPv6)
              Length             = 0x06 (56 bytes)
              Routing Type       = 0x00 (Source Routing)
              Segments Left:     = 0x00

    step 2. The RemoteHost is inspected to verify the gateway did not resend the
            packet
    step 3. The packet is resent
    step 4. The LAN client is inspected to verify the ICMPv6 Echo Reply was
            received from the gateway


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 5095 "Deprecation of Type 0 Routing Headers in IPv6" Section 3: Deprecation of RH0

    An IPv6 node that receives a packet with a destination address
    assigned to it and that contains an RH0 extension header MUST NOT
    execute the algorithm specified in the latter part of Section 4.4 of
    [RFC2460] for RH0.  Instead, such packets MUST be processed according
    to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
    that includes an unrecognised Routing Type value, namely:

       If Segments Left is zero, the node must ignore the Routing header
       and proceed to process the next header in the packet, whose type
       is identified by the Next Header field in the Routing header.

       If Segments Left is non-zero, the node must discard the packet and
       send an ICMP Parameter Problem, Code 0, message to the packet's
       Source Address, pointing to the unrecognized Routing Type.

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

Test Module Name Synopsis
Verify DUT discards packets with Unknown Routing Extension Header as an Intermediary Node basic-v6.tcl ipv6_basic_22 Verify DUT discards packets with Unknown Routing Extension Header as an Intermediary Node


    step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
            extension header. The destination address is the gateway's global
            address, which forces header processing. The segment is set to the
            RemoteHost's IPv6 address.

            Routing Extension Header:
              Next Header        = 0x3a (ICMPv6)
              Length             = 0x06 (56 bytes)
              Routing Type       = 0x33 (Unknown Type)
              Segments Left:     = 0x01

    step 2. The RemoteHost is inspected to verify the gateway did not resend the
            packet
    step 3. The packet is resent
    step 4. ICMPv6 Parameter Problem packet is verified as delivered to the LAN
            client


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.4: Routing Header

    If, while processing a received packet, a node encounters a Routing
    header with an unrecognized Routing Type value, the required behavior
    of the node depends on the value of the Segments Left field, as
    follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.

    https://tools.ietf.org/html/rfc2460#section-4.4

Test Module Name Synopsis
Verify DUT processes packets with Unknown Routing Extension Header as an End Node basic-v6.tcl ipv6_basic_23 Verify DUT processes packets with Unknown Routing Extension Header as an End Node


    step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
            extension header. The destination address is the gateway's global
            address, which forces header processing. The segment is set to the
            RemoteHost's IPv6 address.

            Routing Extension Header:
              Next Header        = 0x3a (ICMPv6)
              Length             = 0x06 (56 bytes)
              Routing Type       = 0x33 (Unknown Type)
              Segments Left:     = 0x00

    step 2. The RemoteHost is inspected to verify the gateway did not resend the
            packet
    step 3. The packet is resent
    step 4. The LAN client is inspected to verify the ICMPv6 Echo Reply was
            received from the gateway


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.4: Routing Header

    If, while processing a received packet, a node encounters a Routing
    header with an unrecognized Routing Type value, the required behavior
    of the node depends on the value of the Segments Left field, as
    follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.

    https://tools.ietf.org/html/rfc2460#section-4.4


frag-v6.tcl

IPv6 fragmentation tests

Test Module Name Synopsis
Verify DUT responds to fragmented ICMPv6 Echo Requests frag-v6.tcl ipv6_frag_1 Verify DUT responds to fragmented ICMPv6 Echo Requests


    step 1. Generate a valid 3000 byte ICMPv6 Echo Request packet
    step 2. Set IPv6 MTU of the LAN to 1280 bytes
    step 3. Initiate an outbound ICMPv6 Echo Request (ping) to the DUT's
            LAN-side IPv6 link-local address using the packet generated in
            Step 1
    step 4. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header

    https://tools.ietf.org/html/rfc2460#section-4.5

Test Module Name Synopsis
Verify DUT forwards fragmented ICMPv6 packets frag-v6.tcl ipv6_frag_2 Verify DUT forwards fragmented ICMPv6 packets


    step 1. Generate a valid 3000 byte ICMPv6 Echo Request packet
    step 2. Set IPv6 MTU of the LAN client to 1280 bytes
    step 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytes
    step 4. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
            using the packet generated in Step 1
    step 5. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header

    https://tools.ietf.org/html/rfc2460#section-4.5

Test Module Name Synopsis
Verify DUT forwards fragmented UDP packets frag-v6.tcl ipv6_frag_3 Verify DUT forwards fragmented UDP packets


    step 1. Generate a valid 3000 byte UDP Echo packet
    step 2. Set IPv6 MTU of the LAN client to 1280 bytes
    step 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytes
    step 4. Initiate an outbound UDP Echo to a WAN IPv6 destination using the
            packet generated in Step 1
    step 5. Verify that a UDP Echo response is received on the LAN


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header

    https://tools.ietf.org/html/rfc2460#section-4.5


ndp.tcl

Neighbor Discovery Protocol and Router Advertisement tests for IPv6 devices

Test Module Name Synopsis
Verify DUT responds to Router Solicitations on the LAN ndp.tcl ipv6_ndp_1 Verify DUT responds to Router Solicitations on the LAN


    step 1. Send a Router Solicitation from the LAN
    step 2. Wait for a Router Advertisement from the DUT
    step 3. Verify the fields in the Router Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT periodically sends unsolicited Router Advertisements ndp.tcl ipv6_ndp_2 Verify DUT periodically sends unsolicited Router Advertisements


    step 1. Listen for a Router Advertisement on the LAN
    step 2. Wait for a second Router Advertisement on the LAN
    step 3. Verify that the DUT is periodically sending Advertisments

    NOTE: The testvar ipv6RAInterval will control how long this test waits for a
    Router Advertisement.


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations for its link-local address ndp.tcl ipv6_ndp_10 Verify DUT responds to Neighbor Solicitations for its link-local address


    step 1. Send a Neighbor Solicitation on the LAN for the DUT's link-local address
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify fields of the Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations for its global IPv6 address ndp.tcl ipv6_ndp_11 Verify DUT responds to Neighbor Solicitations for its global IPv6 address


    step 1. Send a Neighbor Solicitation on the LAN for the DUT's global IPv6 address
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify fields of Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT ignores Neighbor Solicitations with an invalid hop-count ndp.tcl ipv6_ndp_12 Verify DUT ignores Neighbor Solicitations with an invalid hop-count


    step 1. Send an Neighbor Solicitation for the DUT's link-local address with a hop-count of 64
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to DAD-style Neighbor Solicitations for link-local address on LAN ndp.tcl ipv6_ndp_13 Verify DUT responds to DAD-style Neighbor Solicitations for link-local address on LAN


    step 1. Send a Duplicate-Address-Detection (DAD) style Neighbor Solicition
            for the DUT's link-local address on the LAN
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify source, destination, and contents of Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection

    https://tools.ietf.org/html/rfc4862#section-5.4

Test Module Name Synopsis
Verify DUT ignores Neighbor Solicitations with a different target than itself ndp.tcl ipv6_ndp_14 Verify DUT ignores Neighbor Solicitations with a different target than itself


    step 1. Send an Neighbor Solicitation for the lanStack's link-local address to the DUT's link-local address
            and its global address
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address ndp.tcl ipv6_ndp_15 Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address


    step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrong
            Solicited-Node Multicast Address
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to DAD-style Neighbor Solicitations for global address on LAN ndp.tcl ipv6_ndp_16 Verify DUT responds to DAD-style Neighbor Solicitations for global address on LAN


    step 1. Send a Duplicate-Address-Detection (DAD) style Neighbor Solicition
            for the DUT's global address on the LAN
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify source, destination, and contents of Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection

    https://tools.ietf.org/html/rfc4862#section-5.4

Test Module Name Synopsis
Verify DUT sends ICMPv6 Redirect messages for neighbor traffic forwarded to it ndp.tcl ipv6_ndp_20 Verify DUT sends ICMPv6 Redirect messages for neighbor traffic forwarded to it


    step 1: Create a new client on the LAN
    step 2: Send a ping to the Global-Unicast-Address of the new client
    step 3: Verify the DUT sends an ICMPv6 Redirect messsage
    step 4. Verify the ICMPv6 Redirect message
    step 5: Verify the new client responds to the ping

    NOTE: This test is similar to ipv6_forward_3, except it verifies that the
    DUT is sending valid ICMPv6 Redirect messages back to the sender. Test
    ipv6_forward_3 verifies that the packet is forwarded to the correct
    destination.


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 8: Redirect Function

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

Test Module Name Synopsis
Verify Router Advertisements contain M bit and O bit based on LAN mode ndp.tcl ipv6_ndp_30 Verify Router Advertisements contain M bit and O bit based on LAN mode


    step 1. Listen for a Router Advertisement on the LAN
    step 2. Check the "managed address configuration" flag (M bit) in the Router
            Advertisement received in Step 1
    step 3. If the DUT is configured to provide global addresses via DHCPv6 on
            the LAN, the M bit should be set; if autoconfiguration is used
            instead, the M bit should not be set
    step 4. If the DUT is configured to provide global addresses via
            autoconfiguration on the LAN, and the "other stateful configuration"
            flag (O bit) is set, send a DHCPv6 Information-request including an
            Option Request for DHCPv6 Options 23 'DNS Recursive Name Server'
            and 24 'Domain Search List' to the DUT. Skip to Step 6.
    step 5. If the DUT is configured to provide global addresses via
            DHCPv6 and the "managed address configuration" flag
            (M bit) is set, send a DHCPv6 Information-request including an
            Option Request for DHCPv6 Options 23 'DNS Recursive Name Server'
            and 24 'Domain Search List' to the DUT
    step 6. Verify that the DUT sends a DHCPv6 Reply in response to the DHCPv6
            Information-request message sent by the client in Steps 4 or 5
    step 7. Verify that the DUT's DHCPv6 Reply includes DHCPv6 Options 23 and 24
    Step 8. Verify the DNS server information provided by the DUT. If the testvar
            ipv6DNStoLAN is set to "yes", the DNS server addresses provided should
            match the addresses of the DNS servers configured on the WAN. If the
            ipv6DNStoLAN testvar is set to "no", the LAN side IPv6 address of the
            DUT should be provided as the DNS server.
    step 9. Verify the domain search list information provided by the DUT


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.2: Router Advertisement Message Format

    https://tools.ietf.org/html/rfc4861#section-4.2

Test Module Name Synopsis
Verify Router Advertisements contain valid prefix, A bit, and L bit based on LAN settings ndp.tcl ipv6_ndp_31 Verify Router Advertisements contain valid prefix, A bit, and L bit based on LAN settings


    step 1. Listen for Router Advertisements on the LAN for one Router
            Advertisement interval
    step 2. Verify at least one Router Advertisement contains a valid prefix
            based on the DUT's LAN IPv6 address
    step 3. Verify that the prefix length associated with the prefix discovered
            in Step 2 is the same as the DUT's configured LAN prefix length
            (skip this step if the IPv6 WAN mode is 6to4)
    step 4. Verify that the prefix discovered in Step 2 contains a valid
            lifetime
    step 5. Check the autonomous address-configuration flag (A bit) in the
            Router Advertisement received in Step 1
    step 6. If the DUT is configured to provide global addresses via DHCPv6 on
            the LAN, the A bit should not be set; if autoconfiguration is used
            instead, the A bit should be set
    step 7. Verify that the prefix discovered in Step 2 has the on-link flag
            (L bit) set

    NOTE: This test is designed to work with DUT's that support only a single
    LAN mode for address autoconfiguration, either DHCPv6 or autoconfiguration.
    DUT configurations in which both modes are enabled simultaneously (where
    the 'A' and 'M' bits are both set) are not currently supported by this test.


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information

    https://tools.ietf.org/html/rfc4861#section-4.6.2

Test Module Name Synopsis
Verify Router Advertisements contain RDNSS option ndp.tcl ipv6_ndp_32 Verify Router Advertisements contain RDNSS option


    step 1. Listen for a Router Advertisement on the LAN
    step 2. Verify that one or more RDNSS options (25) are present in RA
    step 3. Verify the addresses provided in RDNSS options. If the testvar
            ipv6DNStoLAN is set to "yes", the DNS server addresses listed
            in the RDNSS option should match the addresses of the DNS
            servers configured on the WAN. If the ipv6DNStoLAN testvar is
            set to "no", the RDNSS option should list only the LAN side
            IPv6 address of the DUT (global or link-local address).
    step 4. Verify the RDNSS option lifetime

    NOTE: This test is skipped if the testvar ipv6RdnssSupport is set to no
    indicating that the device does not support the RDNSS option.


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 6106 "IPv6 Router Advertisement Options for DNS Configuration"

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

Test Module Name Synopsis
Verify Router Advertisements contain DNSSL option ndp.tcl ipv6_ndp_33 Verify Router Advertisements contain DNSSL option


    step 1. Listen for a Router Advertisement on the LAN
    step 2. Verify that one or more DNSSL options (31) are present in RA
    step 3. Verify the domain search list provided in the DNSSL option. The
            domain search list should contain the domain name specified by the
            testvar wanDomainName.
    step 4. Verify the DNSSL option lifetime

    NOTE: This test is skipped if the testvar ipv6DnsslSupport is set to no
    indicating that the device does not support the DNSSL option.


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 6106 "IPv6 Router Advertisement Options for DNS Configuration"

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

Test Module Name Synopsis
Verify DUT does not advertise itself as a default router when WAN RA lifetime is 0 ndp.tcl ipv6_ndp_34 Verify DUT does not advertise itself as a default router when WAN RA lifetime is 0


    step 1. Send Router Advertisements on the WAN with a Router Lifetime of 0
    step 2. Listen for RAs from the DUT on the LAN for up to the [dhcpv6PDLatency
            + 1 LAN RA interval]
    step 3. Verify that the DUT eventually stops advertising itself as a default
            router by setting the Router Lifetime in LAN RAs to a value of 0
    step 3. Restore original Router Lifetime on WAN and start sending Router
            Advertisements on the WAN with a non-zero Router Lifetime
    step 4. Verify that the DUT starts advertising itself as a default router by
            setting the Router Lifetime in LAN RAs to a value greater than 0
    step 5. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-4: By default, an IPv6 CE router that has no default
         router(s) on its WAN interface MUST NOT advertise
         itself as an IPv6 default router on its LAN interfaces.
         That is, the "Router Lifetime" is set to zero in all
         Router Advertisement messages it originates [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-5: By default, if the IPv6 CE router is an advertising router and
         loses its IPv6 default router(s) and/or detects loss of
         connectivity on the WAN interface, it MUST explicitly
         invalidate itself as an IPv6 default router on each of its
         advertising interfaces by immediately transmitting one or more
         Router Advertisement messages with the "Router Lifetime" field
         set to zero [RFC4861].

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

Test Module Name Synopsis
Verify Neighbor Unreachability Detection ndp.tcl ipv6_ndp_40 Verify Neighbor Unreachability Detection


    step 1. Disable LAN client to prevent the DUT from receiving
            reachability confirmations
    step 2. Wait (ReachableTime + DELAY_FIRST_PROBE_TIME +
            (MAX_UNICAST_SOLICIT * RetransTimer)) seconds to ensure DUT's
            neighbor cache entry (NCE) for LAN client is deleted
    step 3. Enable LAN client
    step 4. Send a Neighbor Solicitation on the LAN for the DUT's
            link-local address to create a NCE on the DUT for the LAN
            client's link-local address in the STALE state
    step 5. Verify a Neighbor Advertisement is received from the DUT
    step 6. Send an ICMPv6 Echo Request from the LAN to the DUT's
            link-local address to transition the NCE on the DUT from
            STALE to DELAY state.
    step 7. Verify an ICMPv6 Echo Reply is received from the DUT
    step 8. Disable neighbor discovery (ND) on LAN client to prevent
            the sending of Neighbor Advertisements
    step 9. Wait DELAY_FIRST_PROBE_TIME-1 seconds to allow the NCE on
            the DUT to transition from DELAY to PROBE state
    step 10. Wait RetransTimer+1 seconds for the DUT to send a unicast
             Neighbor Solicitation for the LAN client's link local address
    step 11. Verify LAN client receives a unicast Neighbor Solicitation
    step 12. Repeat steps 10 and 11 to ensure that MAX_UNICAST_SOLICIT
             Neighbor Solications are sent.  On the
             MAX_UNICAST_SOLICIT'th Neighbor Solication, reenable
             neighbor discovery on LAN client and respond to the
             Neighbor Solicitation with a Neighbor Advertisement to
             allow the DUT's NCE to transition from PROBE to REACHABLE
             state
    step 13. Disable LAN client to prevent the DUT from receiving
             reachability confirmations
    step 14. Wait ReachableTime+1 seconds to allow DUT's NCE to
             transition from REACHABLE to STALE state
    step 15. Enable LAN client
    step 16. Send an ICMPv6 Echo Request from the LAN to the DUT's
             link-local address to transition the NCE on the DUT from
             STALE to DELAY state.
    step 17. Verify an ICMPv6 Echo Reply is received from the DUT
    step 18. Disable neighbor discovery (ND) on LAN client to prevent
             the sending of Neighbor Advertisements
    step 19. Wait DELAY_FIRST_PROBE_TIME-1 seconds to allow the NCE on
             the DUT to transition from DELAY to PROBE state
    step 20. Wait RetransTimer+1 seconds for the DUT to send a unicast
             Neighbor Solicitation for the LAN client's link local address
    step 21. Verify LAN client receives a unicast Neighbor Solicitation
    step 22. Repeat steps 20 and 21 to ensure that MAX_UNICAST_SOLICIT
             Neighbor Solications are sent.  The DUT's NCE should now
             be deleted


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 7.3: Neighbor Unreachability Detection

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

Test Module Name Synopsis
Verify ICMPv6 Destination Unreachable sent on address resolution failure ndp.tcl ipv6_ndp_41 Verify ICMPv6 Destination Unreachable sent on address resolution failure


    step 1. Wait 60 seconds to ensure DUT has no neighbor cache entry
            (NCE) for ipv6WanIspNextIp
    step 2. Send an ICMPv6 Echo Request from the LAN to ipv6WanIspNextIp
    step 3. Wait 2 seconds for DUT to send a Neighbor Solicitation on
            the WAN.
    step 4. Verify that the Neighbor Solicitation is sent to the
            solicited-node multicast corresponding to ipv6WanIspNextIp
            with target ipv6WanIspNextIp and includes a Source
            Link-Layer Address option
    step 5. Repeat steps 3 & 4 MAX_MULTICAST_SOLICIT (3) times
    step 6. Verify DUT sends an ICMPv6 Destination Unreachable message
            to the LAN client with code 3 (Address Unreachable)


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 7.2.2: Sending Neighbor Solicitations

    https://tools.ietf.org/html/rfc4861#section-7.2.2


ndp-wan.tcl

Neighbor Discovery Protocol and Router Advertisement tests for the WAN side of IPv6 devices

Test Module Name Synopsis
Verify if DUT responds to Router Solicitations on the WAN ndp-wan.tcl ipv6_ndp_wan_1 Verify if DUT responds to Router Solicitations on the WAN


    step 1. Send a Router Solicitation from the WAN
    step 2. Wait to see if DUT sends a Router Advertisement on the WAN
    step 3. Verify the expected behavior

    Note: The testvar ipv6ExpectRAonWan determines if this test should
          expect to see Router Advertisements from the DUT on the WAN


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify if DUT periodically sends unsolicited Router Advertisements ndp-wan.tcl ipv6_ndp_wan_2 Verify if DUT periodically sends unsolicited Router Advertisements


    step 1. Wait for a Router Advertisement on the WAN
    step 2. Wait for a second Router Advertisement on the WAN
    step 3. Verify if the DUT is periodically sending Advertisments as expected

    Notes: The testvar ipv6ExpectRAonWan determines if this test should
           expect to see Router Advertisements from the DUT on the WAN

           The testvar ipv6RAInterval will control how long
           this test waits for a Router Advertisement.



    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations on the WAN for its link-local address ndp-wan.tcl ipv6_ndp_wan_10 Verify DUT responds to Neighbor Solicitations on the WAN for its link-local address


    step 1. Send a Neighbor Solicitation on the WAN for the DUT's link-local address
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify fields of the Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations on the WAN for its global IPv6 address ndp-wan.tcl ipv6_ndp_wan_11 Verify DUT responds to Neighbor Solicitations on the WAN for its global IPv6 address


    step 1. Send a Neighbor Solicitation on the WAN for the DUT's global IPv6 address
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify fields of Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT ignores invalid Neighbor Solicitations sent on the WAN ndp-wan.tcl ipv6_ndp_wan_12 Verify DUT ignores invalid Neighbor Solicitations sent on the WAN


    step 1. Send an invalid Neighbor Solicitation for the DUT's WAN-side global address
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its link local address ndp-wan.tcl ipv6_ndp_wan_13 Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its link local address


    step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's
            link-local address on the WAN
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify source, destination, and contents of Neighbor Advertisement

    Reference: RFC 4862 Section 5.4


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection

    https://tools.ietf.org/html/rfc4862#section-5.4

Test Module Name Synopsis
Verify DUT ignores Neighbor Solicitations with a different target than itself ndp-wan.tcl ipv6_ndp_wan_14 Verify DUT ignores Neighbor Solicitations with a different target than itself


    step 1. Send an Neighbor Solicitation for the wanStack's link-local address to the DUT's
            link-local address and its global address
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address ndp-wan.tcl ipv6_ndp_wan_15 Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address


    step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrong
            Solicited-Node Multicast Address
    step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
    step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its global IPv6 address ndp-wan.tcl ipv6_ndp_wan_16 Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its global IPv6 address


    step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's
            global address on the WAN
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify source, destination, and contents of Neighbor Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection

    https://tools.ietf.org/html/rfc4862#section-5.4


dhcpv6-c.tcl

DHCPv6 client tests for the WAN side of the router

Test Module Name Synopsis
Verify client requests the assignment of a non-temporary address dhcpv6-c.tcl dhcpv6_1 Verify client requests the assignment of a non-temporary address


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


    References:

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

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

Test Module Name Synopsis
Verify client renews non-temporary address when current binding expires dhcpv6-c.tcl dhcpv6_2 Verify client renews non-temporary address when current binding expires


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


    References:

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

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

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

Test Module Name Synopsis
Verify client obtains address from server using various undefined server DUID values dhcpv6-c.tcl dhcpv6_4 Verify client obtains address from server using various undefined server DUID values


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


    References:

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

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

Test Module Name Synopsis
Verify client ignores replies with mismatched client DUID dhcpv6-c.tcl dhcpv6_10 Verify client ignores replies with mismatched client DUID


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


    References:

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

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

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

Test Module Name Synopsis
Verify client ignores unknown or invalid DHCPv6 packets dhcpv6-c.tcl dhcpv6_11 Verify client ignores unknown or invalid DHCPv6 packets


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


    References:

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

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

Test Module Name Synopsis
Verify client handles fragmented IPv6 packets dhcpv6-c.tcl dhcpv6_14 Verify client handles fragmented IPv6 packets


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


    References:

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

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

Test Module Name Synopsis
Verify client ignores server messages with invalid UDP checksum dhcpv6-c.tcl dhcpv6_15 Verify client ignores server messages with invalid UDP checksum


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


    References:

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

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

Test Module Name Synopsis
Verify client composes DUID correctly dhcpv6-c.tcl dhcpv6_16 Verify client composes DUID correctly


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

    Reference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"


    References:

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

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

Test Module Name Synopsis
Verify client restarts when NoBinding failure occurs during Renew dhcpv6-c.tcl dhcpv6_20 Verify client restarts when NoBinding failure occurs during Renew


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


    References:

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

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

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

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

    -  otherwise accepts the information in the IA

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

Test Module Name Synopsis
Verify client restarts when UnspecFail failure occurs during Renew dhcpv6-c.tcl dhcpv6_21 Verify client restarts when UnspecFail failure occurs during Renew


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


    References:

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

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

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

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 dhcpv6-c.tcl dhcpv6_22 Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0


    step 1. Allow the DHCPv6 client to restart DHCPv6 by waiting for the IA_NA
            lifetime to expire without replying to any DHCPv6 messages
    step 2. Send a valid Advertise message in response to the DHCPv6 client's
            Solicit message
    step 3. Verify the DHCPv6 client sends a Request message
    step 4. Send a valid Reply message with all IA lifetimes set to 0
    step 5. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 6. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 7. Verify DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 dhcpv6-c.tcl dhcpv6_23 Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0


    step 1. Wait for DHCPv6 client's current IA_NA binding T1 timer to expire
    step 2. Verify the DHCPv6 client sends a DHCPv6 Renew
    step 3. Send a valid Reply message with all IA lifetimes set to 0
    step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 dhcpv6-c.tcl dhcpv6_24 Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0


    step 1. Wait for DHCPv6 client's current IA_NA binding T2 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Rebind
    step 3. Send a valid Reply message with all IA lifetimes set to 0
    step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client sends Rebind message if Renew for non-temporary address fails dhcpv6-c.tcl dhcpv6_30 Verify client sends Rebind message if Renew for non-temporary address fails


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


    References:

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

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

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

Test Module Name Synopsis
Verify client sends Solicit message if Renew and Rebind for non-temporary address fails dhcpv6-c.tcl dhcpv6_31 Verify client sends Solicit message if Renew and Rebind for non-temporary address fails


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


    References:

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

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

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

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

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

Test Module Name Synopsis
Verify client supports DHCPv6 Reconfigure Key Authentication dhcpv6-c.tcl dhcpv6_32 Verify client supports DHCPv6 Reconfigure Key Authentication


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding
            exists
    step 3. Verify DHCPv6 Reconfigure Key exists for binding
    step 4. Send Reconfigure message requesting Renew
    step 5. Verify DHCPv6 client sends DHCPv6 Renew

    Reference:

    IETF RFC 3315 Section 21.5 "Reconfigure Key Authentication Protocol"


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 21.5: Reconfigure Key Authentication Protocol

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

Test Module Name Synopsis
Verify client ignores DHCPv6 Reconfigure without Authentication option dhcpv6-c.tcl dhcpv6_33 Verify client ignores DHCPv6 Reconfigure without Authentication option


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding
            exists
    step 3. Verify DHCPv6 Reconfigure Key exists for binding
    step 4. Send Reconfigure message requesting Renew without
            Authentication option
    step 5. Verify DHCPv6 client does not send DHCPv6 Renew, Rebind or
            Information-Request


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.11: Reconfigure Message

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

Test Module Name Synopsis
Verify client ignores DHCPv6 Reconfigure with incorrect Reconfigure Key dhcpv6-c.tcl dhcpv6_34 Verify client ignores DHCPv6 Reconfigure with incorrect Reconfigure Key


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding
            exists
    step 3. Verify DHCPv6 Reconfigure Key exists for binding
    step 4. Send Reconfigure message requesting Renew using
            incorrect DHCPv6 Reconfigure Key
    step 5. Verify DHCPv6 client does not send DHCPv6 Renew, Rebind or
            Information-Request


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.11: Reconfigure Message

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

Test Module Name Synopsis
Verify client supports DHCPv6 Reconfigure with Rebind request dhcpv6-c.tcl dhcpv6_35 Verify client supports DHCPv6 Reconfigure with Rebind request


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding
            exists
    step 3. Verify DHCPv6 Reconfigure Key exists for binding
    step 4. Send Reconfigure message requesting Rebind
    step 5. Verify DHCPv6 client sends DHCPv6 Rebind


    References:

    IETF RFC 6644 "Rebind Capability in DHCPv6 Reconfigure Messages" Section 5: Client Behavior

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

Test Module Name Synopsis
Verify client ignores DHCPv6 Reconfigure requesting a Solicit dhcpv6-c.tcl dhcpv6_36 Verify client ignores DHCPv6 Reconfigure requesting a Solicit


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding
            exists
    step 3. Verify DHCPv6 Reconfigure Key exists for binding
    step 4. Send Reconfigure message requesting Solicit
    step 5. Verify DHCPv6 client does not send DHCPv6 Solicit, Renew,
            Rebind or Information-Request


    References:

    IETF RFC 6644 "Rebind Capability in DHCPv6 Reconfigure Messages" Section 5: Client Behavior

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

Test Module Name Synopsis
Verify client retransmits DHCPv6 Solicit messages for non-temporary address dhcpv6-c.tcl dhcpv6_50 Verify client retransmits DHCPv6 Solicit messages for non-temporary address


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


    References:

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

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

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

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

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

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

Test Module Name Synopsis
Verify client retransmits DHCPv6 Request messages for non-temporary address dhcpv6-c.tcl dhcpv6_51 Verify client retransmits DHCPv6 Request messages for non-temporary address


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

    Reference: IETF RFC 3315 Section 14 "Reliability of Client Initiated
    Message Exchanges"

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

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


    References:

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

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

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

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

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

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

Test Module Name Synopsis
Verify client learns new non-temporary address when WAN DHCPv6 server renumbers dhcpv6-c.tcl dhcpv6_60 Verify client learns new non-temporary address when WAN DHCPv6 server renumbers


    step 1. Change the client's DHCPv6 binding to use the new
            non-temporary IPv6 address address specified by the testvar
            "ipv6WanIspNextIp"
    step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
    step 3. Verify Renew or Request contains IA_NA option (3) for same
            non-temporary address
    step 4. Send valid DHCPv6 Reply with new non-temporary address
    step 5. Verify client updates with new non-temporary address
    step 6. Ping client's new non-temporary address
    step 7. Restore client's original non-temporary address by repeating
            Steps 1 through 5 using original non-temporary address
    step 8. Ping client's original non-temporary address


    References:

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

    If the Reply was received in response to a Solicit (with a Rapid
    Commit option), Request, Renew or Rebind message, the client updates
    the information it has recorded about IAs from the IA options
    contained in the Reply message:

    -  Record T1 and T2 times.

    -  Add any new addresses in the IA option to the IA as recorded by
       the client.

    -  Update lifetimes for any addresses in the IA option that the
       client already has recorded in the IA.

    -  Discard any addresses from the IA, as recorded by the client, that
       have a valid lifetime of 0 in the IA Address option.

    -  Leave unchanged any information about addresses the client has
       recorded in the IA but that were not included in the IA from the
       server.

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

Test Module Name Synopsis
Verify client obtains IPv6 address when server uses unknown DHCPv6 options dhcpv6-c.tcl dhcpv6_100 Verify client obtains IPv6 address when server uses unknown DHCPv6 options


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


    References:

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

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

Test Module Name Synopsis
Verify client ignores DHCPv6 messages with unknown options and invalid option length dhcpv6-c.tcl dhcpv6_101 Verify client ignores DHCPv6 messages with unknown options and invalid option length


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


    References:

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

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

Test Module Name Synopsis
Verify client includes the Elapsed Time option with value 0 in first message dhcpv6-c.tcl dhcpv6_102 Verify client includes the Elapsed Time option with value 0 in first message


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


    References:

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

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

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

Test Module Name Synopsis
Verify client increases value of Elapsed Time option when Solicit is retransmitted dhcpv6-c.tcl dhcpv6_103 Verify client increases value of Elapsed Time option when Solicit is retransmitted


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


    References:

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

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

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

Test Module Name Synopsis
Verify client handles Server Unicast Option dhcpv6-c.tcl dhcpv6_130 Verify client handles Server Unicast Option


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


    References:

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

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

Test Module Name Synopsis
Verify client handles SOL_MAX_RT Option dhcpv6-c.tcl dhcpv6_140 Verify client handles SOL_MAX_RT Option


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


    References:

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

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

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

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

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

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

Test Module Name Synopsis
Verify DHCPv6 client includes vendor defined options dhcpv6-c.tcl dhcpv6_150 Verify DHCPv6 client includes vendor defined options


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

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


    References:

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

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

Test Module Name Synopsis
Verify client supports DHCPv6 Rapid Commit option dhcpv6-c.tcl dhcpv6_160 Verify client supports DHCPv6 Rapid Commit option


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


    References:

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

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

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

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


dhcpv6-pd.tcl

DHCPv6 prefix delegation tests for WAN to LAN IPv6 configuration

Test Module Name Synopsis
Verify client requests the assignment of an IPv6 prefix dhcpv6-pd.tcl dhcpv6_pd_1 Verify client requests the assignment of an IPv6 prefix


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not prefix binding exists
    step 3. Verify Valid and Preferred lifetimes for binding
    step 4. Verify that the binding has not expired


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    The requesting router uses a Request message to populate IA_PDs with
    prefixes.  The requesting router includes one or more IA_PD options
    in the Request message.  The delegating router then returns the
    prefixes for the IA_PDs to the requesting router in IA_PD options in
    a Reply message.

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify client renews prefix when current binding expires dhcpv6-pd.tcl dhcpv6_pd_2 Verify client renews prefix when current binding expires


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


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 7: Overview of DHCP with Prefix Delegation

    Before the valid lifetime on each delegated prefix expires, the
    requesting router includes the prefix in an IA_PD option sent in a
    Renew message to the delegating router.  The delegating router
    responds by returning the prefix with updated lifetimes to the
    requesting router.

    https://tools.ietf.org/html/rfc3633#section-7

Test Module Name Synopsis
Verify client sends router advertisements on LAN with delegated prefix dhcpv6-pd.tcl dhcpv6_pd_10 Verify client sends router advertisements on LAN with delegated prefix


    step 1. Listen for IPv6 router advertisements from DUT on LAN
    step 2. Verify that router advertisement contains Prefix Information
            option (3) with valid prefix based on prefix assigned
            by DHCPv6 server on WAN


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    Upon the receipt of a valid Reply message, for each IA_PD the
    requesting router assigns a subnet from each of the delegated
    prefixes to each of the links to which the associated interfaces are
    attached, with the following exception: the requesting router MUST
    NOT assign any delegated prefixes or subnets from the delegated
    prefix(es) to the link through which it received the DHCP message
    from the delegating router.

    https://tools.ietf.org/html/rfc3633#section-12.1

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-2:  The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) for each of its LAN interfaces.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify client sends router advertisements on LAN with prefix lifetimes based on IA_PD lifetimes dhcpv6-pd.tcl dhcpv6_pd_11 Verify client sends router advertisements on LAN with prefix lifetimes based on IA_PD lifetimes


    step 1. Listen for IPv6 router advertisements from DUT on LAN
    step 2. Verify that router advertisement contains Prefix Information
            option (3) with valid prefix based on prefix assigned
            by DHCPv6 server on WAN
    step 3. Verify Prefix Information option (3) contains a Valid lifetime
            not greater than the valid lifetime provided by the DHCPv6
            server in the IA_PD Prefix option
    step 4. Verify Prefix Information option (3) contains a Preferred
            lifetime not greater than the preferred lifetime provided by
            the DHCPv6 server in the IA_PD Prefix option


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    If the requesting router assigns a delegated prefix to a link to
    which the router is attached, and begins to send router
    advertisements for the prefix on the link, the requesting router MUST
    set the valid lifetime in those advertisements to be no later than
    the valid lifetime specified in the IA_PD Prefix option.  A
    requesting router MAY use the preferred lifetime specified in the
    IA_PD Prefix option.

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify LAN side DHCPv6 client address is based on WAN side delegated prefix dhcpv6-pd.tcl dhcpv6_pd_12 Verify LAN side DHCPv6 client address is based on WAN side delegated prefix


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address prefix on the LAN
            matches the prefix delegated on the WAN

    NOTE: This test only applies to configurations where LAN clients
    obtain IPv6 addresses via DHCPv6


Test Module Name Synopsis
Verify LAN side DHCPv6 client lifetime is based on WAN side IA_PD prefix lifetimes dhcpv6-pd.tcl dhcpv6_pd_13 Verify LAN side DHCPv6 client lifetime is based on WAN side IA_PD prefix lifetimes


    step 1. Listen for IPv6 router advertisements from DUT on LAN
    step 2. Verify that router advertisement contains Prefix Information
            option (3) with valid prefix based on prefix assigned
            by DHCPv6 server on WAN
    step 3. Verify Prefix Information option (3) contains a Valid lifetime
            not greater than the valid lifetime provided by the DHCPv6
            server in the IA_PD Prefix option
    step 4. Verify Prefix Information option (3) contains a Preferred
            lifetime not greater than the preferred lifetime provided by
            the DHCPv6 server in the IA_PD Prefix option


Test Module Name Synopsis
Verify client router advertisements on LAN include expected subnet ID dhcpv6-pd.tcl dhcpv6_pd_14 Verify client router advertisements on LAN include expected subnet ID


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains prefix based on public IPv4 WAN
    step 3. Verify advertised prefix includes the expected subnet ID

    Note: The expected subnet ID bits can be configured using the testvar
    ipv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length string
    of hex characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


Test Module Name Synopsis
Verify DUT does not advertise itself as a default router when WAN link is down dhcpv6-pd.tcl dhcpv6_pd_15 Verify DUT does not advertise itself as a default router when WAN link is down


    step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
            link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
            modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
            server and wait for the current IA_NA and/or IA_PD bindings to
            expire
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT eventually stops advertising itself as a default
            router by setting the Router Lifetime in LAN RAs to a value of 0
    step 4. Restore all services on the WAN and wait for the WAN link to be
            re-established by the DUT
    step 5. Verify that the DUT starts advertising itself as a default router by
            setting the Router Lifetime in LAN RAs to a value greater than 0
    step 7. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-4:  By default, an IPv6 CE router that has no default
          router(s) on its WAN interface MUST NOT advertise
          itself as an IPv6 default router on its LAN interfaces.
          That is, the "Router Lifetime" is set to zero in all
          Router Advertisement messages it originates [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-5:  By default, if the IPv6 CE router is an advertising router and
          loses its IPv6 default router(s) and/or detects loss of
          connectivity on the WAN interface, it MUST explicitly
          invalidate itself as an IPv6 default router on each of its
          advertising interfaces by immediately transmitting one or more
          Router Advertisement messages with the "Router Lifetime" field
          set to zero [RFC4861].

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

Test Module Name Synopsis
Verify client restarts when NoBinding failure occurs during IA_PD Renew dhcpv6-pd.tcl dhcpv6_pd_20 Verify client restarts when NoBinding failure occurs during IA_PD Renew


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


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify client restarts when UnspecFail failure occurs during IA_PD Renew dhcpv6-pd.tcl dhcpv6_pd_21 Verify client restarts when UnspecFail failure occurs during IA_PD Renew


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


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 dhcpv6-pd.tcl dhcpv6_pd_22 Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0


    step 1. Allow the DHCPv6 client to restart DHCPv6 by waiting for the IA_PD
            lifetime to expire without replying to any DHCPv6 messages
    step 2. Send a valid Advertise message in response to the DHCPv6 client's
            Solicit message
    step 3. Verify the DHCPv6 client sends a Request message
    step 4. Send a valid Reply message with all IA lifetimes set to 0
    step 5. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 6. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 7. Verify the DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 dhcpv6-pd.tcl dhcpv6_pd_23 Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0


    step 1. Wait for DHCPv6 client's current IA_PD binding T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Send a valid Reply message with all IA lifetimes set to 0
    step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 dhcpv6-pd.tcl dhcpv6_pd_24 Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0


    step 1. Wait for DHCPv6 client's current IA_PD binding T2 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Rebind
    step 3. Send a valid Reply message with all IA lifetimes set to 0
    step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
    step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
            exchange
    step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
            a Renew at T1


    References:

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

    If the Reply message contains any IAs but the client finds no usable
    addresses and/or delegated prefixes in any of these IAs, the client
    may either try another server (perhaps restarting the DHCP server
    discovery process) or use the Information-request message to obtain
    other configuration information only.

    https://tools.ietf.org/html/rfc8415#section-18.2.10.1

Test Module Name Synopsis
Verify client sends Rebind message if Renew for prefix fails dhcpv6-pd.tcl dhcpv6_pd_30 Verify client sends Rebind message if Renew for prefix fails


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


    References:

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

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

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

Test Module Name Synopsis
Verify client sends Solicit message if Renew and Rebind for prefix fails dhcpv6-pd.tcl dhcpv6_pd_31 Verify client sends Solicit message if Renew and Rebind for prefix fails


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


    References:

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

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

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

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

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

Test Module Name Synopsis
Verify client learns new IPv6 prefix when WAN DHCPv6 server renumbers dhcpv6-pd.tcl dhcpv6_pd_60 Verify client learns new IPv6 prefix when WAN DHCPv6 server renumbers


    step 1. Change the client's DHCPv6 binding to use the new IPv6
            prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
    step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
    step 3. Verify Renew or Request contains IA_PD option (26) for
            same prefix
    step 4. Send valid DHCPv6 Reply with new prefix
    step 5. Verify client updates router advertisements on LAN with new
            prefix information
    step 6. Send pings from LAN client to an IPv6 remote host on the
            WAN to verify connectivity with new prefix
    step 7. Restore client's original prefix by repeating Steps 1
            through 5 using original IPv6 prefix
    step 8. Send pings from LAN client to an IPv6 remote host on the
            WAN to verify connectivity with original prefix


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    Upon the receipt of a valid Reply message, for each IA_PD the
    requesting router assigns a subnet from each of the delegated
    prefixes to each of the links to which the associated interfaces are
    attached, with the following exception: the requesting router MUST
    NOT assign any delegated prefixes or subnets from the delegated
    prefix(es) to the link through which it received the DHCP message
    from the delegating router.

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify LAN side DHCPv6 server switches to new IPv6 prefix when WAN DHCPv6 server renumbers dhcpv6-pd.tcl dhcpv6_pd_61 Verify LAN side DHCPv6 server switches to new IPv6 prefix when WAN DHCPv6 server renumbers


    step 1. Change the client's DHCPv6 binding to use the new IPv6
            prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
    step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
    step 3. Verify Renew or Request contains IA_PD option (26) for
            same prefix
    step 4. Send valid DHCPv6 Reply with new prefix
    step 5. Verify DHCPv6 client updates router advertisements on LAN with new
            prefix information
    step 6. Verify DHCPv6 client updates DHCPv6 server on the LAN with new
            prefix
    step 7. Send pings from LAN DHCPv6 client to an IPv6 remote host
            on the WAN to verify connectivity with new prefix
    step 8. Restore client's original prefix by repeating Steps 1
            through 6 using original IPv6 prefix
    step 9. Send pings from LAN DHCPv6 client to an IPv6 remote host
            on the WAN to verify connectivity with original prefix

    NOTE: This test only applies to configurations where LAN clients
    obtain IPv6 addresses via DHCPv6


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    Upon the receipt of a valid Reply message, for each IA_PD the
    requesting router assigns a subnet from each of the delegated
    prefixes to each of the links to which the associated interfaces are
    attached, with the following exception: the requesting router MUST
    NOT assign any delegated prefixes or subnets from the delegated
    prefix(es) to the link through which it received the DHCP message
    from the delegating router.

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify DUT ages out prefix on LAN when WAN DHCPv6 server renumbers dhcpv6-pd.tcl dhcpv6_pd_62 Verify DUT ages out prefix on LAN when WAN DHCPv6 server renumbers


    step 1. Change the DUT's WAN DHCPv6 client binding to use the new
            IPv6 prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
    step 2. Listen for router advertisements on the LAN for
            "dhcpv6IAValidLifetime" seconds and verify the following:

            a. That the original prefix is consistently aged out according to
               requirement L-13 of RFC 7084

            b. That the valid lifetime of the aged out prefix decreases over
               time (if not equal to 0)

            c. That the new prefix is consistently advertised

    step 3. Restart the LAN IPv6 client and verify that it obtains an
            address within the new prefix
    step 4. Send pings from the LAN client to an IPv6 remote host
            on the WAN to verify connectivity with the new address
    step 5. Repeat steps 1 through 4 with the original address and prefix
            specified by the testvars "dhcpv6WanAssignIp" and
            "dhcpv6WanAssignPrefix"


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Requirements

    L-13:  If the delegated prefix changes, i.e., the current prefix is
           replaced with a new prefix without any overlapping time
           period, then the IPv6 CE router MUST immediately advertise the
           old prefix with a Preferred Lifetime of zero and a Valid
           Lifetime of either a) zero or b) the lower of the current
           Valid Lifetime and two hours (which must be decremented in
           real time) in a Router Advertisement message as described in
           Section 5.5.3, (e) of [RFC4862].

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify DUT performs Duplicate Address Detection on global LAN address dhcpv6-pd.tcl dhcpv6_pd_63 Verify DUT performs Duplicate Address Detection on global LAN address


    step 1. Change the DUT's WAN DHCPv6 client binding to use the new
            IPv6 prefix specified by the testvar
            dhcpv6WanAssignNextPrefix
    step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
    step 3. Wait up to dhcpv6PDLatency + 10 seconds for a DAD-style
            Neighbor Solicitation from the DUT on the LAN
    step 4. Verify the following about the received Neighbor
            Soliciation

            a. That the target address of the Neighbor Solicitation is
               the DUT's global IPv6 LAN address in the
               dhcpv6WanAssignNextPrefix prefix

            b. That the IPv6 source address is the unspecified address

            c. That the IPv6 destination address is the solicited-node
               multicast address of the DUT's global IPv6 LAN address
               in the dhcpv6WanAssignNextPrefix prefix

    step 5. Respond to the DUT's DAD-style Neighbor Solicitation by
            sending an unsolicited Neighbor Advertisement to the
            all-nodes multicast address ff02::1 on the LAN-WAN
    step 6. Wait for 2 seconds
    step 7. Send an ICMPv6 Echo Request message to the DUT's global
            IPv6 LAN address in the dhcpv6WanAssignNextPrefix prefix
    step 8. Verify that the DUT does not send an ICMPv6 Echo Response
            message
    step 9. Change the DUT's WAN DHCPv6 client binding to use the old
            IPv6 prefix specified by the testvar dhcpv6WanAssignPrefix
    step 10. Verify DHCPv6 client sends DHCPv6 Renew or Request
    step 11. Send pings from the LAN client to to the DUT's global IPv6
             LAN address in the dhcpv6WanAssignPrefix prefix to
             verify connectivity with the new address


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection

    https://tools.ietf.org/html/rfc4862#section-5.4

Test Module Name Synopsis
Verify client attempts to learn non-temporary address and prefix in a single DHCPv6 session dhcpv6-pd.tcl dhcpv6_pd_100 Verify client attempts to learn non-temporary address and prefix in a single DHCPv6 session


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

    NOTE: IETF RFC 7084, which updates IETF RFC 6204, removed the
          above requirement.


    References:

    IETF RFC 6204 "Basic Requirements for IPv6 Customer Edge Routers" Section 4.2: WAN-Side Configuration

    W-5:  DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
          (IA_PD) SHOULD be done as a single DHCPv6 session.

    https://tools.ietf.org/html/rfc6204#section-4.2

Test Module Name Synopsis
Verify packets to unreachable subnets in the delegated prefix are dropped dhcpv6-pd.tcl dhcpv6_pd_110 Verify packets to unreachable subnets in the delegated prefix are dropped


    step 1. Build a destination IPv6 address by setting all subnet bits
    step 2. This test assumes that this address is not configured on an
            interface
    step 3. Send a UDP echo to this destination from the LAN client
    step 4. Verify the packet is not forwarded to the WAN

    Reference: IETF RFC 7084 - Basic Requirements for IPv6 Customer Edge Routers, Requirement WPD-5:



    NOTE: This test is only applicable if the delegated prefix length
    is less than 64.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    WPD-5:  Any packet received by the CE router with a destination
            address in the prefix(es) delegated to the CE router but not
            in the set of prefixes assigned by the CE router to the LAN
            must be dropped.  In other words, the next hop for the
            prefix(es) delegated to the CE router should be the null
            destination.  This is necessary to prevent forwarding loops
            when some addresses covered by the aggregate are not
            reachable [RFC4632].

            (a) The IPv6 CE router SHOULD send an ICMPv6 Destination
                Unreachable message in accordance with Section 3.1 of
                [RFC4443] back to the source of the packet, if the
                packet is to be dropped due to this rule.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
Verify LAN side DHCPv6 client address includes SLA ID dhcpv6-pd.tcl dhcpv6_pd_120 Verify LAN side DHCPv6 client address includes SLA ID


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address on the LAN includes
            the expected SLA ID

    RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
    DUT's allow the SLA ID to be arbitrarily configured. This test
    verifies that the DUT uses the expected SLA ID. The expected SLA
    can be configured using the testvar "ipv6LanSubnetId" which must
    be a hex string with four or less characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify Route Information option is advertised for delegated prefix dhcpv6-pd.tcl dhcpv6_pd_130 Verify Route Information option is advertised for delegated prefix


    step 1. Listen for Router Advertisements on the LAN for up to one Router
            Advertisement interval
    step 2. Verify that the DUT includes a Route Information option for the
            delegated prefix configured using the testvar
            dhcpv6WanAssignPrefix


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-3:  An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) using the "Route Information Option" specified
          in Section 2.3 of [RFC4191].  This advertisement is
          independent of having or not having IPv6 connectivity on the
          WAN interface.

    https://tools.ietf.org/html/rfc7084#section-4.3


dhcpv6-s.tcl

DHCPv6 server tests for the LAN side of the router

Test Module Name Synopsis
Verify server assigns same address after client restart dhcpv6-s.tcl dhcpv6_server_1 Verify server assigns same address after client restart


    step 1. Restart DHCPv6 on LAN client without sending a Release to the server
    step 2. Verify that the server assigns an address to the client
    step 3. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server returns address within configured pool dhcpv6-s.tcl dhcpv6_server_2 Verify server returns address within configured pool


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

    Note: The DHCPv6 pool is configured using the testvars ipv6DhcpClientStart
    and ipv6DhcpClientEnd. These testvars must match the DHCPv6 pool settings on
    the DUT.


    References:

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

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

Test Module Name Synopsis
Verify server returns IP address with expected valid lifetime dhcpv6-s.tcl dhcpv6_server_3 Verify server returns IP address with expected valid lifetime


    step 1. Send DHCPv6 Release to release DHCPv6 client address on LAN
    step 2. Restart DHCPv6 client on LAN
    step 3. Verify DHCPv6 client receives an address with the expected
            valid lifetime

    Note: The testvar ipv6DhcpClientValidLifetime can be used to configure the
    expected valid lifetime, in seconds, that is used by the DUT's DHCPv6 server
    on the LAN.

    This testvar can be set to a numeric value if the valid lifetime is fixed,
    or it can be set to a value of "dynamic" if the valid lifetime varies based
    on the delegated prefix (IA_PD) received on the WAN. If set to "dynamic"
    this test will verify that the valid lifetime received on the LAN is less
    than or equal to the IA_PD valid lifetime assigned by CDRouter's DHCPv6
    server on the WAN (which is configured using the testvar dhcpv6IAValidLifetime).


    References:

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

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

Test Module Name Synopsis
Verify server assigns address to client using undefined client DUID values dhcpv6-s.tcl dhcpv6_server_5 Verify server assigns address to client using undefined client DUID values


    step 1. Release client's current DHCPv6 binding
    step 2. Configure the client to use a client DUID with unknown format
    step 3. Restart DHCPv6 on client
    step 4. Verify the client obtains an address
    step 5. Repeat Steps 1 through 4 for different unknown client DUID formats
    step 6. Release the DHCPv6 binding
    step 7. Verify that the server assigns an address to the client using the
            client's original DUID format


    References:

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

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

Test Module Name Synopsis
Verify server ignores Solicits sent to unicast address dhcpv6-s.tcl dhcpv6_server_8 Verify server ignores Solicits sent to unicast address


    step 1. Release client's current DHCPv6 binding
    step 2. Verify the DHCPv6 server reply contains a status code of 0 'Success'
    step 3. Configure LAN client to send DHCPv6 Solicit messages to server's
            unicast address
    step 4. Restart DHCPv6 on LAN client
    step 5. Verify that server does not provide an IPv6 address to the client.
    step 6. Restart DHCPv6 on LAN client using All_DHCP_Relay_Agents_and_Servers
            multicast address
    step 7. Verify that the server assigns an address to the client

    Unless otherwise specified in this document, or in a document that
    describes how IPv6 is carried over a specific type of link (for link
    types that do not support multicast), a client sends DHCP messages to
    the All_DHCP_Relay_Agents_and_Servers.


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 13: Transmission of Messages by a Client

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

Test Module Name Synopsis
Verify server provides DNS and domain information to clients dhcpv6-s.tcl dhcpv6_server_9 Verify server provides DNS and domain information to clients


    step 1. Release client's current DHCPv6 binding
    step 2. Restart DHCPv6 on client
    step 3. Verify that LAN client receives DHCPv6 DNS Recursive Name Server
            (23) option from server
    step 4. Verify the DNS server addresses provided by the DHCPv6 server. If
            the testvar ipv6DNStoLAN is set to "yes", the DNS server addresses
            provided should match the addresses of the DNS servers configured on
            the WAN. If the ipv6DNStoLAN testvar is set to "no", the LAN side
            IPv6 address of the DUT should be provided as the DNS server.
    step 5. Check if LAN client receives DHCPv6 Domain Search List (24) option
            from server


    References:

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

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

    IETF RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"

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

Test Module Name Synopsis
Verify server ignores requests with mismatched server DUID dhcpv6-s.tcl dhcpv6_server_10 Verify server ignores requests with mismatched server DUID


Description
    step 1. Modify client to use an unknown server DUID
    step 2. Restart DHCPv6 on client by sending Renew to the server
    step 3. Verify that server does not reply to Renew with unknown server DUID


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.6: Renew Message

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

Test Module Name Synopsis
Verify server ignores unknown or invalid DHCPv6 packets dhcpv6-s.tcl dhcpv6_server_11 Verify server ignores unknown or invalid DHCPv6 packets


    step 1. Build DHCPv6 packet with msg-type field set to 0
    step 2. Send packet built in Step 1 to server
    step 3. Verify that server ignores invalid DHCPv6 packet generated in Step 2
    step 4. Repeat Steps 1 through 3 using msg-types 1 through 255
    step 5. Verify server is still functioning by running test dhcpv6_server_1


    References:

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

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

Test Module Name Synopsis
Verify server assigns address when IA_NA request from client does not contain an IPv6 address dhcpv6-s.tcl dhcpv6_server_12 Verify server assigns address when IA_NA request from client does not contain an IPv6 address


    step 1. Release client's current DHCPv6 binding
    step 2. Configure client to omit address hint in DHCPv6 Request messages
    step 3. Restart DHCPv6 on client
    step 4. Verify client obtains an address
    step 5. Release client's current DHCPv6 binding
    step 6. Configure client to include address hint in DHCPv6 Request message
    step 7. Verify client obtains an address


    References:

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

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

Test Module Name Synopsis
Verify server assigns multiple addresses to client using multiple IA_NA identifiers dhcpv6-s.tcl dhcpv6_server_13 Verify server assigns multiple addresses to client using multiple IA_NA identifiers


    step 1. Configure the client to use a new IA_NA IAID
    step 2. Restart DHCPv6 on client without sending a Release to the server
    step 3. Verify that the server assigns a new address to the client
    step 4. Restore client's original IA_NA IAID
    step 5. Restart DHCPv6 on client without sending a Release to the server
    step 6. Verify that the server assigns an address to the client
    step 7. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server handles fragmented IPv6 packets dhcpv6-s.tcl dhcpv6_server_14 Verify server handles fragmented IPv6 packets


    step 1. Configure client to use a large User Class (15) option to force
            IPv6 fragmentation
    step 2. Initiate Renew for client's current IPv6 address
    step 3. Verify that server responds to Renew with valid Reply message


    References:

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

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

Test Module Name Synopsis
Verify server ignores client request with invalid UDP checksum dhcpv6-s.tcl dhcpv6_server_15 Verify server ignores client request with invalid UDP checksum


    step 1. Configure the client to send invalid UDP checksums
    step 2. Restart DHCPv6 on client without sending a Release to the server
    step 3. Verify that the server does not respond to DHCPv6 requests with bad
            UDP checksums
    step 4. Configure the client to send valid UDP checksums
    step 5. Restart DHCPv6 on the client without sending a Release to the server
    step 6. Verify that the server assigns an address to the client
    step 7. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server composes DUID correctly dhcpv6-s.tcl dhcpv6_server_16 Verify server composes DUID correctly


    step 1. Initiate a DHCPv6 Renew for the client's current IPv6 address
    step 2. Verify that the server sends a Reply
    step 3. Inspect the composition of the server DUID in Reply to ensure
            correctness


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address after DHCPv6 Request from client dhcpv6-s.tcl dhcpv6_server_20 Verify server assigns same IPv6 address after DHCPv6 Request from client


    step 1. Initiate DHCPv6 Request from the client
    step 2. Verify that the server assigns the same address to the client

    When the server receives a valid Request message, the server creates
    the bindings for that client according to the server's policy and
    configuration information and records the IAs and other information
    requested by the client.


    References:

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

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

Test Module Name Synopsis
Verify server sends UseMulticast status code when client sends a unicast Request dhcpv6-s.tcl dhcpv6_server_21 Verify server sends UseMulticast status code when client sends a unicast Request


    step 1. Initiate a DHCPv6 Request from the client using the server's unicast
            address
    step 2. Verify the that the server sends a Reply message with a status code
            of 5 'UseMulticast'

    When the server receives a Request message via unicast from a client
    to which the server has not sent a unicast option, the server
    discards the Request message and responds with a Reply message
    containing a Status Code option with the value UseMulticast, a Server
    Identifier option containing the server's DUID, the Client Identifier
    option from the client message, and no other options.


    References:

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

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

Test Module Name Synopsis
Verify server sends NotOnLink status code when client sends Request with invalid link address dhcpv6-s.tcl dhcpv6_server_22 Verify server sends NotOnLink status code when client sends Request with invalid link address


    step 1. Initiate a DHCPv6 Request from the client with an unknown
            IAID containing an unknown address, which is not
            considered "on link"
    step 2. Verify that the server sends a Reply message with a status code of
            4 'NotOnLink'

    If the server finds that the prefix on one or more IP addresses in
    any IA in the message from the client is not appropriate for the link
    to which the client is connected, the server MUST return the IA to
    the client with a Status Code option with the value NotOnLink.


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address after DHCPv6 Confirm from client dhcpv6-s.tcl dhcpv6_server_30 Verify server assigns same IPv6 address after DHCPv6 Confirm from client


    step 1. Initiate a DHCPv6 Confirm from the client
    step 2. Verify that the server Reply contains a status code of 0 'success'


    References:

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

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

Test Module Name Synopsis
Verify server sends NotOnLink status code when client sends Confirm with invalid link address dhcpv6-s.tcl dhcpv6_server_31 Verify server sends NotOnLink status code when client sends Confirm with invalid link address


    step 1. Initiate a DHCPv6 Confirm from the client with an unknown
            IAID containing an unknown address, which is not
            considered "on link"
    step 2. Verify that the server sends a Reply message with a status code of
            4 'NotOnLink'

    When the server receives a Confirm message, the server determines
    whether the addresses in the Confirm message are appropriate for the
    link to which the client is attached.  If all of the addresses in the
    Confirm message pass this test, the server returns a status of
    Success.  If any of the addresses do not pass this test, the server
    returns a status of NotOnLink.  If the server is unable to perform
    this test (for example, the server does not have information about
    prefixes on the link to which the client is connected), or there were
    no addresses in any of the IAs sent by the client, the server MUST
    NOT send a reply to the client.


    References:

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

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

Test Module Name Synopsis
Verify server silently discards client Confirm messages that do not contain any addresses dhcpv6-s.tcl dhcpv6_server_32 Verify server silently discards client Confirm messages that do not contain any addresses


    step 1. Initiate a DHCPv6 Confirm from the client with an unknown IAID
            containing no addresses
    step 2. Verify that the server does not send a Reply message

    When the server receives a Confirm message, the server determines
    whether the addresses in the Confirm message are appropriate for the
    link to which the client is attached.  If all of the addresses in the
    Confirm message pass this test, the server returns a status of
    Success.  If any of the addresses do not pass this test, the server
    returns a status of NotOnLink.  If the server is unable to perform
    this test (for example, the server does not have information about
    prefixes on the link to which the client is connected), or there were
    no addresses in any of the IAs sent by the client, the server MUST
    NOT send a reply to the client.


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address after DHCPv6 Renew from client dhcpv6-s.tcl dhcpv6_server_40 Verify server assigns same IPv6 address after DHCPv6 Renew from client


    step 1. Initiate DHCPv6 Renew for the client's current IPv6 address
    step 2. Verify that the server updates the client's current IPv6 address
            binding


    References:

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

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

Test Module Name Synopsis
Verify server sends UseMulticast status code when client sends unicast Renew dhcpv6-s.tcl dhcpv6_server_41 Verify server sends UseMulticast status code when client sends unicast Renew


    step 1. Initiate DHCPv6 Renew using the server's unicast address
    step 2. Verify the that the server sends a Reply message with a status
            code of 5 'UseMulticast'

    When the server receives a Renew message via unicast from a client to
    which the server has not sent a unicast option, the server discards
    the Renew message and responds with a Reply message containing a
    Status Code option with the value UseMulticast, a Server Identifier
    option containing the server's DUID, the Client Identifier option
    from the client message, and no other options.


    References:

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

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

Test Module Name Synopsis
Verify server sends NoBinding status code when client attempts to renew unknown IAID dhcpv6-s.tcl dhcpv6_server_42 Verify server sends NoBinding status code when client attempts to renew unknown IAID


    step 1. Initiate DHCPv6 Renew with an unknown IAID that should not have a
            binding
    step 2. Verify that the server sends a Reply message with a status code of
            3 'NoBinding'

    If the server cannot find a client entry for the IA the server
    returns the IA containing no addresses with a Status Code option set
    to NoBinding in the Reply message.


    References:

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

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

Test Module Name Synopsis
Verify server sends Reply with lifetimes of 0 when client attempts to renew unknown address dhcpv6-s.tcl dhcpv6_server_43 Verify server sends Reply with lifetimes of 0 when client attempts to renew unknown address


    step 1. Initiate a DHCPv6 Renew from client with a valid IAID containing
            unknown address
    step 2. Verify that the server sends Reply message with correct IAID
    step 3. Verify Reply contains correct IA IPv6 address
    step 4. Verify Reply contains IA Preferred lifetime of 0
    step 5. Verify Reply contains IA Valid lifetime of 0
    step 6. Restart DHPCv6 on client
    step 7. Verify that the server assigns an address to the client

    If the server finds that any of the addresses are not appropriate for
    the link to which the client is attached, the server returns the
    address to the client with lifetimes of 0.


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address after DHCPv6 Rebind from client dhcpv6-s.tcl dhcpv6_server_50 Verify server assigns same IPv6 address after DHCPv6 Rebind from client


    step 1. Initiate a DHCPv6 Rebind from the client
    step 2. Verify that the server updates the client's current IPv6 address
            binding


    References:

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

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

Test Module Name Synopsis
Verify server sends Reply with lifetimes of 0 when client attempts to rebind with unknown address dhcpv6-s.tcl dhcpv6_server_52 Verify server sends Reply with lifetimes of 0 when client attempts to rebind with unknown address


    step 1. Initiate a DHCPv6 Rebind with a valid IAID containing unknown
            address
    step 2. Verify that the server sends a Reply message with correct IAID
    step 3. Verify Reply contains correct IA IPv6 address
    step 4. Verify Reply contains IA Preferred lifetime of 0
    step 5. Verify Reply contains IA Valid lifetime of 0
    step 6. Restart DHPCv6 on client
    step 7. Verify that the server assigns an address to the client

    If the server finds that any of the addresses are not appropriate for
    the link to which the client is attached, the server returns the
    address to the client with lifetimes of 0.


    References:

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

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

Test Module Name Synopsis
Verify server responds to an Information-request message from client dhcpv6-s.tcl dhcpv6_server_60 Verify server responds to an Information-request message from client


    step 1. Initiate a DHCPv6 Information-request from client
    step 2. Verify response from server


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.5: Receipt of Information-request Messages

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

Test Module Name Synopsis
Verify server assigns same IPv6 address after DHCPv6 Release from client dhcpv6-s.tcl dhcpv6_server_70 Verify server assigns same IPv6 address after DHCPv6 Release from client


    step 1. Initiate a DHCPv6 Release from the client
    step 2. Verify that the server sends a Reply message with a status code of
            0 'Success'
    step 3. Restart DHCPv6 on client
    step 4. Verify that the server assigns an address to the client


    References:

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

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

Test Module Name Synopsis
Verify server sends UseMulticast status code when clients sends unicast DHCPv6 Release dhcpv6-s.tcl dhcpv6_server_71 Verify server sends UseMulticast status code when clients sends unicast DHCPv6 Release


    step 1. Initiate a DHCPv6 Release from the client using the server's unicast
            address
    step 2. Verify the that the server sends a Reply message with a status code
            of 5 'UseMulticast'
    step 3. Restart DHCPv6 on client
    step 4. Verify that the server assigns an address to the client

    When the server receives a Release message via unicast from a client
    to which the server has not sent a unicast option, the server
    discards the Release message and responds with a Reply message
    containing a Status Code option with value UseMulticast, a Server
    Identifier option containing the server's DUID, the Client Identifier
    option from the client message, and no other options.


    References:

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

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

Test Module Name Synopsis
Verify server sends NoBinding status code when client attempts to release unknown IAID dhcpv6-s.tcl dhcpv6_server_72 Verify server sends NoBinding status code when client attempts to release unknown IAID


    step 1. Initiate DHCPv6 Release with an unknown IAID that should not have a
            binding
    step 2. Verify that the server sends a Reply message with a status code of
            3 'NoBinding'

    For each IA in the Release message for which the server has no binding information,
    the serve adds an IA option using the IAID from the Release message, an includes a
    Status Code option with the value NoBinding in the IA option.  No other options are
    included in the IA option.


    References:

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

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

Test Module Name Synopsis
Verify server assigns IPv6 address after DHCPv6 Decline from client dhcpv6-s.tcl dhcpv6_server_80 Verify server assigns IPv6 address after DHCPv6 Decline from client


    step 1. Initiate a DHCPv6 Decline for the client's current IPv6 address
    step 2. Verify that the server sends a Reply message with status code of 0
            'Success'
    step 3. Restart DHCPv6 on client with a sending a Release to the server
    step 4. Verify that the server assigns an address to client
    step 5. Verify that the address assigned by the server is not the same as
            the client's original address


    References:

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

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

Test Module Name Synopsis
Verify server sends UseMulticast status code when client sends unicast DHCPv6 Decline dhcpv6-s.tcl dhcpv6_server_81 Verify server sends UseMulticast status code when client sends unicast DHCPv6 Decline


    step 1. Initiate a DHCPv6 Decline from the client using the server's unicast
            address
    step 2. Verify the that the server sends a Reply message with a status code
            of 5 'UseMulticast'
    step 3. Restart DHCPv6 on LAN interface without sending a Release to the
            server
    step 4. Verify that the server assigns an address to the client
    step 5. Verify that the address assigned by the server is the same as the
            client's original address

    When the server receives a Decline message via unicast from a client
    to which the server has not sent a unicast option, the server
    discards the Decline message and responds with a Reply message
    containing a Status Code option with the value UseMulticast, a Server
    Identifier option containing the server's DUID, the Client Identifier
    option from the client message, and no other options.


    References:

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

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

Test Module Name Synopsis
Verify server sends NoBinding status code when client attempts to decline unknown IAID dhcpv6-s.tcl dhcpv6_server_82 Verify server sends NoBinding status code when client attempts to decline unknown IAID


    step 1. Initiate DHCPv6 Decline with an unknown IAID that should not have a
            binding
    step 2. Verify that the server sends a Reply message with a status code of 3
            'NoBinding'

    For each IA in the Decline message for which the server has no binding information,
    the server adds an IA option using the IAID from the Release message and includes a
    Status Code option with the value NoBinding in the IA option.  No other options are
    included in the IA option.


    References:

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

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

Test Module Name Synopsis
Verify server assigns IPv6 address when client uses unknown DHCPv6 options dhcpv6-s.tcl dhcpv6_server_100 Verify server assigns IPv6 address when client uses unknown DHCPv6 options


    step 1. Configure client to use unknown DHCPv6 option
    step 2. Restart DHCPv6 on LAN client without sending a Release to the server
    step 3. Verify that the server assigns an address to the client
    step 4. Verify that the address assigned by the server is the same as the
            client's original address

    Note: To ensure compatibility with future client implemenations that may
    support yet to be defined DHCPv6 options, servers should ignore any options
    that are unknown.


    References:

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

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

Test Module Name Synopsis
Verify server ignores client requests with invalid option length dhcpv6-s.tcl dhcpv6_server_101 Verify server ignores client requests with invalid option length


    step 1. Configure client to use invalid DHCPv6 option length
    step 2. Restart DHCPv6 on LAN client without sending a Release to the server
    step 3. Verify that the server does not assign an address to the client
    step 4. Configure client to use valid DHCPv6 option length
    step 5. Restart DHCPv6 on LAN client without sending a Release to the server
    step 6. Verify that the server assigns an address to the client
    step 7. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server supports Rapid Commit option dhcpv6-s.tcl dhcpv6_server_102 Verify server supports Rapid Commit option


    step 1. Configure the client to request DHCPv6 option 14 'Rapid Commit'
    step 2. Restart DHCPv6 on the client
    step 3. Verify that DHCPv6 server responds with Reply message containing the
           'Rapid Commit' option
    step 4. Verify that the server assigns an address to the client
    step 5. Verify that the address assigned by the server is the same as the
            client's original address

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

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


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address when client requests both IA_NA and IA_PD dhcpv6-s.tcl dhcpv6_server_110 Verify server assigns same IPv6 address when client requests both IA_NA and IA_PD


    step 1. Configure client to request both IA_NA and IA_PD options
    step 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the server
    step 3. Verify that the server assigns an address to the client
    step 4. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server assigns same IPv6 address when client requests both IA_NA and IA_TA dhcpv6-s.tcl dhcpv6_server_111 Verify server assigns same IPv6 address when client requests both IA_NA and IA_TA


    step 1. Configure client to request both IA_NA and IA_TA options
    step 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the server
    step 3. Verify that the server assigns an address to the client
    step 4. Verify that the address assigned by the server is the same as the
            client's original address


    References:

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

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

Test Module Name Synopsis
Verify server responds to Relay-Forward requests sent to the All_DHCP_Servers multicast address dhcpv6-s.tcl dhcpv6_server_120 Verify server responds to Relay-Forward requests sent to the All_DHCP_Servers multicast address


    step 1. Configure a relay agent on the LAN to send to DHCPv6 messages to the
            All_DHCP_Servers multicast address
    step 2. Restart DHCPv6 on the client without sending a Release to the server
    step 3. Verify that the server assigns an address to the client

    The relay agent MAY be configured to use a list of destination
    addresses, which MAY include unicast addresses, the All_DHCP_Servers
    multicast address, or other addresses selected by the network
    administrator.


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 20: Relay Agent Behavior

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

Test Module Name Synopsis
Verify server responds to Relay-Forward requests sent to server unicast address dhcpv6-s.tcl dhcpv6_server_121 Verify server responds to Relay-Forward requests sent to server unicast address


    step 1. Configure a relay agent on the LAN to send DHCPv6 messages to the
            server's global unicast address
    step 2. Restart DHCPv6 on the client without sending a Release to the server
    step 3. Verify that the server assigns an address to the client

    The relay agent MAY be configured to use a list of destination
    addresses, which MAY include unicast addresses, the All_DHCP_Servers
    multicast address, or other addresses selected by the network
    administrator.


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 20: Relay Agent Behavior

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

Test Module Name Synopsis
Verify server includes Interface-Id option in Relay-Reply if included by relay agent dhcpv6-s.tcl dhcpv6_server_122 Verify server includes Interface-Id option in Relay-Reply if included by relay agent


    step 1. Configure a relay agent on the LAN to send DHCPv6 messages to the
            server's global unicast address
    step 2. Configure a relay agent to include the Interface-Id (18) option in
            Relay-Forward messages
    step 3. Restart DHCPv6 on the client without sending a Release to the server
    step 4. Verify that the server sends a Relay-Reply message to the relay
            agent
    step 5. Verify that the Relay-Reply message includes the original
            Interface-Id (18) option value included by the relay agent
    step 6. Wait for DHCPv6 transaction to complete

    Reference: IETF RFC 3315 Section 22.18 "Interface-Id Option"

    The server MUST copy the Interface-Id option from the Relay-Forward
    message into the Relay-Reply message the server sends to the relay
    agent in response to the Relay-Forward message.  This option MUST NOT
    appear in any message except a Relay-Forward or Relay-Reply message.


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.18: Interface-Id Option

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


pppoe-c-v6.tcl

PPPoE client tests with IPv6 on the WAN side of the router

Test Module Name Synopsis
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail pppoe-c-v6.tcl ipv6_pppoe_client_1 PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail


    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 upto 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:

    testvar pppFailUsesICMP yes


Test Module Name Synopsis
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link pppoe-c-v6.tcl ipv6_pppoe_client_10 PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link


    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).


Test Module Name Synopsis
PPPoE PPP client replies to LCP Echo-Requests pppoe-c-v6.tcl ipv6_pppoe_client_50 PPPoE PPP client replies to LCP Echo-Requests


    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


Test Module Name Synopsis
PPPoE PPP client maintains LCP Magic Number during session pppoe-c-v6.tcl ipv6_pppoe_client_60 PPPoE PPP client maintains LCP Magic Number during session


    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

Test Module Name Synopsis
IPv6CP Configure-Requests include Interface Identifier option pppoe-c-v6.tcl ipv6_pppoe_client_70 IPv6CP Configure-Requests include Interface Identifier option


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Interface Identifier in IPv6CP Configure Request
    step 3. Verify PPPoE link is reestablished


    References:

    IETF RFC 5072 "IP Version 6 over PPP" Section 5: Stateless Autoconfiguration and Link-Local Addresses

    The interface identifier of IPv6 unicast addresses [5] of a PPP
    interface SHOULD be negotiated in the IPV6CP phase of the PPP
    connection setup (see Section 4.1).

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

Test Module Name Synopsis
PPPoE/PPP restarts if PPP authentication fails pppoe-c-v6.tcl ipv6_pppoe_client_200 PPPoE/PPP restarts if PPP authentication fails


    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).


Test Module Name Synopsis
PPPoE/PPP can recover if LCP renegotiation is attempted pppoe-c-v6.tcl ipv6_pppoe_client_210 PPPoE/PPP can recover if LCP renegotiation is attempted


    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).


Test Module Name Synopsis
PPPoE/PPP can recover if LCP Echo-Request contains bad length pppoe-c-v6.tcl ipv6_pppoe_client_230 PPPoE/PPP can recover if LCP Echo-Request contains bad length


    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.


Test Module Name Synopsis
PPPoE client recovers if PPPoE server drops PADR from PPPoE client pppoe-c-v6.tcl ipv6_pppoe_client_300 PPPoE client recovers if PPPoE server drops PADR from PPPoE client


    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

Test Module Name Synopsis
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO pppoe-c-v6.tcl ipv6_pppoe_client_310 PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO


    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

Test Module Name Synopsis
PPPoE client maintains Relay-Session-Id during PPPoE session establishment pppoe-c-v6.tcl ipv6_pppoe_client_320 PPPoE client maintains Relay-Session-Id during PPPoE session establishment


    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


slaac-wan.tcl

Autoconf / SLAAC client tests for the WAN side of the router

Test Module Name Synopsis
Verify DUT configures a new address using SLAAC when a new prefix is advertised on the WAN slaac-wan.tcl ipv6_slaac_wan_1 Verify DUT configures a new address using SLAAC when a new prefix is advertised on the WAN


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix
    step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
            WAN
    step 3. Verify that the target address in the Neighbor Solicitation is
            based on the new prefix
    step 4. Wait 10 seconds for the DUT to configure the new target address
    step 5. Send 10 pings to verify that the DUT has configured the new target
            address


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify DUT sends DAD-style Neighbor Solicitations when configuring an address slaac-wan.tcl ipv6_slaac_wan_10 Verify DUT sends DAD-style Neighbor Solicitations when configuring an address


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix
    step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
            WAN
    step 3. Verify that the target address in the Neighbor Solicitation is
            based on the new prefix
    step 4. Verify that the source address of the Neighbor Solicitation is the
            unspecified address
    step 5. Verify that the destination address of the Neighbor Solicitation is
            a solicited-node multicast address based on the target address in
            step 3


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify DUT does not configure an address when a DAD collision occurs slaac-wan.tcl ipv6_slaac_wan_11 Verify DUT does not configure an address when a DAD collision occurs


    step 1. Send a Router Advertisement on the WAN that advertises a new prefix
    step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
            WAN
    step 3. Force a DAD collision by sending a Neighbor Advertisement for the
            target address used by the DUT in step 2
    step 4. Wait 10 seconds
    step 5. Verify that the DUT does not configure the target address by
            sending a Neighbor Solicitation


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations for new configured address on WAN slaac-wan.tcl ipv6_slaac_wan_12 Verify DUT responds to Neighbor Solicitations for new configured address on WAN


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix
    step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
            WAN
    step 3. Verify that the target address in the Neighbor Solicitation is
            based on the new prefix
    step 4. Wait 10 seconds
    step 5. Run test ipv6_ndp_wan_11 to verify that the DUT has configured
            and responds to Neighbor Solicitations for the newly configured
            target address


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify DUT responds to DAD-style Neighbor Solicitations for new configured address on WAN slaac-wan.tcl ipv6_slaac_wan_13 Verify DUT responds to DAD-style Neighbor Solicitations for new configured address on WAN


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix
    step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
            WAN
    step 3. Verify that the target address in the Neighbor Solicitation is
            based on the new prefix
    step 4. Wait 10 seconds
    step 5. Run test ipv6_ndp_wan_16 to verify that the DUT has configured
            and responds to DAD-style Neighbor Solicitations for the newly
            configured target address


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify DUT does not configure an address when the A-bit is not set slaac-wan.tcl ipv6_slaac_wan_20 Verify DUT does not configure an address when the A-bit is not set


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix with the A-bit not set
    step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
            on the WAN for the prefix advertised in step 1


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing

    For each Prefix-Information option in the Router Advertisement:

     a)  If the Autonomous flag is not set, silently ignore the Prefix
         Information option.

    https://tools.ietf.org/html/rfc4862#section-5.5.3

Test Module Name Synopsis
Verify DUT does not configure an address when the advertised prefix is a link-local prefix slaac-wan.tcl ipv6_slaac_wan_21 Verify DUT does not configure an address when the advertised prefix is a link-local prefix


    step 1. Send a Router Advertisement on the WAN that advertises a
            link-local prefix
    step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
            on the WAN for the prefix advertised in step 1


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing

    For each Prefix-Information option in the Router Advertisement:

     b)  If the prefix is the link-local prefix, silently ignore the
         Prefix Information option.

    https://tools.ietf.org/html/rfc4862#section-5.5.3

Test Module Name Synopsis
Verify DUT does not configure an address when the valid lifetime is 0 slaac-wan.tcl ipv6_slaac_wan_22 Verify DUT does not configure an address when the valid lifetime is 0


    step 1. Send a Router Advertisement on the WAN that advertises a new
            global prefix with a valid-lifetime of 0
    step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
            on the WAN for the prefix advertised in step 1


    References:

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing

    For each Prefix-Information option in the Router Advertisement:

     c)  If the preferred lifetime is greater than the valid lifetime,
         silently ignore the Prefix Information option.  A node MAY wish to
         log a system management error in this case.

    https://tools.ietf.org/html/rfc4862#section-5.5.3


6to4.tcl

6to4 tunnel tests for connecting IPv6 hosts over IPv4 networks

Test Module Name Synopsis
Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN 6to4.tcl ipv6_6to4_1 Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6to4 prefix based on public IPv4 WAN
    step 3. Verify 6to4 prefix contains a valid lifetime


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify DUT assigns itself a global address on the LAN side 6to4 network 6to4.tcl ipv6_6to4_2 Verify DUT assigns itself a global address on the LAN side 6to4 network


    step 1. Determine the DUT's LAN side IPv6 global address
    step 2. Send ICMPv6 Echo Request to the DUT's global IPv6 address
    step 3. Verify ICMPv6 Echo Response is received from the global IPv6 address


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify IPv6 Router Advertisements include SLA ID 6to4.tcl ipv6_6to4_3 Verify IPv6 Router Advertisements include SLA ID


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6to4 prefix based on public IPv4 WAN
    step 3. Verify advertised 6to4 prefix includes the expected SLA ID

    RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most DUT's allow
    the SLA ID to be arbitrarily configured. This test verifies that the DUT
    advertises the expected SLA ID. The expected SLA can be configured using
    the testvar "ipv6LanSubnetId" which must be a hex string with four or less
    characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify packets to 6to4 addresses are tunneled directly to IPv4 address 6to4.tcl ipv6_6to4_10 Verify packets to 6to4 addresses are tunneled directly to IPv4 address


    step 1. Forward IPv6 UDP to IPv6 address on 6to4 network that maps to
            remoteHost IPv4
    step 2. Verify remoteHost IPv4 on the WAN received tunneled IPv6 packet
    step 3. Verify return IPv6 UDP traffic is forwarded back from remoteHost IPv4


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.1: Simple scenario - all sites work the same

    https://tools.ietf.org/html/rfc3056#section-5.1

Test Module Name Synopsis
Verify packets to non 6to4 addresses are tunneled to 6to4 relay server 6to4.tcl ipv6_6to4_11 Verify packets to non 6to4 addresses are tunneled to 6to4 relay server


    step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 network
    step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
    step 3. Verify return IPv6 UDP traffic is forwarded back from relay server


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.2: Mixed scenario with relay to native IPv6

    https://tools.ietf.org/html/rfc3056#section-5.2

Test Module Name Synopsis
Verify IPv4 src address of tunneled 6to4 packets matches WAN IPv4 address 6to4.tcl ipv6_6to4_12 Verify IPv4 src address of tunneled 6to4 packets matches WAN IPv4 address


    step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 network
    step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
    step 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
            IPv4 address


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.2: Mixed scenario with relay to native IPv6

    https://tools.ietf.org/html/rfc3056#section-5.2

Test Module Name Synopsis
Verify encapsulating IPv4 header for 6to4 has the DF flag set correctly 6to4.tcl ipv6_6to4_13 Verify encapsulating IPv4 header for 6to4 has the DF flag set correctly


    step 1. Forward IPv6 UDP to remoteHostv6 address
    step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
    step 3. Verify 'do not fragment' flag is set correctly on IPv4
            header based on the value of ipv6TunnelMtuType


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit

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

    IETF RFC 4213 "Basic Transition Mechanisms for IPv6 Hosts and Routers" Section 3.2: Tunnel MTU and Fragmentation

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

Test Module Name Synopsis
Verify DUT handles incoming 6to4 fragmented packets 6to4.tcl ipv6_6to4_14 Verify DUT handles incoming 6to4 fragmented packets


    step 1. Configure 6to4 Relay server to use an IPv4 MTU of 252
    step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP data
    step 3. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
    step 4. Send same UDP data back through 6to4 relay server
    step 5. 6to4 relay server will fragment the IPv4 packet
    step 6. Verify UDP data is sent to original IPv6 LAN client


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit

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

Test Module Name Synopsis
Verify IPv6 Router Advertisements announce new 6to4 prefix when IPv4 WAN changes 6to4.tcl ipv6_6to4_100 Verify IPv6 Router Advertisements announce new 6to4 prefix when IPv4 WAN changes


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IP address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6to4 prefix based on new public WAN IP
    step 5. Verify 6to4 prefix contains a valid lifetime
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new original IP address


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify DUT updates global IPv6 address after IPv4 WAN change 6to4.tcl ipv6_6to4_101 Verify DUT updates global IPv6 address after IPv4 WAN change


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IPv4 address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6to4 prefix based on new public WAN IPv4
    step 5. Verify 6to4 prefix contains a valid lifetime
    step 6. Ping DUT's new IPv6 global address
    step 7. Verify IPv6 ping response
    step 8. Bring down WAN link
    step 9. Bring up WAN link with new original IPv4 address


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change 6to4.tcl ipv6_6to4_102 Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IPv4 address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6to4 prefix based on new public WAN IPv4
    step 5. Verify 6to4 prefix contains a valid lifetime
    step 6. Forward IPv6 traffic from LAN to remoteHostv6
    step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 address
    step 8. Bring down WAN link
    step 9. Bring up WAN link with new original IPv4 address


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify IPv6 router advertisements age out 6to4 prefix when IPv4 WAN link is down 6to4.tcl ipv6_6to4_103 Verify IPv6 router advertisements age out 6to4 prefix when IPv4 WAN link is down


    step 1. Bring down WAN link
    step 2. Listen for IPv6 RA from DUT
    step 3. Verify either the RA does not contain previous 6to4 prefix
            or the advertised 6to4 prefix preferred lifetime is now 0
    step 4. Bring up WAN link
    step 5. Listen for IPv6 RA from DUT
    step 6. Verify the RA contains the expected 6to4 prefix


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds"

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

Test Module Name Synopsis
Verify LAN side DHCPv6 client address contains a 6to4 prefix based on IPv4 WAN 6to4.tcl ipv6_6to4_150 Verify LAN side DHCPv6 client address contains a 6to4 prefix based on IPv4 WAN


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address on the LAN contains
            a 6to4 prefix based on public IPv4 WAN


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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

Test Module Name Synopsis
Verify LAN side DHCPv6 client address contains a 6to4 prefix which includes SLA ID 6to4.tcl ipv6_6to4_160 Verify LAN side DHCPv6 client address contains a 6to4 prefix which includes SLA ID


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address on the LAN contains
            a 6to4 prefix which includes the expected SLA ID

    RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
    DUT's allow the SLA ID to be arbitrarily configured. This test
    verifies that the DUT uses the expected SLA ID. The expected SLA
    can be configured using the testvar "ipv6LanSubnetId" which must
    be a hex string with four or less characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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


6rd.tcl

6rd tunnel tests for connecting IPv6 hosts over IPv4 networks

Test Module Name Synopsis
Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN 6rd.tcl ipv6_6rd_1 Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6rd prefix based on public IPv4 WAN
    step 3. Verify 6rd prefix contains a valid lifetime


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify DUT assigns itself a global address on the LAN side 6rd network 6rd.tcl ipv6_6rd_2 Verify DUT assigns itself a global address on the LAN side 6rd network


    step 1. Determine the DUT's LAN side IPv6 global address based
    step 2. Send ICMPv6 Echo Request to the DUT's global IPv6 address
    step 3. Verify ICMPv6 Echo Response is received from the global IPv6 address


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify IPv6 Router Advertisements include subnet ID 6rd.tcl ipv6_6rd_3 Verify IPv6 Router Advertisements include subnet ID


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6rd prefix based on public IPv4 WAN
    step 3. Verify advertised 6rd prefix includes the expected subnet ID

    Note: The expected subnet ID bits can be configured using the testvar
    ipv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length string
    of hex characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify packets to 6rd addresses are tunneled directly to IPv4 address 6rd.tcl ipv6_6rd_10 Verify packets to 6rd addresses are tunneled directly to IPv4 address


    step 1. Forward IPv6 UDP to IPv6 address on 6rd network that maps to
            new WAN side IPv4 gateway based on testvar wanIspNextIp
    step 2. Verify new gateway on the WAN receives tunneled IPv6 packet
    step 3. Verify return IPv6 UDP traffic is forwarded back from new IPv4 gateway

    IPv6 communication between customer sites of a same ISP is direct
    across the ISP IPv4 infrastructure: when a CPE sees that the IPv6
    destination address of an outgoing packet starts with its own 6rd
    relay ISPv6 prefix, it takes the 32 bits that follow this prefix as
    IPv4 destination of the encapsulating packet.


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify packets to non 6rd addresses are tunneled to 6rd relay server 6rd.tcl ipv6_6rd_11 Verify packets to non 6rd addresses are tunneled to 6rd relay server


    step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd network
    step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
    step 3. Verify return IPv6 UDP traffic is forwarded back from relay server


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify IPv4 src address of tunneled 6rd packets matches WAN IPv4 address 6rd.tcl ipv6_6rd_12 Verify IPv4 src address of tunneled 6rd packets matches WAN IPv4 address


    step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd network
    step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
    step 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
            IPv4 address


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify encapsulating IPv4 header for 6rd has the DF flag set correctly 6rd.tcl ipv6_6rd_13 Verify encapsulating IPv4 header for 6rd has the DF flag set correctly


    step 1. Forward IPv6 UDP to remoteHostv6 address
    step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
    step 3. Verify 'do not fragment' flag is set correctly on IPv4
            header based on the value of ipv6TunnelMtuType


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit

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

    IETF RFC 4213 "Basic Transition Mechanisms for IPv6 Hosts and Routers" Section 3.2: Tunnel MTU and Fragmentation

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

Test Module Name Synopsis
Verify DUT handles incoming 6rd fragmented packets 6rd.tcl ipv6_6rd_14 Verify DUT handles incoming 6rd fragmented packets


    step 1. Configure 6rd Relay server to use an IPv4 MTU of 252
    step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP data
    step 3. Verify 6rd relay server on the WAN received tunneled IPv6 packet
    step 4. Send same UDP data back through 6rd relay server
    step 5. 6rd relay server will fragment the IPv4 packet
    step 6. Verify UDP data is sent to original IPv6 LAN client


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify IPv6 Router Advertisements announce new 6rd prefix when IPv4 WAN changes 6rd.tcl ipv6_6rd_100 Verify IPv6 Router Advertisements announce new 6rd prefix when IPv4 WAN changes


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IP address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6rd prefix based on new public WAN IP
    step 5. Verify 6rd prefix contains a valid lifetime
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new original IP address


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify DUT updates global IPv6 address after IPv4 WAN change 6rd.tcl ipv6_6rd_101 Verify DUT updates global IPv6 address after IPv4 WAN change


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IPv4 address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6rd prefix based on new public WAN IPv4
    step 5. Verify 6rd prefix contains a valid lifetime
    step 6. Ping DUT's new IPv6 global address
    step 7. Verify IPv6 ping response
    step 8. Bring down WAN link
    step 9. Bring up WAN link with new original IPv4 address


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change 6rd.tcl ipv6_6rd_102 Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change


    step 1. Bring down WAN link
    step 2. Bring up WAN link with new external IPv4 address
    step 3. Listen for IPv6 RA from DUT
    step 4. Verify RA contains 6rd prefix based on new public WAN IPv4
    step 5. Verify 6rd prefix contains a valid lifetime
    step 6. Forward IPv6 traffic from LAN to remoteHostv6
    step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 address
    step 8. Bring down WAN link
    step 9. Bring up WAN link with new original IPv4 address


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify IPv6 router advertisements age out 6rd prefix when IPv4 WAN link is down 6rd.tcl ipv6_6rd_103 Verify IPv6 router advertisements age out 6rd prefix when IPv4 WAN link is down


    step 1. Bring down WAN link
    step 2. Listen for IPv6 RA from DUT
    step 3. Verify either the RA does not contain previous 6rd prefix
            or the advertised 6rd prefix preferred lifetime is now 0
    step 4. Bring up WAN link
    step 5. Listen for IPv6 RA from DUT
    step 6. Verify the RA contains the expected 6rd prefix


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify LAN side DHCPv6 client address contains a 6rd prefix based on IPv4 WAN 6rd.tcl ipv6_6rd_150 Verify LAN side DHCPv6 client address contains a 6rd prefix based on IPv4 WAN


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address on the LAN contains
            a 6rd prefix based on public IPv4 WAN


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

Test Module Name Synopsis
Verify LAN side DHCPv6 client address contains a 6rd prefix which includes SLA ID 6rd.tcl ipv6_6rd_160 Verify LAN side DHCPv6 client address contains a 6rd prefix which includes SLA ID


    step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
    step 2. Verify whether or not a non-temporary address binding exists
    step 3. Verify that the non-temporary address on the LAN contains
            a 6rd prefix which includes the expected SLA ID

    RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
    DUT's allow the SLA ID to be arbitrarily configured. This test
    verifies that the DUT uses the expected SLA ID. The expected SLA
    can be configured using the testvar "ipv6LanSubnetId" which must
    be a hex string with four or less characters. Examples:

    testvar ipv6LanSubnetId ffff
    testvar ipv6LanSubnetId 1


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

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

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

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


icmp-v6.tcl

ICMPv6 tests for baseline ICMPv6 not including Neighbor Discovery

Test Module Name Synopsis
Verify ICMPv6 Echo Requests work through DUT icmp-v6.tcl icmpv6_1 Verify ICMPv6 Echo Requests work through DUT


    step 1. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify ICMPv6 Echo Requests from multiple LAN clients work through DUT icmp-v6.tcl icmpv6_2 Verify ICMPv6 Echo Requests from multiple LAN clients work through DUT


    step 1. Configure additional lan host
    step 2. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 1
    step 3. Verify ICMPv6 Echo Reply is received
    step 4. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 2
    step 5. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to its global IPv6 address from LAN icmp-v6.tcl icmpv6_3 Verify DUT responds to ICMPv6 Echo Requests to its global IPv6 address from LAN


    step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's global IPv6 address
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to its link-local address icmp-v6.tcl icmpv6_4 Verify DUT responds to ICMPv6 Echo Requests to its link-local address


    step 1. Initiate an outbound ICMPv6 Echo Request to the router's LAN side link-local address
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify ICMPv6 Echo Requests to DUT's global IPv6 address behave as expected icmp-v6.tcl icmpv6_5 Verify ICMPv6 Echo Requests to DUT’s global IPv6 address behave as expected


    step 1. Determine expected DUT global address
    step 2. Initiate an outbound ICMPv6 Echo Request to the DUT's global address from the LAN
    step 3. Verify response is received
    step 4. Initiate an inbound ICMPv6 Echo Request to the DUT's global address from the WAN
    step 5. Verify the device behaves as expected.

    NOTE: the testvar ipv6WanPingRespond is used to determine if pinging the
          WAN-side of the DUT is expected to work or not.  It defaults to "no"
          which signifies that the device will not respond to IPv6 pings on its
          WAN interface.


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Routers multicast group icmp-v6.tcl icmpv6_6 Verify DUT responds to ICMPv6 Echo Requests sent to the All-Routers multicast group


    step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the link-local IPv6 address
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a global prefix icmp-v6.tcl icmpv6_7 Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a global prefix


    step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the global-prefix
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Nodes group from a link-local address icmp-v6.tcl icmpv6_8 Verify DUT responds to ICMPv6 Echo Requests sent to the All-Nodes group from a link-local address


    step 1. Send an ICMPv6 Echo Request from the LAN to the All-Nodes Multicast group (ff02::1)
    step 2. Wait for an ICMPv6 Echo Response
    step 3. Verify the Echo Response is from the DUT
    step 4. Continue waiting until the DUT responds, or timeout


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to the All-Nodes group from a global IPv6 address icmp-v6.tcl icmpv6_9 Verify DUT responds to ICMPv6 Echo Requests to the All-Nodes group from a global IPv6 address


    step 1. Send an ICMPv6 Echo Request from the LAN to the All-Nodes Multicast group (ff02::1)
    step 2. Wait for an ICMPv6 Echo Response
    step 3. Verify the Echo Response is from the DUT
    step 4. Continue waiting until the DUT responds, or timeout


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on LAN icmp-v6.tcl icmpv6_10 Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on LAN


    step 1. Set the IPv6 Hop Limit of outbound packets on the LAN to 0
    step 2. Forward an IPv6 packet from a LAN client to the IPv6 WAN remote host
    step 3. Verify that the DUT does not forward the IPv6 packet to the IPv6 WAN
            remote host
    step 4. Verify that the DUT sends an ICMPv6 Time Exceeded packet to the LAN
            client
    step 5. Verify the ICMPv6 Time Exceeded packet contains the IPv6 header of
            the original packet
    step 6. Repeat steps 1 through 4 using an IPv6 Hop Limit of 1

    Note: This test is similar to icmpv6_32. The primary difference is that
    icmpv6_32 verifies that the DUT sends an ICMPv6 Time Exceeded when it
    receives a packet with a Hop Limit of 0 or 1 on the WAN side while this test
    verifies that the DUT sends an ICMPv6 Time Exceeded when it receives a
    packet with a Hop Limit of 0 or 1 on the LAN side.


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.3: Time Exceeded Message

    If a router receives a packet with a Hop Limit of zero, or if a
    router decrements a packet's Hop Limit to zero, it MUST discard the
    packet and originate an ICMPv6 Time Exceeded message with Code 0 to
    the source of the packet.  This indicates either a routing loop or
    too small an initial Hop Limit value.

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

Test Module Name Synopsis
Verify DUT forwards inbound ICMPv6 Time Exceeded icmp-v6.tcl icmpv6_11 Verify DUT forwards inbound ICMPv6 Time Exceeded


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMPv6 Time Exceeded packet with original UDP packet as data
    step 4. Verify ICMPv6 Time Exceeded packet is received by LAN host
    step 5. Verify the contents of the original IP packet included
            in the ICMPv6 Time Exceeded packet


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT forwards inbound ICMPv6 Destination Unreachable icmp-v6.tcl icmpv6_12 Verify DUT forwards inbound ICMPv6 Destination Unreachable


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMPv6 Destination Unreachable packet with original UDP packet as data
    step 4. Verify ICMPv6 Destination Unreachable is received by LAN host
    step 5. Verify the contents of the original IPv6 packet included
            in the ICMPv6 Destination Unreachable packet


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT forwards inbound ICMPv6 Packet Too Big messages icmp-v6.tcl icmpv6_13 Verify DUT forwards inbound ICMPv6 Packet Too Big messages


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMPv6 Packet Too Big packet with MTU size 1280
    step 4. Verify ICMPv6 Packet Too Big is received by LAN host
    step 5. Verify the received MTU in Packet Too Big message is unchanged


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT forwards inbound ICMPv6 Parameter Problem icmp-v6.tcl icmpv6_14 Verify DUT forwards inbound ICMPv6 Parameter Problem


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMPv6 Parameter Problem packet with pointer value of 40
    step 4. Verify ICMPv6 Parameter Problem is received by LAN host
    step 5. Verify the pointer value is unchanged
    step 6. Verify the contents of the include IPv6 packet in the ICMPv6 packet


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

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

Test Module Name Synopsis
Verify DUT supports Path MTU Discovery over WAN interface icmp-v6.tcl icmpv6_20 Verify DUT supports Path MTU Discovery over WAN interface


    step 1. Send 1500 byte UDP packet
    step 2. Check for an ICMPv6 Packet Too Big packet with code = 0
    step 3. Repeat process 2 more times until an ICMPv6 Packet Too Big
            is received, or all 3 packets are sent
    step 4. If an ICMPv6 Packet Too Big packet was sent, verify that
            the code value is 0 and verify the MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMPv6 Packet Too Big packet is sent
    step 6. When a packet size is found that does not generate an
            ICMPv6 Packet Too Big message,verify packets can be
            forwarded using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMPv6 Packet Too Big packet

    NOTE: This test starts with an initial MTU of 1500. If the WAN interface
          already supports this MTU (DHCP), then this test will pass without
          exercising the real part of Path MTU Discovery.

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


    References:

    IETF RFC 1981 "Path MTU Discovery for IP version 6"

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

Test Module Name Synopsis
Verify Path MTU value is consistent with Router Advertisement MTU value icmp-v6.tcl icmpv6_30 Verify Path MTU value is consistent with Router Advertisement MTU value


    step 1. Send a Router Solicitation from LAN side
    step 2. Verify a Router Advertisement with an MTU option is
            received on LAN side
    step 3. Send 1500 byte UDP packet
    step 4. Check for an ICMPv6 Packet Too Big packet
    step 5. Repeat process 2 more times until an ICMPv6 Packet Too Big
            is received, or all 3 packets are sent
    step 6. If an ICMPv6 Packet Too Big packet was sent, verify that
            the MTU value is less than or equal to the MTU option
            contained in the Router Advertisement.
    step 7. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMPv6 Packet Too Big packet is sent
    step 8. Verify the final MTU size is less than or equal to the MTU
            option contained in the Router Advertisement.

    NOTE: This test starts with an initial MTU of 1500. If the WAN interface
          already supports this MTU (DHCP), then this test will pass without
          exercising the real part of Path MTU Discovery.

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


    References:

    IETF RFC 1981 "Path MTU Discovery for IP version 6"

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

Test Module Name Synopsis
Verify Packet Too Big messages as IPv6 WAN MTU changes icmp-v6.tcl icmpv6_31 Verify Packet Too Big messages as IPv6 WAN MTU changes


    step 1. Send an ICMPv6 Router Advertisement on the WAN containing the
            current WAN IPv6 MTU.
    step 2. Send a UDP packet equal to the current WAN IPv6 MTU from a LAN
            client to a WAN server.
    step 3. Verify an ICMPv6 Packet Too Big message is not sent.
    step 4. Repeat steps 2-3 two more times.
    step 5. Send a UDP packet greater than the current WAN IPv6 MTU from a LAN
            client to a WAN server; if the LAN MTU is too small to permit this
            packet to be sent, a warning will be generated.
    step 6. Verify an ICMPv6 Packet Too Big message is sent and includes the
            current WAN IPv6 MTU.
    step 7. Repeat steps 5-6 two more times.
    step 8. Repeat steps 1-7, decrementing the current WAN IPv6 MTU by 20 on
            each iteration until the WAN IPv6 MTU falls below the minimum IPv6
            link MTU of 1280.

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


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.2: Packet Too Big Message

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

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 6.3.4: Processing Received Router Advertisements

    https://tools.ietf.org/html/rfc4861#section-6.3.4

Test Module Name Synopsis
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on WAN icmp-v6.tcl icmpv6_32 Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on WAN


    step 1. Set the IPv6 Hop Limit on the IPv6 WAN remote host to 0
    step 2. Forward an IPv6 packet from a LAN client to the IPv6 WAN remote host
    step 3. Send response from the IPv6 WAN remote host to the LAN client with
            an IPv6 Hop Limit of 0
    step 4. Verify that the DUT sends an ICMPv6 Time Exceeded packet to the IPv6
            WAN remote host
    step 5. Verify the ICMPv6 Time Exceeded packet contains the IPv6 header of
            the original packet
    step 6. Repeat steps 1 through 5 using an IPv6 Hop Limit of 1

    Note: This test is similar to icmpv6_10. The primary difference is that
    icmpv6_10 verifies that the DUT sends an ICMPv6 Time Exceeded when it
    receives a packet with a Hop Limit of 0 or 1 on the LAN side while this test
    verifies that the DUT sends an ICMPv6 Time Exceeded when it receives a
    packet with a Hop Limit of 0 or 1 on the WAN side.


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.3: Time Exceeded Message

    If a router receives a packet with a Hop Limit of zero, or if a
    router decrements a packet's Hop Limit to zero, it MUST discard the
    packet and originate an ICMPv6 Time Exceeded message with Code 0 to
    the source of the packet.  This indicates either a routing loop or
    too small an initial Hop Limit value.

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the LAN icmp-v6.tcl icmpv6_33 Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the LAN


    step 1. Determine expected DUT global address
    step 2. Initiate an inbound ICMPv6 Echo Request to the DUT's global address
            from the LAN with Hop Limit of 0
    step 3. Verify the device responds to the ICMPv6 Echo Request


    References:

    IETF RFC 8200 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format

    When forwarding, the packet is discarded if Hop Limit was zero
    when received or is decremented to zero.  A node that is the
    destination of a packet should not discard a packet with Hop Limit
    equal to zero; it should process the packet normally.

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the WAN icmp-v6.tcl icmpv6_34 Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the WAN


    step 1. Determine expected DUT global address
    step 2. Initiate an inbound ICMPv6 Echo Request to the DUT's global address
            from the WAN with Hop Limit of 0
    step 3. Verify the device behaves as expected

    Note: the testvar ipv6WanPingRespond is used to determine if pinging the WAN
    side of the DUT is expected to work or not.  It defaults to "no" which
    signifies that the device will not respond to IPv6 pings on its WAN
    interface.


    References:

    IETF RFC 8200 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format

    When forwarding, the packet is discarded if Hop Limit was zero
    when received or is decremented to zero.  A node that is the
    destination of a packet should not discard a packet with Hop Limit
    equal to zero; it should process the packet normally.

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


firewall-v6.tcl

IPv6 Firewall tests including port scans

Test Module Name Synopsis
Inbound TCP connections to public side HTTP port are blocked firewall-v6.tcl ipv6_firewall_1 Inbound TCP connections to public side HTTP port are blocked


    step 1. Initiate a WAN TCP connection to the DUT's global IPv6 address management port
    step 2. Verify the connection is not established

    NOTE: The value of the DUT's IPv6 address management port is taken
          from the default insecure management port defined as the
          first port in the value of testvar dutMgmtPort.  Please read
          the documentation for dutMgmtPort for more information about
          the default insecure management port concept and its usage.


Test Module Name Synopsis
Inbound TCP connections to LAN hosts are blocked firewall-v6.tcl ipv6_firewall_2 Inbound TCP connections to LAN hosts are blocked


    step 1. Initiate a WAN TCP connection to a LAN client address
    step 2. Verify the connection is not established


Test Module Name Synopsis
TCP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets firewall-v6.tcl ipv6_firewall_100 TCP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets


    step 1. Send TCP SYN packets from WAN to each port of the LAN Client in the port scan range
    step 2. Verify that each packet is not forwarded to the LAN IPv6 Client,
            unless the port is configured as open.

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

    testvar portScanDelay 100

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

    testvar ipv6FirewallTcpClosedPorts "2323"
    testvar ipv6FirewallTcpOpenPorts "22 443"


Test Module Name Synopsis
UDP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets firewall-v6.tcl ipv6_firewall_101 UDP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets


    step 1. Send UDP packets from WAN to each port of the LAN Client in the port scan range
    step 2. Verify that each packet is not forwarded to the LAN IPv6 Client,
            unless the port is configured as open.

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

    testvar portScanDelay 100

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

    testvar ipv6FirewallUdpClosedPorts "2323"
    testvar ipv6FirewallUdpOpenPorts "22 443"


Test Module Name Synopsis
TCP fragmentation port scan test to verify the DUT does not forward unsolicited packets firewall-v6.tcl ipv6_firewall_110 TCP fragmentation port scan test to verify the DUT does not forward unsolicited packets


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

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

    testvar portScanDelay 100

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

    testvar ipv6FirewallTcpClosedPorts "2323"
    testvar ipv6FirewallTcpOpenPorts "22 443"


Test Module Name Synopsis
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN firewall-v6.tcl ipv6_firewall_301 Verify firewall blocks/accepts piggyback TCP SYN connections from WAN


    step 1. Send a TCP SYN from LAN host to IP address on WAN
    step 2. Send a TCP SYN from the WAN host to the original LAN host
            using the same TCP source port
    step 3. If the router blocks simultaneous TCP SYNs
            (testvar 'natSimultaneousTcp' is set to no), verify the TCP
            SYN from the WAN is dropped

            OR

            If the router supports simultaneous TCP SYNs
            (testvar 'natSimultaneousTcp' is set to yes), verify the TCP
            SYN from the WAN is forwarded to the LAN

    step 4. Repeat step 1 using new TCP port numbers
    step 5. Send a TCP SYN from the WAN host to the original LAN host
            using a new TCP source port
    step 6. Verify the TCP SYN from the WAN is dropped

    NOTE: This test verifies that the firewall only allows TCP packets
    for established TCP sessions. If simultaneous TCP open is supported through
    the firewall, this test will verify that TCP SYN packets from the WAN are
    forwarded to the LAN. If simultaneous TCP open through the firewall is
    not supported, the test will verify that no TCP SYN packets are allowed
    from the WAN to the LAN for sessions that have been initiated from the LAN.

    NOTE: The testvar natSimultaneousTcp originates from IPv4 concepts. However,
    this testvar is used to indicate if this same behavior exists for IPv6.


Test Module Name Synopsis
Verify outbound packets with forbidden source addresses are not forwarded onto the WAN firewall-v6.tcl ipv6_firewall_505 Verify outbound packets with forbidden source addresses are not forwarded onto the WAN


    step 1. Configure a variety of invalid source addresses for traffic
    step 2. Send traffic with these addresses to the WAN
    step 3. Verify packets are not forwarded


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-1: Packets bearing multicast source addresses in their outer IPv6
    headers MUST NOT be forwarded or transmitted on any interface.

    REC-2: Packets bearing multicast destination addresses in their outer
    IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
    Architecture" [RFC4007]) than the configured scope boundary level of
    the gateway MUST NOT be forwarded in any direction.  The DEFAULT
    scope boundary level SHOULD be organization-local scope, and it
    SHOULD be configurable by the network administrator.

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

Test Module Name Synopsis
Verify inbound packets with forbidden source addresses are not forwarded onto the LAN firewall-v6.tcl ipv6_firewall_506 Verify inbound packets with forbidden source addresses are not forwarded onto the LAN


    Step 1. Create a new vnode on the RemoteHostv6
    Step 2. Send UDP traffic to the LAN with forbidden sources from vnode
    Step 3. Verify traffic is not forwarded onto the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-1: Packets bearing multicast source addresses in their outer IPv6
    headers MUST NOT be forwarded or transmitted on any interface.

    REC-2: Packets bearing multicast destination addresses in their outer
    IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
    Architecture" [RFC4007]) than the configured scope boundary level of
    the gateway MUST NOT be forwarded in any direction.  The DEFAULT
    scope boundary level SHOULD be organization-local scope, and it
    SHOULD be configurable by the network administrator.

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

Test Module Name Synopsis
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network firewall-v6.tcl ipv6_firewall_508 Verify outbound packets are not forwarded if the source address is not a prefix of the interior network


    step 1. Create a new LAN client
    step 2. Assign a different global prefix to the LAN
    step 3. Send traffic to the WAN from the martian source address
    step 4. Verify traffic is not forwarded


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-5: Outbound packets MUST NOT be forwarded if the source address
    in their outer IPv6 header does not have a unicast prefix configured
    for use by globally reachable nodes on the interior network.

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

Test Module Name Synopsis
Verify inbound packets are not forwarded if the source address is assigned for use on the interior network firewall-v6.tcl ipv6_firewall_509 Verify inbound packets are not forwarded if the source address is assigned for use on the interior network


    step 1. Create a new stack on the remoteHost
    step 2. Assign the stack the same global prefix as is used on the LAN
    step 3. Send traffic to the LAN from the remote stack
    step 4. Verify traffic is NOT forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-6: Inbound packets MUST NOT be forwarded if the source address in
    their outer IPv6 header has a global unicast prefix assigned for use
    by globally reachable nodes on the interior network.

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

Test Module Name Synopsis
Verify outbound packets with link local source addresses are not forwarded to the WAN firewall-v6.tcl ipv6_firewall_510 Verify outbound packets with link local source addresses are not forwarded to the WAN


    step 1. Send traffic from the LAN to the WAN with a link-local source address
    step 2. Verify traffic is not forwarded to the WAN


Test Module Name Synopsis
Verify inbound packets with link local source addresses are not forwarded to the LAN firewall-v6.tcl ipv6_firewall_511 Verify inbound packets with link local source addresses are not forwarded to the LAN


    step 1. Initiate a new UDP session with the device to allow inbound traffic
    step 2. Configure a new stack on the WAN with a link-local prefix as the source
    step 3. Send traffic from this new stack to the LAN
    step 4. Verify traffic is not forwarded to the LAN


Test Module Name Synopsis
Verify inbound IPv6 DNS queries on the WAN are not processed by DNS proxy firewall-v6.tcl ipv6_firewall_512 Verify inbound IPv6 DNS queries on the WAN are not processed by DNS proxy


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT's
            global IPv6 address
    step 2. Verify that the query is received by either the primary or backup
            DNS server on the WAN
    step 3. Verify that the DNS response is received by the LAN client
    step 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to the
            DUT's global IPv6 address
    step 5. Verify that a DNS response is not received by the remote host on the
            WAN that initiated the original request


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-8: By DEFAULT, inbound DNS queries received on exterior
    interfaces MUST NOT be processed by any integrated DNS resolving
    server.

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

Test Module Name Synopsis
Verify inbound DHCPv6 discovery packets on the WAN are not processed by DHCPv6 server firewall-v6.tcl ipv6_firewall_513 Verify inbound DHCPv6 discovery packets on the WAN are not processed by DHCPv6 server


    step 1. Start new DHCPv6 client on WAN interface
    step 2. Verify new client does not obtain an IPv6 address via DHCPv6 from
            the DUT
    step 3. Send three pings from LAN to WAN to verify that the DUT is still
            operating properly


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
    exterior interfaces MUST NOT be processed by any integrated DHCPv6
    server or relay agent.

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

Test Module Name Synopsis
Verify ICMPv6 Destination Unreachable message from WAN does not destroy UDP firewall state firewall-v6.tcl ipv6_firewall_540 Verify ICMPv6 Destination Unreachable message from WAN does not destroy UDP firewall state


    step 1. Send IPv6 UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
    step 3. Verify ICMPv6 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 IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    UDP headers that match the flow state record.

    REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a UDP flow.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Verify ICMPv6 Destination Unreachable message from WAN does not destroy TCP firewall state firewall-v6.tcl ipv6_firewall_541 Verify ICMPv6 Destination Unreachable message from WAN does not destroy TCP firewall state


    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
    step 3. Verify ICMPv6 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 IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    TCP headers that match the flow state record.

    REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a TCP flow.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Verify ICMPv6 Packet Too Big message from WAN does not destroy UDP firewall state firewall-v6.tcl ipv6_firewall_542 Verify ICMPv6 Packet Too Big message from WAN does not destroy UDP firewall state


    step 1. Send IPv6 UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
    step 3. Verify ICMPv6 Too Big 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 IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    UDP headers that match the flow state record.

    REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a UDP flow.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Verify ICMPv6 Packet Too Big message from WAN does not destroy TCP firewall state firewall-v6.tcl ipv6_firewall_543 Verify ICMPv6 Packet Too Big message from WAN does not destroy TCP firewall state


    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMPv6 Packet Too Big message from the WAN for the connection
    step 3. Verify ICMPv6 Packet Too Big 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 IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    TCP headers that match the flow state record.

    REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a TCP flow.

    https://tools.ietf.org/html/rfc6092#section-3.3.1


firewall-out-v6.tcl

IPv6 Firewall tests for limiting outbound access to services

Test Module Name Synopsis
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked firewall-out-v6.tcl ipv6_firewall_outbound_1 Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific
            TCP ports
    step 2. Send a TCP SYN packet from the LAN to each blocked port
    step 3. Verify the DUT does not forward TCP packets to any of the blocked
            ports

    The ipv6FirewallOutBlockedTcpPorts testvar is used to determine the list of
    TCP ports  that the DUT has been configured to block access to.


Test Module Name Synopsis
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked firewall-out-v6.tcl ipv6_firewall_outbound_2 Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific
            UDP ports
    step 2. Send a UDP packet from the LAN to each blocked port
    step 3. Verify the DUT does not forward UDP packets to any of the blocked
            ports

    The ipv6FirewallOutBlockedUdpPorts testvar is used to determine the list of
    UDP ports  that the DUT has been configured to block access to.


Test Module Name Synopsis
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked firewall-out-v6.tcl ipv6_firewall_outbound_3 Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific
            IP Protocol types
    step 2. Send an IP packet from the LAN to the WAN for each blocked IP
            protocol
    step 3. Verify the DUT does not forward any of the blocked IP protocols

    The ipv6FirewallOutBlockedIpProtos testvar is used to determine the list of
    IP Protocol types that the DUT has been configured to block access to.



apps-v6.tcl

Application tests for IPv6

Test Module Name Synopsis
Verify IPv6 HTTP session through the router apps-v6.tcl ipv6_app_100 Verify IPv6 HTTP session through the router


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


Test Module Name Synopsis
Verify IPv6 HTTPS session through the router apps-v6.tcl ipv6_app_110 Verify IPv6 HTTPS session through the router


    step 1. Initiate an outbound TCP connection to HTTPS server over IPv6
    step 2. Verify the TCP connection is established
    step 3. Verify the IPv6 source address on the WAN side is the LAN client's address
    step 4. Verify the TLS session is established
    step 5. Send HTTPS GET request to server
    step 6. Verify HTTPS response is received
    step 7. Close TCP connection from LAN side


Test Module Name Synopsis
Verify IPv6 DNS query through the router apps-v6.tcl ipv6_app_112 Verify IPv6 DNS query through the router


    step 1. Enable a DNS server on the IPv6 remoteHost
    step 2. Initiate an AAAA IPv6 DNS query to the IPv6 remoteHost
    step 3. Verify the query is received by the correct DNS server
            (depends on the value of dnsCaptive) on the WAN side
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.

    NOTE: If the testvar dnsCaptive is set to yes, the test will expect
    DNS queries to be sent to the original WAN side DNS servers and
    not the 3rd party DNS server.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify IPv6 FTP session through the router apps-v6.tcl ipv6_app_114 Verify IPv6 FTP session through the router


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP EPRT command using all upper case letters
    step 4. Verify router translates EPRT command using router's address
    step 5. Initiate inbound TCP connection for FTP data connection
    step 6. Verify inbound TCP connection is established
    step 7. Close both connections


    References:

    IETF RFC 2428 "FTP Extensions for IPv6 and NATs"

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

Test Module Name Synopsis
Verify IPv6 SMTP session through the router apps-v6.tcl ipv6_app_120 Verify IPv6 SMTP session through the router


    step 1. Initiate an outbound TCP connection to SMTP server
    step 2. Send email message using SMTP server
    step 3. Verify SMTP server correctly receives email message
    step 4. Close SMTP session from LAN side


    References:

    IETF RFC 821 "SIMPLE MAIL TRANSFER PROTOCOL"

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

Test Module Name Synopsis
Verify IPv6 POP3 session through the router apps-v6.tcl ipv6_app_122 Verify IPv6 POP3 session through the router


    step 1. Initiate an outbound TCP connection to POP3 server
    step 2. Retreive email messages using POP3 protocol
    step 3. Verify POP3 server correctly returns email messages
    step 4. Close POP3 session from LAN side


    References:

    IETF RFC 1939 "Post Office Protocol - Version 3"

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

Test Module Name Synopsis
Verify IPv6 TFTP session through the router apps-v6.tcl ipv6_app_124 Verify IPv6 TFTP session through the router


    step 1. Startup a TFTP server on the WAN
    step 2. Initiate an outbound TFTP connection to TFTP server from LAN
    step 3. Send TFTP GET to receive file via TFTP
    step 4. Verify TFTP server correctly returns file via TFTP
    step 5. Close TFTP session from LAN side


    References:

    IETF RFC 1350 "THE TFTP PROTOCOL (REVISION 2)"

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

Test Module Name Synopsis
Verify IPv6 NTP session through the router apps-v6.tcl ipv6_app_126 Verify IPv6 NTP session through the router


    step 1. Initiate an outbound NTP connection to NTP server
    step 2. Verify NTP request is sent to the WAN
    step 3. Verify NTP response is sent to LAN client


Test Module Name Synopsis
Verify IPv6 STUN session through the router apps-v6.tcl ipv6_app_130 Verify IPv6 STUN session through the router


    step 1. Initiate an outbound STUN Binding Request to remoteHost
    step 2. Verify STUN Binding Response is received
    step 3. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6
            address of the STUN client


    References:

    IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"

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

Test Module Name Synopsis
Verify IPv6 authenticated STUN session through the router apps-v6.tcl ipv6_app_131 Verify IPv6 authenticated STUN session through the router


    step 1. Configure STUN server and client to use authentication
    step 2. Initiate an outbound STUN Binding Request to remoteHost
    step 3. STUN server should sent back a 401 Binding Error Response
    step 4. STUN client retransmits Binding Request using message-integrity attribute
    step 5. Verify STUN Binding Response is received
    step 6. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6
            address of the STUN client


    References:

    IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"

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

Test Module Name Synopsis
Verify IPv6 L2GRE session through the router apps-v6.tcl ipv6_app_140 Verify IPv6 L2GRE session through the router


    step 1. Enable L2GRE endpoint on the LAN client
    step 2. Create a new IPv6 address on the WAN for the other L2GRE endpoint
    step 3. Initiate an ICMPv6 ping from LAN to WAN using L2GRE tunnel
    step 4. Verify the ICMPv6 is successful


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify a Multipath TCP connection can be opened (IPv6) apps-v6.tcl ipv6_mptcp_1 Verify a Multipath TCP connection can be opened (IPv6)


        step 1. Initiate MPTCP connection from LAN client to WAN server
        step 2. Verify MPTCP connection is established
        step 3. Verify MPTCP connection attributes on LAN client and
                WAN server match
        step 4. Close MPTCP connection


    References:

    IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"

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

Test Module Name Synopsis
Verify a Multipath TCP connection with two subflows can be opened (IPv6) apps-v6.tcl ipv6_mptcp_2 Verify a Multipath TCP connection with two subflows can be opened (IPv6)


        step 1. Initiate MPTCP connection from LAN client to WAN server
        step 2. Verify MPTCP connection is established
        step 3. Verify MPTCP connection attributes on LAN client and
                WAN server match
        step 4. Transmit data on MPTCP connection from LAN client
        step 5. Verify data is received by WAN server
        step 6. Initiate new MPTCP subflow on MPTCP connection from
                step 1
        step 7. Verify new MPTCP subflow is established
        step 8. Verify MPTCP subflow attributes on LAN client and WAN
                server match
        step 9. Transmit data on MPTCP connection from LAN client
        step 10. Verify data is received by WAN server
        step 11. Close MPTCP connection


    References:

    IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"

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


forward-v6.tcl

IPv6 forwarding tests with different packet sizes and directions

Test Module Name Synopsis
Verify IPv6 Hop Limit is decremented for forwarded packets forward-v6.tcl ipv6_forward_1 Verify IPv6 Hop Limit is decremented for forwarded packets

    step 1. Forward an IPv6 packet from a LAN client to the WAN
    step 2. Verify the Hop Limit of the packet is decremented by 1

    NOTE: Decremented by 1 by each node that forwards the packet.


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format

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

Test Module Name Synopsis
Verify IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 forward-v6.tcl ipv6_forward_2 Verify IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0

    step 1. Set the IPv6 Hop Limit of outbound packets to 1
    step 2. Forward an IPv6 packet from a LAN client to the WAN
    step 3. Verify the packet is not forwarded
    step 4. Repeat the test with a Hop Limit of 0

    NOTE: The packet is discarded if Hop Limit is decremented to zero.


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format

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

Test Module Name Synopsis
Verify IPv6 packet can be forwarded back through incoming LAN interface forward-v6.tcl ipv6_forward_3 Verify IPv6 packet can be forwarded back through incoming LAN interface

    step 1. Forward an IP packet from a LAN client to another LAN client
    step 2. Forward packet using router's MAC address
    step 3. Verify packet is forwarded back out the LAN interface

    NOTE: The router may send an ICMP Redirect back to the originator.


Test Module Name Synopsis
Forward IPv6 UDP packets with various packet lengths (LAN to WAN) forward-v6.tcl ipv6_forward_10 Forward IPv6 UDP packets with various packet lengths (LAN to WAN)

    step 1. Initiate an outbound UDP connection with UDP data length of 4
    step 2. Verify packets are received on the WAN interface
    step 3. Continue forwarding until the maximum unfragmented packet length is reached

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IPv4/IPv6 address. This can cause this test to fail.

    NOTE: Some routers allow static configuration of the MTU size. This may
    default to 1492 even for routers running DHCP on the WAN side.

    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


Test Module Name Synopsis
Forward IPv6 UDP packets with various packet lengths (WAN to LAN) forward-v6.tcl ipv6_forward_11 Forward IPv6 UDP packets with various packet lengths (WAN to LAN)

    step 1. Initiate an outbound UDP connection with UDP data length of 4
    step 2. Verify packet is received on the WAN interface
    step 3. Forward a return packet from the WAN to the LAN
    step 4. Verify packets are received on the LAN interface
    step 5. Continue forwarding until the maximum unfragmented packet length is reached

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IPv6/IPv6 address. This can cause this test to fail.

    NOTE: Some routers allow static configuration of the MTU size. This may
    default to 1492 even for routers running DHCP on the WAN side.

    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



jumbo-v6.tcl

Jumbo MTU IPv6 forwarding tests with different packet sizes and directions

Test Module Name Synopsis
Verify IPv6 Hop Limit is decremented for forwarded jumbo MTU packets jumbo-v6.tcl ipv6_jumbo_1 Verify IPv6 Hop Limit is decremented for forwarded jumbo MTU packets

    step 1. Forward an IPv6 packet from a LAN client to the WAN that utilizes
            the maximum supported jumbo mtu of both interfaces
    step 2. Verify the Hop Limit of the packet is decremented by 1

    NOTE: Decremented by 1 by each node that forwards the packet.

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


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: Header Format

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

Test Module Name Synopsis
Verify jumbo MTU IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 jumbo-v6.tcl ipv6_jumbo_2 Verify jumbo MTU IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0

    step 1. Set the IPv6 Hop Limit of outbound packets to 1
    step 2. Forward an IPv6 packet from a LAN client to the WAN that utilizes
            the maximum supported jumbo mtu of both interfaces
    step 3. Verify the packet is not forwarded
    step 4. Repeat the test with a Hop Limit of 0

    NOTE: The packet is discarded if Hop Limit is decremented to zero.

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


    References:

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format

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

Test Module Name Synopsis
Verify jumbo MTU IPv6 packet can be forwarded back through incoming LAN interface jumbo-v6.tcl ipv6_jumbo_3 Verify jumbo MTU IPv6 packet can be forwarded back through incoming LAN interface

    step 1. Forward an IP packet from a LAN client to another LAN client that
            utilizes the maximum supported jumbo mtu of both interfaces
    step 2. Forward packet using router's MAC address
    step 3. Verify packet is forwarded back out the LAN interface

    NOTE: The router may send an ICMP Redirect back to the originator.

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


Test Module Name Synopsis
Forward jumbo MTU IPv6 UDP packets with various packet lengths (LAN to WAN) jumbo-v6.tcl ipv6_jumbo_10 Forward jumbo MTU IPv6 UDP packets with various packet lengths (LAN to WAN)

    step 1. Initiate an outbound UDP connection with UDP packet that
            utilizes the maximum supported standard mtu of both interfaces
    step 2. Verify packets are received on the WAN interface
    step 3. Continue forwarding until the maximum unfragmented packet length is
            reached, i.e. maximum supported jumbo mtu of both interfaces

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IPv4/IPv6 address. This can cause this test to fail.

    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


Test Module Name Synopsis
Forward jumbo MTU IPv6 UDP packets with various packet lengths (WAN to LAN) jumbo-v6.tcl ipv6_jumbo_11 Forward jumbo MTU IPv6 UDP packets with various packet lengths (WAN to LAN)

    step 1. Initiate an outbound UDP connection with UDP packet that utilizes
            the maximum supported standard mtu of both interfaces
    step 2. Verify packet is received on the WAN interface
    step 3. Forward a return packet from the WAN to the LAN that utilizes the
            maximum supported standard mtu of both interfaces
    step 4. Verify packets are received on the LAN interface
    step 5. Continue forwarding until the maximum unfragmented packet length is
            reached, i.e maximum supported jumbo mtu of both interfaces

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IPv6/IPv6 address. This can cause this test to fail.

    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



scaling-v6.tcl

Scaling tests for maximum number of IPv6 clients and connections (TCP, HTTP, etc)

Test Module Name Synopsis
Verify all IPv6 clients obtain an IPv6 address via autoconf or DHCPv6 and are operational scaling-v6.tcl ipv6_scale_1 Verify all IPv6 clients obtain an IPv6 address via autoconf or DHCPv6 and are operational


    step 1. Determine the size of the LAN IPv6 address pool
    step 2. Create a new client for each available address within the pool
    step 3. Verify the client obtains an IPv6 address via autoconfiguration or DHCPv6
    step 4. Verify there are no address conflicts
    step 5. Verify each client can establish an outbound HTTP connection
    step 6. Verify each client can send/receive data over the connection
    step 7. Close each TCP connection

    NOTE: The DHCPv6 address pool size is set in your configuration file using
    the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
    remains in use through the test run for a host on the LAN side. This test
    will attempt to create clients for the pool size - 1. If you are using
    multiple LAN interfaces, the number of DHCPv6 clients from each interface
    will also be subtracted from the DHCPv6 pool size.


    References:

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

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify all IPv6 clients with multiple TCP connections scaling-v6.tcl ipv6_scale_2 Verify all IPv6 clients with multiple TCP connections


    step 1. Determine the size of the IPv6 LAN address pool
    step 2. Determine the maximum number of TCP connections to create for
            each client
    step 3. Create a new client for each available address within the pool
    step 4. Verify the client obtains an IPv6 address via autoconf or DHCPv6
    step 5. Verify there are no address conflicts
    step 6. Verify each client can establish X outbound HTTP connections to
            port 80, where X is the number of TCP connections per DHCPv6 client
            to create. Each connection is to a unique IP address.
    step 7. Verify each client can send/receive data over each connection
    step 8. Close each TCP connection

    NOTE: The DHCPv6 address pool size is set in your configuration file using
    the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
    remains in use through the test run for a host on the LAN side. This test
    will attempt to create clients for the pool size - 1. If you are using
    multiple LAN interfaces, the number of DHCPv6 clients from each interface
    will also be subtracted from the DHCPv6 pool size.

    NOTE: The maximum number of TCP connections per host is set in your
    configuration file using the testvar 'scaleTcpConnsPerHost'. If this entry
    is not included in your configuration file, it defaults to 5.


    References:

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

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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

Test Module Name Synopsis
Verify all IPv6 clients with single UDP connection scaling-v6.tcl ipv6_scale_3 Verify all IPv6 clients with single UDP connection


    step 1. Determine the size of the IPv6 LAN address pool
    step 2. Determine the maximum number of UDP connections to create for
            each DHCP client
    step 3. Create a DHCP client for each available address within the pool
    step 4. Verify each client obtains an IP address within the range
    step 5. Verify there are no address conflicts
    step 6. Verify each client can establish one outbound UDP connection
    step 7. Verify each client can send/receive data over each connection
    step 8. Release all new DHCP client leases

    NOTE: The DHCPv6 address pool size is set in your configuration file using
    the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
    remains in use through the test run for a host on the LAN side. This test
    will attempt to create clients for the pool size - 1. If you are using
    multiple LAN interfaces, the number of DHCPv6 clients from each interface
    will also be subtracted from the DHCPv6 pool size.


    References:

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

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

    IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"

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


dslite.tcl

DS-Lite tests for tunneling IPv4 over IPv6

Test Module Name Synopsis
Verify NAT is not enabled on DS-Lite B4 interface dslite.tcl dslite_1 Verify NAT is not enabled on DS-Lite B4 interface


    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 original LAN address
    step 6. Close TCP connection from LAN side


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE

    A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
    interface and a B4 interface, as the NAT function will be performed
    by the AFTR in the service provider's network.  This will avoid
    accidentally operating in a double-NAT environment.

    https://tools.ietf.org/html/rfc6333#section-4.2

Test Module Name Synopsis
Verify B4 Element announces itself as the IPv4 default gateway using DHCPv4 dslite.tcl dslite_10 Verify B4 Element announces itself as the IPv4 default gateway using DHCPv4


    step 1. Send a DHCPREQUEST for the current IP address
    step 2. Verify DHCP server sends DHCPACK
    step 3. Verify the gateway address is the router's LAN IPv4 address


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE

    A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
    interface and a B4 interface, as the NAT function will be performed
    by the AFTR in the service provider's network.  This will avoid
    accidentally operating in a double-NAT environment.

    However, it SHOULD operate its own DHCP(v4) server handing out
    [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.
    It SHOULD advertise itself as the default IPv4 router to those home
    hosts.  It SHOULD also advertise itself as a DNS server in the DHCP
    Option 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxy
    to accept DNS IPv4 requests from home hosts and send them using IPv6
    to the service provider DNS servers, as described in Section 5.5.

    https://tools.ietf.org/html/rfc6333#section-4.2

Test Module Name Synopsis
Verify B4 Element announces itself as the IPv4 DNS server using DHCPv4 dslite.tcl dslite_11 Verify B4 Element announces itself as the IPv4 DNS server using DHCPv4


    step 1. Send a DHCPREQUEST for the current IP address
    step 2. Verify DHCP server sends DHCPACK
    step 3. Verify the DNS server address is the router's LAN IPv4 address


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE

    A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
    interface and a B4 interface, as the NAT function will be performed
    by the AFTR in the service provider's network.  This will avoid
    accidentally operating in a double-NAT environment.

    However, it SHOULD operate its own DHCP(v4) server handing out
    [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.
    It SHOULD advertise itself as the default IPv4 router to those home
    hosts.  It SHOULD also advertise itself as a DNS server in the DHCP
    Option 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxy
    to accept DNS IPv4 requests from home hosts and send them using IPv6
    to the service provider DNS servers, as described in Section 5.5.

    https://tools.ietf.org/html/rfc6333#section-4.2

Test Module Name Synopsis
Verify DS-Lite packet fragmentation occurs at IPv6 layer and not the IPv4 layer dslite.tcl dslite_20 Verify DS-Lite packet fragmentation occurs at IPv6 layer and not the IPv4 layer


    step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
    step 2. Verify the packet is received on the WAN
    step 3. Verify the packet results in IPv6 fragments and no IPv4 fragments


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation

    (b)  if in the original packet header the Don't Fragment - DF  -
         bit flag is CLEAR, the tunnel entry-point node encapsulates
         the original packet, and subsequently fragments the
         resulting IPv6 tunnel packet into IPv6 fragments that do
         not exceed the Path MTU to the tunnel exit-point.

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

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly

    Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
    traffic over IPv6 will reduce the effective MTU of the datagram.
    Unfortunately, path MTU discovery [RFC1191] is not a reliable method
    to deal with this problem.

    A solution to deal with this problem is for the service provider to
    increase the MTU size of all the links between the B4 element and the
    AFTR elements by at least 40 bytes to accommodate both the IPv6
    encapsulation header and the IPv4 datagram without fragmenting the
    IPv6 packet.

    However, as not all service providers will be able to increase their
    link MTU, the B4 element MUST perform fragmentation and reassembly if
    the outgoing link MTU cannot accommodate the extra IPv6 header.  The
    original IPv4 packet is not oversized.  The packet is oversized after
    the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
    fragmented.  Fragmentation MUST happen after the encapsulation of the
    IPv6 packet.  Reassembly MUST happen before the decapsulation of the
    IPv4 packet.  A detailed procedure has been specified in [RFC2473]
    Section 7.2.

    https://tools.ietf.org/html/rfc6333#section-5.3

Test Module Name Synopsis
Verify IPv4 ICMP Unreachable is generated if DF=1 and packet would fragment dslite.tcl dslite_21 Verify IPv4 ICMP Unreachable is generated if DF=1 and packet would fragment


    step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
    step 2. Verify an ICMP unreachable with code 4 is received on the LAN


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation

    (b)  if in the original packet header the Don't Fragment - DF  -
         bit flag is CLEAR, the tunnel entry-point node encapsulates
         the original packet, and subsequently fragments the
         resulting IPv6 tunnel packet into IPv6 fragments that do
         not exceed the Path MTU to the tunnel exit-point.

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

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly

    Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
    traffic over IPv6 will reduce the effective MTU of the datagram.
    Unfortunately, path MTU discovery [RFC1191] is not a reliable method
    to deal with this problem.

    A solution to deal with this problem is for the service provider to
    increase the MTU size of all the links between the B4 element and the
    AFTR elements by at least 40 bytes to accommodate both the IPv6
    encapsulation header and the IPv4 datagram without fragmenting the
    IPv6 packet.

    However, as not all service providers will be able to increase their
    link MTU, the B4 element MUST perform fragmentation and reassembly if
    the outgoing link MTU cannot accommodate the extra IPv6 header.  The
    original IPv4 packet is not oversized.  The packet is oversized after
    the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
    fragmented.  Fragmentation MUST happen after the encapsulation of the
    IPv6 packet.  Reassembly MUST happen before the decapsulation of the
    IPv4 packet.  A detailed procedure has been specified in [RFC2473]
    Section 7.2.

    https://tools.ietf.org/html/rfc6333#section-5.3

Test Module Name Synopsis
Verify IPv4 packet is dropped if DF=1 and packet would fragment dslite.tcl dslite_22 Verify IPv4 packet is dropped if DF=1 and packet would fragment


    step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
    step 2. Verify packet is not forwarded to the WAN


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation

    (b)  if in the original packet header the Don't Fragment - DF  -
         bit flag is CLEAR, the tunnel entry-point node encapsulates
         the original packet, and subsequently fragments the
         resulting IPv6 tunnel packet into IPv6 fragments that do
         not exceed the Path MTU to the tunnel exit-point.

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

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly

    Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
    traffic over IPv6 will reduce the effective MTU of the datagram.
    Unfortunately, path MTU discovery [RFC1191] is not a reliable method
    to deal with this problem.

    A solution to deal with this problem is for the service provider to
    increase the MTU size of all the links between the B4 element and the
    AFTR elements by at least 40 bytes to accommodate both the IPv6
    encapsulation header and the IPv4 datagram without fragmenting the
    IPv6 packet.

    However, as not all service providers will be able to increase their
    link MTU, the B4 element MUST perform fragmentation and reassembly if
    the outgoing link MTU cannot accommodate the extra IPv6 header.  The
    original IPv4 packet is not oversized.  The packet is oversized after
    the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
    fragmented.  Fragmentation MUST happen after the encapsulation of the
    IPv6 packet.  Reassembly MUST happen before the decapsulation of the
    IPv4 packet.  A detailed procedure has been specified in [RFC2473]
    Section 7.2.

    https://tools.ietf.org/html/rfc6333#section-5.3

Test Module Name Synopsis
Verify DNS queries sent to router over IPv4 are forwarded to IPv6 DNS server dslite.tcl dslite_30 Verify DNS queries sent to router over IPv4 are forwarded to IPv6 DNS server


    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. The query may be received by the primary or backup DNS server
    step 4. Verify the DNS query is using IPv6 and not IPv4
    step 5. Send a return response back to LAN
    step 6. Verify the response is received by the LAN client

    NOTE: The router must support some type of DNS relay or proxy to
          pass this test case.


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.5: DNS

    A B4 element is only configured from the service provider with IPv6.
    As such, it can only learn the address of a DNS recursive server
    through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
    defines an option to get the IPv6 address of such a DNS recursive
    server, the B4 element cannot easily discover the IPv4 address of
    such a recursive DNS server, and as such will have to perform all DNS
    resolution over IPv6.

    https://tools.ietf.org/html/rfc6333#section-5.5

Test Module Name Synopsis
Verify LAN clients can reach the IPv4 address of DS-Lite AFTR dslite.tcl dslite_40 Verify LAN clients can reach the IPv4 address of DS-Lite AFTR


    step 1. Initiate an outbound ICMP Echo Request to the IPv4 address of the WAN (AFTR)
    step 2. Verify ICMP Echo Reply (ping response) is received


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 6.5: Well-Known IPv4 Address

    The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by
    IANA to configure the IPv4-in-IPv6 tunnel.  That address can then be
    used to report ICMP problems and will appear in traceroute outputs.

    The following testvars are used to configure the AFTR and B4 addresses:
        AFTR: testvar wanIspIp        192.0.0.1
          B4: testvar wanIspAssignIp  192.0.0.2

    https://tools.ietf.org/html/rfc6333#section-6.5

Test Module Name Synopsis
Verify LAN clients can reach the IPv4 address of DS-Lite B4 dslite.tcl dslite_41 Verify LAN clients can reach the IPv4 address of DS-Lite B4


    step 1. Initiate an outbound ICMP Echo Request to the IPv4 address of the CPE WAN (B4)
    step 2. Verify ICMP Echo Reply (ping response) is received


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.7: Well-Known IPv4 Address

    Any locally unique IPv4 address could be configured on the IPv4-in-
    IPv6 tunnel to represent the B4 element.  Configuring such an address
    is often necessary when the B4 element is sourcing IPv4 datagrams
    directly over the tunnel.  In order to avoid conflicts with any other
    address, IANA has defined a well-known range, 192.0.0.0/29.

    192.0.0.0 is the reserved subnet address.  192.0.0.1 is reserved for
    the AFTR element, and 192.0.0.2 is reserved for the B4 element.  If a
    service provider has a special configuration that prevents the B4
    element from using 192.0.0.2, the B4 element MAY use any other
    addresses within the 192.0.0.0/29 range.

    Note: A range of addresses has been reserved for this purpose.  The
    intent is to accommodate nodes implementing multiple B4 elements.

    The following testvars are used to configure the AFTR and B4 addresses:
        AFTR: testvar wanIspIp        192.0.0.1
          B4: testvar wanIspAssignIp  192.0.0.2

    https://tools.ietf.org/html/rfc6333#section-5.7

Test Module Name Synopsis
Verify IPv4 TOS is copied to IPv6 Traffic Class dslite.tcl dslite_42 Verify IPv4 TOS is copied to IPv6 Traffic Class


    step 1. Forward an IPv4 packet from a LAN client to the WAN with a specific TOS
    step 2. Verify the packet is received on the WAN (AFTR)
    step 3. Verify that the IPv4 TOS and IPv6 Traffic Class are set to
            the IPv4 TOS from step 1
    step 4. Forward an IPv4 packet from the WAN to a LAN client with a specific TOS
    step 5. Verify the packet is received by the LAN client
    step 6. Verify that the IPv4 TOS are set to the IPv4 TOS from step 4
    step 7. Repeat steps 1 to 7 with several different IPv4 TOS values


    References:

    IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 7.1: Tunneling

    Tunneling MUST be done in accordance to [RFC2473] and [RFC4213].
    Traffic classes ([RFC2474]) from the IPv4 headers MUST be carried
    over to the IPv6 headers and vice versa.

    https://tools.ietf.org/html/rfc6333#section-7.1


dns-v6.tcl

IPv6 DNS proxy and DNS failover related tests

Test Module Name Synopsis
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 dns-v6.tcl ipv6_dns_10 Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns-v6.tcl ipv6_dns_11 Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-v6.tcl ipv6_dns_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns-v6.tcl ipv6_dns_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response dns-v6.tcl ipv6_dns_45 Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response dns-v6.tcl ipv6_dns_46 Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns-v6.tcl ipv6_dns_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-v6.tcl ipv6_dns_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify IPv6 DNS proxy fails over when new primary DNS server is learned dns-v6.tcl ipv6_dns_60 Verify IPv6 DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.


Test Module Name Synopsis
Verify IPv6 DNS lookups with multiple IPv4 responses dns-v6.tcl ipv6_dns_70 Verify IPv6 DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy recovers after DNS server outage dns-v6.tcl ipv6_dns_100 Verify IPv6 DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify IPv6 DNS queries including the EDNS0 option dns-v6.tcl ipv6_dns_110 Verify IPv6 DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns-v6.tcl ipv6_dns_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns-v6.tcl ipv6_dns_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for TXT records dns-v6.tcl ipv6_dns_130 Verify IPv6 DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client

    Reference: RFC 1035 Domain names - implementation and specification


Test Module Name Synopsis
Verify DNS queries for CNAME records dns-v6.tcl ipv6_dns_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns-v6.tcl ipv6_dns_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns-v6.tcl ipv6_dns_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SPF records dns-v6.tcl ipv6_dns_140 Verify IPv6 DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SRV records dns-v6.tcl ipv6_dns_141 Verify IPv6 DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns-v6.tcl ipv6_dns_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to a
    value of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

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

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle DNSSEC queries dns-v6.tcl ipv6_dns_200 Verify IPv6 DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle large DNSSEC responses dns-v6.tcl ipv6_dns_201 Verify IPv6 DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

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

Test Module Name Synopsis
Verify IPv6 DNS proxy honors TTL values when caching responses dns-v6.tcl ipv6_dns_300 Verify IPv6 DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns-v6.tcl ipv6_dns_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that the last 10 hostname lookups are not cached by
            the DUT's DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns-v6.tcl ipv6_dns_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server.
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1.
    step 3. Verify that DNS responses are received for both DNS
            queries.


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns-v6.tcl ipv6_dns_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns-v6.tcl ipv6_dns_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns-v6.tcl ipv6_dns_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname    
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns-v6.tcl ipv6_dns_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using DNS over TLS


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

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


dns-tcp-v6.tcl

IPv6 DNS over TCP proxy and DNS failover related tests

Test Module Name Synopsis
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 dns-tcp-v6.tcl ipv6_dns_tcp_10 Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns-tcp-v6.tcl ipv6_dns_tcp_11 Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tcp-v6.tcl ipv6_dns_tcp_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns-tcp-v6.tcl ipv6_dns_tcp_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response dns-tcp-v6.tcl ipv6_dns_tcp_45 Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response dns-tcp-v6.tcl ipv6_dns_tcp_46 Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns-tcp-v6.tcl ipv6_dns_tcp_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tcp-v6.tcl ipv6_dns_tcp_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify IPv6 DNS proxy fails over when new primary DNS server is learned dns-tcp-v6.tcl ipv6_dns_tcp_60 Verify IPv6 DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.


Test Module Name Synopsis
Verify IPv6 DNS lookups with multiple IPv4 responses dns-tcp-v6.tcl ipv6_dns_tcp_70 Verify IPv6 DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy recovers after DNS server outage dns-tcp-v6.tcl ipv6_dns_tcp_100 Verify IPv6 DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify IPv6 DNS queries including the EDNS0 option dns-tcp-v6.tcl ipv6_dns_tcp_110 Verify IPv6 DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns-tcp-v6.tcl ipv6_dns_tcp_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup

    Reference: RFC 6891 Extension Mechanisms for DNS (EDNS0)


Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns-tcp-v6.tcl ipv6_dns_tcp_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for TXT records dns-tcp-v6.tcl ipv6_dns_tcp_130 Verify IPv6 DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify DNS queries for CNAME records dns-tcp-v6.tcl ipv6_dns_tcp_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client

    Reference: RFC 1035 Domain names - implementation and specification


Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns-tcp-v6.tcl ipv6_dns_tcp_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns-tcp-v6.tcl ipv6_dns_tcp_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SPF records dns-tcp-v6.tcl ipv6_dns_tcp_140 Verify IPv6 DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SRV records dns-tcp-v6.tcl ipv6_dns_tcp_141 Verify IPv6 DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns-tcp-v6.tcl ipv6_dns_tcp_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to av
    alue of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

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

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle DNSSEC queries dns-tcp-v6.tcl ipv6_dns_tcp_200 Verify IPv6 DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle large DNSSEC responses dns-tcp-v6.tcl ipv6_dns_tcp_201 Verify IPv6 DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

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

Test Module Name Synopsis
Verify IPv6 DNS proxy honors TTL values when caching responses dns-tcp-v6.tcl ipv6_dns_tcp_300 Verify IPv6 DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns-tcp-v6.tcl ipv6_dns_tcp_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that the last 10 hostname lookups are not cached by
            the DUT's DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns-tcp-v6.tcl ipv6_dns_tcp_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server.
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1.
    step 3. Verify that DNS responses are received for both DNS
            queries.


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns-tcp-v6.tcl ipv6_dns_tcp_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns-tcp-v6.tcl ipv6_dns_tcp_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns-tcp-v6.tcl ipv6_dns_tcp_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname    
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns-tcp-v6.tcl ipv6_dns_tcp_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using DNS over TLS


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

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


dns-tls-v6.tcl

IPv6 DNS over TLS proxy and DNS failover related tests

Test Module Name Synopsis
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 dns-tls-v6.tcl ipv6_dns_tls_10 Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns-tls-v6.tcl ipv6_dns_tls_11 Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tls-v6.tcl ipv6_dns_tls_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns-tls-v6.tcl ipv6_dns_tls_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response dns-tls-v6.tcl ipv6_dns_tls_45 Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response dns-tls-v6.tcl ipv6_dns_tls_46 Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns-tls-v6.tcl ipv6_dns_tls_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tls-v6.tcl ipv6_dns_tls_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify IPv6 DNS proxy fails over when new primary DNS server is learned dns-tls-v6.tcl ipv6_dns_tls_60 Verify IPv6 DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.


Test Module Name Synopsis
Verify IPv6 DNS lookups with multiple IPv4 responses dns-tls-v6.tcl ipv6_dns_tls_70 Verify IPv6 DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy recovers after DNS server outage dns-tls-v6.tcl ipv6_dns_tls_100 Verify IPv6 DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify IPv6 DNS queries including the EDNS0 option dns-tls-v6.tcl ipv6_dns_tls_110 Verify IPv6 DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns-tls-v6.tcl ipv6_dns_tls_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns-tls-v6.tcl ipv6_dns_tls_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for TXT records dns-tls-v6.tcl ipv6_dns_tls_130 Verify IPv6 DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client

    Reference: RFC 1035 Domain names - implementation and specification


Test Module Name Synopsis
Verify DNS queries for CNAME records dns-tls-v6.tcl ipv6_dns_tls_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns-tls-v6.tcl ipv6_dns_tls_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns-tls-v6.tcl ipv6_dns_tls_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SPF records dns-tls-v6.tcl ipv6_dns_tls_140 Verify IPv6 DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify IPv6 DNS queries for SRV records dns-tls-v6.tcl ipv6_dns_tls_141 Verify IPv6 DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns-tls-v6.tcl ipv6_dns_tls_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to av
    alue of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

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

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle DNSSEC queries dns-tls-v6.tcl ipv6_dns_tls_200 Verify IPv6 DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify IPv6 DNS proxy does not mangle large DNSSEC responses dns-tls-v6.tcl ipv6_dns_tls_201 Verify IPv6 DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

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

Test Module Name Synopsis
Verify IPv6 DNS proxy honors TTL values when caching responses dns-tls-v6.tcl ipv6_dns_tls_300 Verify IPv6 DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns-tls-v6.tcl ipv6_dns_tls_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that the last 10 hostname lookups are not cached by
            the DUT's DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns-tls-v6.tcl ipv6_dns_tls_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server.
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1.
    step 3. Verify that DNS responses are received for both DNS
            queries.


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns-tls-v6.tcl ipv6_dns_tls_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns-tls-v6.tcl ipv6_dns_tls_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns-tls-v6.tcl ipv6_dns_tls_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns-tls-v6.tcl ipv6_dns_tls_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using DNS over TLS


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

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


url-filter-v6.tcl

IPv6 URL filtering tests for LAN side HTTP clients

Test Module Name Synopsis
Verify HTTP GETs to filtered URLs over IPv6 are blocked url-filter-v6.tcl ipv6_urlfilter_10 Verify HTTP GETs to filtered URLs over IPv6 are blocked


    step 1. Set up new web server on WAN side using IPv6 free network address
    step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP GETs to filtered URLs over IPv6 are blocked without DNS lookups url-filter-v6.tcl ipv6_urlfilter_12 Verify HTTP GETs to filtered URLs over IPv6 are blocked without DNS lookups


    step 1. Set up new web server on WAN side using IPv6 free network address
    step 2. Resolve only domain IPv6 addresses for non-filtered URLs using AAAA
            lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP HEADs to filtered URLs over IPv6 are blocked url-filter-v6.tcl ipv6_urlfilter_15 Verify HTTP HEADs to filtered URLs over IPv6 are blocked


    step 1. Set up new web server on WAN side using IPv6 free network address
    step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP HEAD from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP POSTs to filtered URLs over IPv6 are blocked url-filter-v6.tcl ipv6_urlfilter_20 Verify HTTP POSTs to filtered URLs over IPv6 are blocked


    step 1. Set up new web server on WAN side using IPv6 free network address
    step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP POST from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify URL filtering over IPv6 does not look at Cookie data url-filter-v6.tcl ipv6_urlfilter_30 Verify URL filtering over IPv6 does not look at Cookie data


    step 1. Set up new web server on WAN side using IPv6 free network address
    step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. Use one of the filtered URLs as the cookie data
    step 7. Verify webserver does return a response
    step 8. Repeat for each configured allowed URL

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

Test Module Name Synopsis
Verify HTTPS GETs to filtered URLs over IPv6 are blocked url-filter-v6.tcl ipv6_urlfilter_40 Verify HTTPS GETs to filtered URLs over IPv6 are blocked


    step 1. Set up new HTTPS server on WAN side using IPv6 free network address
    step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
    step 3. Initiate IPv6 TCP connection to web server from LAN client
    step 4. If TCP connection is not established, skip to step 9
    step 5. Verify TCP connection is opened
    step 6.  Establish SSL connection to server
    step 7.  Send HTTPS GET from LAN client to new server for requested URL
    step 8.  URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 9.  Repeat for each configured filtered URL
    step 10. Verify that each configured non-filtered URL returns a valid
             webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 8, or using a proxy to return a 200 HTTP status code
    in step 8 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.


mcast-v6.tcl

MLDv1/v2 and multicast data tests for IPv6 MLD proxy

Test Module Name Synopsis
MLD packets from LAN are proxied to WAN interface mcast-v6.tcl ipv6_mcast_1 MLD packets from LAN are proxied to WAN interface


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
    step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
    step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Repeat test using an MLDv1 Leave packet or MLDv2 Memebership Report
            to leave the multicast group
    step 6. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: Some routers may send an MLD query on the LAN interface after the
    MLD Leave from the LAN client. The MLD Leave may not be sent on the
    WAN interface until the LAN side has made multiple queries.

    The amount of time this test case should wait before expecting the
    MLD Leave on the WAN interface may be configured by setting the
    testvar 'ipv6MulticastCacheTimeout'.

    Example:

    testvar ipv6MulticastCacheTimeout 30


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify IPv6 Hop-Limit is decremented for multicast packets mcast-v6.tcl ipv6_mcast_2 Verify IPv6 Hop-Limit is decremented for multicast packets


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Verify the TTL is decremented by the expected IP hop count

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The number of expected IP hops can be configured using the testvar
    'IPv6HopCount'. The default is 1 IP hop. If the device is using bridge
    mode, the expected IPv6HopCount is 0.

    NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    MLD report. The default value is 2 seconds.

    testvar ipv6MulticastJoinDelay 2

    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Forward Multicast IPv6 UDP packets with various packet lengths (LAN to WAN) mcast-v6.tcl ipv6_mcast_11 Forward Multicast IPv6 UDP packets with various packet lengths (LAN to WAN)


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the WAN interface
    step 3. Forward a multicast UDP packet from the LAN with UDP length 4
    step 4. Verify the packet is received on the WAN interface
    step 5. Repeat for all packet sizes up to the max MTU

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    MLD report. The default value is 2 seconds.

    testvar ipv6MulticastJoinDelay 2

    NOTE: If the device does not support forwarding multiast traffic
    to the WAN, this test case may be skipped by setting
    the testvar supportsIPv6MulticastOut to no.

    For example,

       testvar supportsIPv6MulticastOut no


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Forward Multicast IPv6 UDP packets with various packet lengths (WAN to LAN) mcast-v6.tcl ipv6_mcast_12 Forward Multicast IPv6 UDP packets with various packet lengths (WAN to LAN)


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Forward a multicast UDP packet from the WAN with UDP length 4
    step 4. Verify the packet is received on the LAN interface
    step 5. Repeat for all packet sizes up to the max MTU

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    MLD report. The default value is 2 seconds.

    testvar ipv6MulticastJoinDelay 2


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLD router periodically sends general MLD Query on LAN interface mcast-v6.tcl ipv6_mcast_20 Verify MLD router periodically sends general MLD Query on LAN interface


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Wait up to mldQueryInterval seconds for a general MLD Query on the LAN
    step 3. Repeat for 2 queries

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Multicast streams are not forwarded if no group members exist mcast-v6.tcl ipv6_mcast_50 Multicast streams are not forwarded if no group members exist


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Allocate a multicast group that has no members on the LAN
    step 3. Forward UDP multicast packet from WAN to LAN using group
    step 4. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Multicast streams are not forwarded after last member leaves group mcast-v6.tcl ipv6_mcast_51 Multicast streams are not forwarded after last member leaves group


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Send a MLD Leave packet on the LAN interface for group
    step 6. Wait for the multicast cache to expire
    step 7. Forward UDP multicast packet from WAN to LAN using group
    step 8. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Multicast streams are not forwarded after last member ages out mcast-v6.tcl ipv6_mcast_52 Multicast streams are not forwarded after last member ages out


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Wait for the multicast group to expire
    step 6. Forward UDP multicast packet from WAN to LAN using group
    step 7. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.

    NOTE: The amount of time it takes the multicast group to expire is
    based on the mldQueryInterval, mldRobustnessVariable, and
    mldQueryResponseInterval. These can all be configured using the
    following testvars:

      testvar mldQueryInterval 125
      testvar mldRobustnessVariable 2
      testvar mldQueryResponseInterval 10


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
MLD proxy interface answers MLD general query requests mcast-v6.tcl ipv6_mcast_53 MLD proxy interface answers MLD general query requests


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for MLD membership report on the WAN
    step 4. Issue an MLD Membership query to ff02::1 on WAN for group address ::
    step 5. Verify router's WAN side responds with MLD membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
MLD proxy interface answers MLD specific query requests mcast-v6.tcl ipv6_mcast_54 MLD proxy interface answers MLD specific query requests


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for MLD membership report on the WAN
    step 4. Issue an MLD Membership query to ff02::1 on WAN for specific group address
    step 5. Verify router's WAN side responds with MLD membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLD router sends MLD Group Specific Query after last member leaves group mcast-v6.tcl ipv6_mcast_60 Verify MLD router sends MLD Group Specific Query after last member leaves group


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
    step 3. Send an MLDv2 Leave or MLDv2 Memebership packet on the LAN interface
            to leave the multicast group
    step 4. Verify an MLDv1/2 Query packet is sent on the LAN interface
            to the specific multicast group. If mldFastLeave is set
            to yes, verify that no MLD Query is sent.

    NOTE: This test will work with a multicast proxy implementation only.

    NOTE: If the device supports MLD Fast Leave, the testvar mldFastLeave
    should be set to yes. In this case, the test case will verify that
    no group specific MLD query is sent after the MLD Leave.

    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLD router sends MLD Leave after last group member ages out mcast-v6.tcl ipv6_mcast_70 Verify MLD router sends MLD Leave after last group member ages out


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
    step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
    step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Let group member on the LAN age out. No responses will sent to MLD
            queries and no MLD Leave will be sent.
    step 6. Verify MLD leave or MLDv2 membership report is received for the group
            on the WAN interface
    step 7. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The amount of time it takes the multicast group to expire is
    based on the mldQueryInterval, mldRobustnessVariable, and
    mldQueryResponseInterval. These can all be configured using the
    following testvars:

      testvar mldQueryInterval 125
      testvar mldRobustnessVariable 2
      testvar mldQueryResponseInterval 10

    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLD router accepts reports with unspecified source address mcast-v6.tcl ipv6_mcast_80 Verify MLD router accepts reports with unspecified source address


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
            with IP src ::
    step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
    step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Repeat test using an MLDv1 Leave packet or MLDv2 Memebership Report
            to leave the multicast group
    step 6. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: Some routers may send an MLD query on the LAN interface after the
    MLD Leave from the LAN client. The MLD Leave may not be sent on the
    WAN interface until the LAN side has made multiple queries.

    The amount of time this test case should wait before expecting the
    MLD Leave on the WAN interface may be configured by setting the
    testvar 'ipv6MulticastCacheTimeout'.

    Example:

    testvar ipv6MulticastCacheTimeout 30


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify MLD snooping switch scenario with unspecified source address mcast-v6.tcl ipv6_mcast_81 Verify MLD snooping switch scenario with unspecified source address


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface with IP src ::
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Verify the TTL is decremented by the expected IP hop count

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The number of expected IP hops can be configured using the testvar
    'IPv6HopCount'. The default is 1 IP hop.

    NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    MLD report. The default value is 2 seconds.

    testvar ipv6MulticastJoinDelay 2


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify the maximum number of multicast groups received on the LAN mcast-v6.tcl ipv6_mcast_100 Verify the maximum number of multicast groups received on the LAN


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Join mldMaxGroups multicast groups on the LAN interface
    step 3. Forward a multicast UDP packet from the WAN to each group
    step 4. Verify each group is received on the LAN interface
    step 5. Send a MLD Leave for each multicast group

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: You can slow down the rate at which CDRouter will join each group
    by configuring the testvar ipv6MulticastScaleDelay. It defaults to 1
    millisecond.

    testvar ipv6MulticastScaleDelay 1

    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify IPTV channel change test scenario 1 (no overlap) mcast-v6.tcl ipv6_mcast_110 Verify IPTV channel change test scenario 1 (no overlap)


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the MLDv1 or MLDv2 report is received in the WAN
    step 5. Start sending multicast data on the WAN for the new group
    step 6. Verify the LAN side starts to receive the multicast data
    step 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
    step 8. Leave the multicast group on the LAN using MLDv1/2
    step 9. Switch to the next channel or exit if too many failures have
            occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar ipv6IptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test early if many channels start failing.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify IPTV channel change test scenario 2 (overlap) mcast-v6.tcl ipv6_mcast_120 Verify IPTV channel change test scenario 2 (overlap)


    step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
    step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the MLDv1 or MLDv2 report is received in the WAN
    step 5. Leave any previous multicast group for the last channel
    step 6. Start sending multicast data on the WAN for the new group
    step 7. Verify the LAN side starts to receive the multicast data
    step 8. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
    step 9. Switch to the next channel or exit if too many failures have occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar ipv6IptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test early if many channels start failing.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES mcast-v6.tcl ipv6_mcast_200 Verify MLDv2 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv2 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address.
    step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
    step 7. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 router blocks incoming multicast sources that do not match the source list mcast-v6.tcl ipv6_mcast_210 Verify MLDv2 router blocks incoming multicast sources that do not match the source list


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv2 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding fails from WAN to LAN for new group using
            the different source address.
    step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
    step 7. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 router blocks incoming sources on a per group basis mcast-v6.tcl ipv6_mcast_220 Verify MLDv2 router blocks incoming sources on a per group basis


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Send an MLDv2 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address.
    step 6. Verify multicast forwarding fails from WAN to LAN for a different group
            using the same specific source address.
    step 7. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
    step 8. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 source specific group with multiple sources mcast-v6.tcl ipv6_mcast_230 Verify MLDv2 source specific group with multiple sources


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Create a new server on the WAN for a multicast source
    step 3. Send an MLDv2 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing multiple specific source
    step 4. Verify an MLDv2 Membership Report packet is received on the WAN interface
    step 5. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 6. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address from source address 1.
    step 7. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address from source address 2.
    step 8. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
    step 9. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 general query requests with source specific memberships mcast-v6.tcl ipv6_mcast_240 Verify MLDv2 general query requests with source specific memberships


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for MLD membership report on the WAN
    step 4. Issue an MLD Membership query to ff02::1 on WAN for group ::
    step 5. Verify router's WAN side responds with MLD membership report for
            the multicast group


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 specific query requests with source specific memberships mcast-v6.tcl ipv6_mcast_250 Verify MLDv2 specific query requests with source specific memberships


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for MLD membership report on the WAN
    step 4. Issue an MLD Membership query on WAN for specific group address
    step 5. Verify router's WAN side responds with MLD membership report for
            the multicast group


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 group and source specific query requests mcast-v6.tcl ipv6_mcast_260 Verify MLDv2 group and source specific query requests


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 1. Join a multicast group on the LAN interface
    step 2. Wait up to 20 seconds for MLD membership report on the WAN
    step 3. Issue an MLD Membership query on WAN for specific group address
    step 4. Verify router's WAN side responds with MLD membership report for
            the multicast group


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 maximum number of multicast groups with multiple group records mcast-v6.tcl ipv6_mcast_300 Verify MLDv2 maximum number of multicast groups with multiple group records


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Join mldMaxGroups multicast groups on the LAN interface using
            multiple group records in a single MLDv2 membership report
    step 3. Forward a multicast UDP packet from the WAN to each group
    step 4. Verify each group is received on the LAN interface
    step 5. Send a MLD Leave for each multicast group


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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

Test Module Name Synopsis
Verify MLDv2 source specific IPTV channel change test scenario mcast-v6.tcl ipv6_mcast_310 Verify MLDv2 source specific IPTV channel change test scenario


    step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
    step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the MLDv2 report is received in the WAN
    step 5. Start sending multicast data on the WAN for the new group
    step 6. Verify the LAN side starts to receive the multicast data
    step 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
    step 8. Send new MLDv2 report to leave current channel and join next channel
            or exit if too many failures have occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar ipv6IptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test earily is many channels start failing.


    References:

    IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"

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

    IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"

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


ula.tcl

IPv6 unique local address (ULA) test module

Test Module Name Synopsis
Verify Router Advertisements include valid unique local prefix ula.tcl ula_1 Verify Router Advertisements include valid unique local prefix


    step 1. Listen for Router Advertisements on the LAN for up to one Router
            Advertisement interval
    step 2. Verify at least one Router Advertisement contains a valid unique
            local prefix that matches the expected unique local prefix
            configured using the testvar ipv6LanUlaPrefix
    step 3. Verify that the unique local prefix discovered in Step 2 contains
            a valid lifetime

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information

    https://tools.ietf.org/html/rfc4861#section-4.6.2

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-side Configuration

    ULA-1:  The IPv6 CE router SHOULD be capable of generating a ULA
            prefix [RFC4193].

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify Route Information option is advertised for unique local prefix ula.tcl ula_2 Verify Route Information option is advertised for unique local prefix


    step 1. Listen for Router Advertisements on the LAN for up to one Router
            Advertisement interval
    step 2. Verify at least one Router Advertisement contains a valid unique
            local prefix that matches the expected unique local prefix
            configured using the testvar ipv6LanUlaPrefix
    step 3. Verify that the unique local prefix discovered in Step 2 contains
            a valid lifetime
    step 4. Verify that the DUT includes a Route Information option for the
            unqiue local prefix discovered in Step 2

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-side Configuration

    L-3:   An IPv6 CE router MUST advertise itself as a router for the
           delegated prefix(es) (and ULA prefix if configured to provide
           ULA addressing) using the "Route Information Option" specified
           in Section 2.3 of [RFC4191].  This advertisement is
           independent of having or not having IPv6 connectivity on the
           WAN interface.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify advertised unique local prefix includes A bit and L bit based on LAN settings ula.tcl ula_3 Verify advertised unique local prefix includes A bit and L bit based on LAN settings


    step 1. Listen for Router Advertisements on the LAN for up to one Router
            Advertisement interval
    step 2. Verify at least one Router Advertisement contains a valid unique
            local prefix that matches the expected unique local prefix
            configured using the testvar ipv6LanUlaPrefix
    step 3. Verify that the unique local prefix discovered in Step 2 contains
            a valid lifetime
    step 4. Check the autonomous address-configuration flag (A bit) in the
            Router Advertisement received in Step 1
    step 5. If the DUT is configured to provide global addresses via DHCPv6 on
            the LAN, the A bit should not be set; if autoconfiguration is used
            instead, the A bit should be set
    step 6. Verify that the prefix discovered in Step 2 has the on-link flag
            (L bit) set

    NOTE: This test is designed to work with DUT's that support only a single
          LAN mode for address autoconfiguration, either DHCPv6 or autoconf.
          DUT configurations in which both modes are enabled simultaneously
          (where the 'A' and 'M' bits are both set) are not currently supported
          by this test.

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information

    https://tools.ietf.org/html/rfc4861#section-4.6.2

Test Module Name Synopsis
Verify DUT responds to Neighbor Solicitations for its IPv6 unique local address ula.tcl ula_4 Verify DUT responds to Neighbor Solicitations for its IPv6 unique local address


    step 1. Send a Neighbor Solicitation on the LAN for the DUT's IPv6 unique
            local address
    step 2. Wait for a Neighbor Advertisement from the DUT
    step 3. Verify fields of Neighbor Advertisement


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify that DUT does not advertise unique local prefixes on the WAN ula.tcl ula_5 Verify that DUT does not advertise unique local prefixes on the WAN


    step 1. Send a Router Solicitation from the WAN
    step 2. Wait to see if DUT sends a Router Advertisement on the WAN
    step 3. Verify that Router Advertisement does not contain any unique local
            prefixes

    NOTE: The testvar ipv6ExpectRAonWan determines if this test should expect to
          see Router Advertisements from the DUT on the WAN.


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

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

Test Module Name Synopsis
Verify unique local prefix is advertised when WAN link is down ula.tcl ula_10 Verify unique local prefix is advertised when WAN link is down


    step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
            link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
            modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
            server and wait for the current IA_NA and/or IA_PD bindings to
            expire.
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
            Information option with a Valid Lifetime greater than 0 for the
            expected unique local prefix
    step 3. Restore all services on the WAN and wait for the WAN link to be
            re-established by the DUT
    step 4. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-2:   The IPv6 CE router MUST assign a separate /64 from its
           delegated prefix(es) (and ULA prefix if configured to provide
           ULA addressing) for each of its LAN interfaces.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify Route Information option for unique local prefix is valid when WAN link is down ula.tcl ula_11 Verify Route Information option for unique local prefix is valid when WAN link is down


    step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
            link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
            modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
            server and wait for the current IA_NA and/or IA_PD bindings to
            expire.
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT sends RAs on the LAN that contain both a Prefix
            Information with a Valid Lifetime greater than 0 and a Route
            Information option for the expected unique local prefix
    step 3. Restore all services on the WAN and wait for the WAN link to be
            re-established by the DUT
    step 4. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-3:   An IPv6 CE router MUST advertise itself as a router for the
           delegated prefix(es) (and ULA prefix if configured to provide
           ULA addressing) using the "Route Information Option" specified
           in Section 2.3 of [RFC4191].  This advertisement is
           independent of having or not having IPv6 connectivity on the
           WAN interface.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify DUT does not advertise itself as a default router when WAN link is down ula.tcl ula_12 Verify DUT does not advertise itself as a default router when WAN link is down


    step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
            link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
            modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
            server and wait for the current IA_NA and/or IA_PD bindings to
            expire.
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT eventually stops advertising itself as a default
            router by setting the Router Lifetime in LAN RAs to a value of 0
            while still sending valid Prefix Information option for the expected
            unique local prefix
    step 4. Restore all services on the WAN and wait for the WAN link to be
            re-established by the DUT
    step 5. Verify that the DUT starts advertising itself as a default router by
            setting the Router Lifetime in LAN RAs to a value greater than 0
    step 6. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-5:  An IPv6 CE router MUST NOT advertise itself as a default
            router with a Router Lifetime greater than zero whenever all
            of its configured and delegated prefixes are ULA prefixes.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify unique local prefix is advertised when WAN RA lifetime is 0 ula.tcl ula_13 Verify unique local prefix is advertised when WAN RA lifetime is 0


    step 1. Send Router Advertisements on the WAN with a Router
            Lifetime of 0
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
            Information and with a Valid Lifetime greater than 0 for the
            expected unique local prefix
    step 4. Restore original Router Lifetime on WAN and start sending Router
            Advertisements on the WAN with a non-zero Router Lifetime
    step 5. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-4:  By default, an IPv6 CE router that has no default router(s) on
          its WAN interface MUST NOT advertise itself as an IPv6 default
          router on its LAN interfaces.  That is, the "Router Lifetime"
          field is set to zero in all Router Advertisement messages it
          originates [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-5:  By default, if the IPv6 CE router is an advertising router and
          loses its IPv6 default router(s) and/or detects loss of
          connectivity on the WAN interface, it MUST explicitly
          invalidate itself as an IPv6 default router on each of its
          advertising interfaces by immediately transmitting one or more
          Router Advertisement messages with the "Router Lifetime" field
          set to zero [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-5:  An IPv6 CE router MUST NOT advertise itself as a default
            router with a Router Lifetime greater than zero whenever all
            of its configured and delegated prefixes are ULA prefixes.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify Route Information option for unique local prefix is valid when WAN RA lifetime is 0 ula.tcl ula_14 Verify Route Information option for unique local prefix is valid when WAN RA lifetime is 0


    step 1. Send Router Advertisements on the WAN with a Router
            Lifetime of 0
    step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
            lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
            interval] (whichever is greater)
    step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
            Information and with a Valid Lifetime greater than 0 for the
            expected unique local prefix
    step 4. Verify that the DUT sends RAs on the LAN that contain a Route
            Information and with a Route Lifetime greater than 0 for the
            expected unique local prefix
    step 5. Restore original Router Lifetime on WAN and start sending Router
            Advertisements on the WAN with a non-zero Router Lifetime
    step 6. Wait for the duration of the dhcpv6PDLatency testvar and perform a
            connectivity check to ensure that the WAN link is operational

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-4:  By default, an IPv6 CE router that has no default router(s) on
          its WAN interface MUST NOT advertise itself as an IPv6 default
          router on its LAN interfaces.  That is, the "Router Lifetime"
          field is set to zero in all Router Advertisement messages it
          originates [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-5:  By default, if the IPv6 CE router is an advertising router and
          loses its IPv6 default router(s) and/or detects loss of
          connectivity on the WAN interface, it MUST explicitly
          invalidate itself as an IPv6 default router on each of its
          advertising interfaces by immediately transmitting one or more
          Router Advertisement messages with the "Router Lifetime" field
          set to zero [RFC4861].

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-5:  An IPv6 CE router MUST NOT advertise itself as a default
            router with a Router Lifetime greater than zero whenever all
            of its configured and delegated prefixes are ULA prefixes.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to its IPv6 unique local address from LAN ula.tcl ula_20 Verify DUT responds to ICMPv6 Echo Requests to its IPv6 unique local address from LAN


    step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's IPv6 unique
            local address
    step 2. Verify ICMPv6 Echo Reply is received
    step 3. Verify the IPv6 source address is a unique local address

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


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a unique local prefix ula.tcl ula_21 Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a unique local prefix


    step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the LAN client's
            unique local address
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

Test Module Name Synopsis
Verify DUT responds to ICMPv6 Echo Requests to the All Nodes group from a unique local IPv6 address ula.tcl ula_22 Verify DUT responds to ICMPv6 Echo Requests to the All Nodes group from a unique local IPv6 address


    step 1. Send an ICMPv6 Echo Request from the LAN client's unique local
            address to the All-Nodes Multicast group (ff02::1)
    step 2. Wait for an ICMPv6 Echo Response
    step 3. Verify the Echo Response is from the DUT
    step 4. Continue waiting until the DUT responds, or timeout


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

Test Module Name Synopsis
Verify packets with IPv6 unique local source addresses are not forwarded to the WAN ula.tcl ula_30 Verify packets with IPv6 unique local source addresses are not forwarded to the WAN


    step 1. Force the LAN client to transmit using its IPv6 unique local address
    step 2. Forward an IPv6 packet from the LAN client to the IPv6 remote host
            on the WAN
    step 3. Verify the packet is not forwarded


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-4:  By default, the IPv6 CE router MUST act as a site border
            router according to Section 4.3 of [RFC4193] and filter
            packets with local IPv6 source or destination addresses
            accordingly.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify packets with IPv6 unique local destination addresses are not forwarded to the WAN ula.tcl ula_31 Verify packets with IPv6 unique local destination addresses are not forwarded to the WAN


    step 1. Force the LAN client to transmit using its IPv6 global address
    step 2. Create a new IPv6 host on the WAN with only unique local address
    step 3. Forward an IPv6 packet from the LAN client to the new IPv6 host on
            the WAN
    step 4. Verify the packet is not forwarded


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-4:  By default, the IPv6 CE router MUST act as a site border
            router according to Section 4.3 of [RFC4193] and filter
            packets with local IPv6 source or destination addresses
            accordingly.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify packets with IPv6 unique local source addresses are not forwarded to the LAN ula.tcl ula_32 Verify packets with IPv6 unique local source addresses are not forwarded to the LAN


    step 1. Create a new IPv6 host on the WAN with only unique local address
    step 2. Forward an IPv6 packet from the new host on the WAN to the LAN
            client using the LAN client's global address as the destination
            address
    step 3. Verify the packet is not forwarded


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-4:  By default, the IPv6 CE router MUST act as a site border
            router according to Section 4.3 of [RFC4193] and filter
            packets with local IPv6 source or destination addresses
            accordingly.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Verify packets with IPv6 unique local destination addresses are not forwarded to the LAN ula.tcl ula_33 Verify packets with IPv6 unique local destination addresses are not forwarded to the LAN


    step 1. Set the IPv6 remote host on the WAN to send using its global address
    step 2. Forward an IPv6 packet from the new host on the WAN to the LAN
            client using the LAN client's unique local address as the destination
            address
    step 3. Verify the packet is not forwarded


    References:

    IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"

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

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    ULA-4:  By default, the IPv6 CE router MUST act as a site border
            router according to Section 4.3 of [RFC4193] and filter
            packets with local IPv6 source or destination addresses
            accordingly.

    https://tools.ietf.org/html/rfc7084#section-4.3


static-v6.tcl

IPv6 static route related tests

Test Module Name Synopsis
Verify all LAN IPv6 static routes with LAN side traffic only static-v6.tcl static_v6_1 Verify all LAN IPv6 static routes with LAN side traffic only


    step 1. Find all configured IPv6 static routes with next hops on the LAN interface
    step 2. Create new gateways for each next hop on the LAN
    step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
    step 4. Verify that the host in the static route reponds with ICMPv6 Echo Reply

    NOTE: When configuring static routes on the CPE device, CDRouter expects
    that the next hop or gateway address is not contained within any LAN-side
    DHCPv6 address pools. CDRouter will create a new host for each next hop
    address.


Test Module Name Synopsis
Verify all LAN IPv6 static routes with LAN to WAN traffic static-v6.tcl static_v6_2 Verify all LAN IPv6 static routes with LAN to WAN traffic


    step 1. Find all configured IPv6 static routes with next hops on the LAN interface
    step 2. Create new gateways for each nexthop on the LAN
    step 3. Send ICMPv6 Echo Request from host in static route network to the WAN side remoteHost
    step 4. Verify that the remoteHost on the WAN receives the ICMPv6 Echo Request
    step 5. Verify the WAN host ICMPv6 Echo Reply is received by the host in static route network

    NOTE: When configuring static routes on the CPE device, CDRouter expects
    that the next hop or gateway address is not contained within any LAN-side
    DHCPv6 address pools. CDRouter will create a new host for each next hop
    address.


Test Module Name Synopsis
Verify all WAN IPv6 static routes static-v6.tcl static_v6_10 Verify all WAN IPv6 static routes


    step 1. Find all configured IPv6 static routes with next hops on the WAN interface
    step 2. Create new gateways for each next hop on the WAN if not the ipv6WanIspIp
    step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
    step 4. Verify that the host in the static route receives the ICMPv6 Echo Request


Test Module Name Synopsis
Verify all WAN IPv6 static routes after WAN ISP address change static-v6.tcl static_v6_20 Verify all WAN IPv6 static routes after WAN ISP address change


    step 1. Find all configured IPv6 static routes with next hops on the WAN interface
    step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
    step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
    step 4. Verify that the host in the static route reponds with ICMPv6 Echo Reply

    NOTE: This test is intended to test static routes that are configured on the CPE
    device by specifying a next hop address of "Wan" instead of a specific IPv6 address.
    Most CPEs allow this type of static route configuration since the actual next hop will
    not be known during configuration when running a dynamic WAN protocol such as PPPoE,
    PPTP, L2TP, or DHCP.

    NOTE: This test is only run when the WAN protocol is dynamic.



cpe-v6.tcl

Tests to verify requirements in RFC 7084

Test Module Name Synopsis
RA Prefix Information Option L-flag, L-flag=0 without Default Router cpe-v6.tcl cpe_v6_1 RA Prefix Information Option L-flag, L-flag=0 without Default Router


    Purpose: Verify that the DUT properly processes the L-flag of the Prefix
             Information Option in the RA.

    Procedure:

    step 1. Reboot the DUT.
    step 2. TR1 transmits a Router Advertisement on the WAN network. The Router
            lifetime is set to 0 and the L-Flag in the Prefix Information Option
            is set to 0.
    step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 4. The DUT must not forward the Echo Request to the WAN.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    https://tools.ietf.org/html/rfc7084#section-4.2

    IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules

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

Test Module Name Synopsis
RA Prefix Information Option L-flag, L-flag=1 without Default Router cpe-v6.tcl cpe_v6_2 RA Prefix Information Option L-flag, L-flag=1 without Default Router


    Purpose: Verify that the DUT properly processes the L-flag of the Prefix
             Information Option in the RA.

    Procedure:

    step 1. Reboot the DUT.
    step 2. TR1 transmits a Router Advertisement on the WAN network. The Router
            lifetime is set to 0 and the L-Flag in the Prefix Information Option
            is set to 1.
    step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 4. The DUT must forward the Echo Request to the WAN using REF-Node1
            as the next hop.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    https://tools.ietf.org/html/rfc7084#section-4.2

    IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules

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

Test Module Name Synopsis
RA Prefix Information Option L-flag, L-flag=0 with Default Router cpe-v6.tcl cpe_v6_3 RA Prefix Information Option L-flag, L-flag=0 with Default Router


    Purpose: Verify that the DUT properly processes the L-flag of the Prefix
             Information Option in the RA.

    Procedure:

    step 1. Reboot the DUT.
    step 2. TR1 transmits RA1 on the WAN network. The L-flag is set to 0.
    step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 4. The DUT must forward the Echo Request to the WAN using TR1 as the
            next hop.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.8: L Flag Processing

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
RA Prefix Information Option L-flag, L-flag=1 with Default Router cpe-v6.tcl cpe_v6_4 RA Prefix Information Option L-flag, L-flag=1 with Default Router


    Purpose: Verify that the DUT properly processes the L-flag of the Prefix
             Information Option in the RA.

    Procedure:

    step 1. Reboot the DUT.
    step 2. TR1 transmits a Router Advertisement on the WAN network.
            The L-flag in the Prefix Information Option is set to 1.
    step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 4. The DUT must forward the Echo Request to the WAN using REF-Node1
            as the next hop.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    https://tools.ietf.org/html/rfc7084#section-4.2

    IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules

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

Test Module Name Synopsis
DHCPv6 Required Options cpe-v6.tcl cpe_v6_5 DHCPv6 Required Options


    Purpose: Verify an IPv6 CE Router properly implements the required DHCPv6
             Options.

    Procedure:

    step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
    step 2. Observe the packets transmitted on the WAN.

    Observable Results:

    step 2. The DUT must transmit a DHCPv6 Solicit message including a
            Reconfigure Accept Option and Option Request Option. The option
            request option must include the DNS_SERVERS Option and SHOULD
            contain the DNS Search List option. DHCP-Server1 sends a DHCPv6
            Advertisement message with the IPv6 address information included.
            DUT sends a DHCPv6 Request messages to confirm the IPv6 address and
            ask for additional information. DHCP-Server1 responds with a DHCPv6
            Reply message that contains the confirmed address.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    WAA-4:   The IPv6 CE router MUST be able to support the following
                    DHCPv6 options: Identity Association for Non-temporary
                    Address (IA_NA), Reconfigure Accept [RFC3315], and
                    DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able to
                    support the DNS Search List (DNSSL) option as specified in
                    [RFC3646].

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
RA M-flag is Set cpe-v6.tcl cpe_v6_6 RA M-flag is Set


    Purpose: Verify an IPv6 CE Router properly process the M flag in Router
             Advertisement.

    Procedure:

    step 1. Reboot the DUT.
    step 2. In response to Router Solicitations from the DUT, TR1
            transmits a Router Advertisement with the M-flag set to 1.
    step 3. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3. The DUT must transmit a DHCPv6 Solicit message containing an
            IA_NA Option.


    References:

    IPv6 Ready CE Router Conformance Test Specification, Rev 1.0.3: Test CERouterInterop.1.6.4: M Flag Processing

    https://ipv6ready.org/docs/IPv6_Ready_Test_Specification_CE_Router_Conformance.pdf

Test Module Name Synopsis
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=0 cpe-v6.tcl cpe_v6_7 RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=0


    Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
             determining initiating DHCPv6 Prefix Delegation.

    Procedure:

    step 1. Reboot the DUT.
    step 2. In response to Router Solicitations from the DUT, TR1
            transmits a Router Advertisement with the M-flag set to 1 and the
            O-flag set to 0.
    step 3. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3. The DUT must transmit a DHCPv6 Solicit message containing an 
            IA_PD Option.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5F: DHCPv6 Prefix Delegation, M Flag

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=1 cpe-v6.tcl cpe_v6_8 RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=1


    Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
             determining initiating DHCPv6 Prefix Delegation.

    Procedure:

    step 1. Reboot the DUT.
    step 2. In response to Router Solicitations from the DUT, TR1
            transmits a Router Advertisement with the M-flag set to 0 and the
            O-flag set to 1.
    step 3. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3. The DUT must transmit a DHCPv6 Solicit message containing an 
            IA_PD Option.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5G: DHCPv6 Prefix Delegation, O Flag

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=1 cpe-v6.tcl cpe_v6_9 RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=1


    Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
             determining initiating DHCPv6 Prefix Delegation.

    Procedure:

    step 1. Reboot the DUT.
    step 2. In response to Router Solicitations from the DUT, TR1
            transmits a Router Advertisement with the M-flag set to 1 and the
            O-flag set to 1.
    step 3. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3. The DUT must transmit a DHCPv6 Solicit message containing an 
            IA_PD Option.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
    delegation when either the M or O flags are set to 1 in a
    received Router Advertisement (RA) message.  Behavior of the
    CE router to use DHCPv6 prefix delegation when the CE router
    has not received any RA or received an RA with the M and the
    O bits set to zero is out of scope for this document.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
No Global Address is Configured cpe-v6.tcl cpe_v6_10 No Global Address is Configured


    Purpose: Verify an IPv6 CE Router properly follows the weak host model
             when no suitable scope exists for a source address on the WAN
             interface.

    Procedure:

    step 1. Reboot the DUT.
    step 2. In response to Router Solicitations from the DUT, TR1
            transmits a Router Advertisement with the M-flag set to 0 and the
            A-flag in the prefix set to 0 so that no global address is assigned
            to the DUT on the WAN.
    step 3. Observe the packets transmitted on the WAN.
    step 4. REF-Host1 transmits an IPv6 packet to TAR-Host1 with a hop-limit of
            2.
    step 5. Observe the packets transmitted on the WAN.

    Observable Results:
    
    step 2. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
            transmits a valid DHCPv6 Advertise Message to DUT. DUT
            transmits a valid DHCPv6 Request Message. DHCP-Server1 transmits a
            valid Reply message to DUT.
    step 4. DUT must transmit an ICMPv6 Time Exceeded message using the
            global source address acquired on the LAN interface to REF-Host1.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.6: Unnumbered WAN

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Different DHCPv6 Prefix Size from Hint cpe-v6.tcl cpe_v6_11 Different DHCPv6 Prefix Size from Hint


    Purpose: Verify that the DUT properly supports prefix delegation and accepts
             a different delegated prefix length from its hint.

    Procedure:

    step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
    step 2. Observe the packets transmitted on the WAN.
    step 3. If the DUT includes a prefix hint, configure DHCP-Server1 to
            assign a different prefix length than the prefix hint supplied in
            the DHCPv6 Solicit message from the DUT.
    step 3. Wait for timer T1 (50s) to expire.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 2. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
            transmits a valid DHCPv6 Advertise Message to DUT. DUT
            transmits a valid DHCPv6 Request Message. DHCP-Server1 transmits a
            valid DHCPv6 Reply message to DUT.
    step 4. The DUT transmits a valid DHCPv6 Renew Message including IA_PD
            option and IA_PD Prefix option and the value within these two
            options must be the same as given in the DHCPv6 Reply message in
            step 2.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5: DHCPv6 Prefix Delegation

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Prevent Forwarding Loops cpe-v6.tcl cpe_v6_12 Prevent Forwarding Loops


    Purpose: Verify an IPv6 CE Router properly prevents routing loops by
             discarding packets that match aggregate routes in the delegated
             prefixes.

    Procedure:

    step 1. Configure DHCP-Server1 to delegate a prefixes larger than DUT can
            delegate.
    step 2. Allow the DUT's DHCPv6 Lease to expire on the WAN.
    step 3. Observe the packets transmitted on the WAN.
    step 4. TAR-Host1 transmits ICMPv6 Echo Request to an address that was not
            assigned to a LAN interface on the DUT.
    step 5. Observe the packets transmitted on the WAN.
    step 6. REF-Host1 transmits ICMPv6 Echo Request to an address that was
            not assigned to a LAN interface on the DUT.
    step 7. Observe the packets transmitted on the WAN.

    Observable Results:
    
    step 3. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
            transmits a valid DHCPv6 Advertise Message to DUT. DUT
            transmits a valid DHCPv6 Request Message. DHCP-Server transmits a
            valid DHCPv6 Reply message to DUT.
    step 5. The DUT must not forward the ICMPv6 Echo Request to
            TAR-Router1. The DUT should transmit an ICMPv6 Destination
            Unreachable message to TAR-Host1.
    step 7. The DUT must not forward the ICMPv6 Echo Request to the LAN.
            The DUT should transmit an ICMPv6 Destination Unreachable message
            to REF-Host1.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.3.4: Forwarding Loops

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /64 cpe-v6.tcl cpe_v6_13 Assign /64 Prefixes to LAN Interfaces, Prefix Length of /64


    Purpose: Verify an IPv6 CE Router properly assigns address from prefix
             delegation to LAN interfaces.

    Procedure:

    step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
    step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
            and assign addresses to the LAN side hosts. The prefix length is 64.
    step 4. Observe the packets transmitted on the LAN.
    step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
    step 6. Observe the packets transmitted on the LAN.
    step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
    step 8. Observe the packets transmitted on the LAN.

    Observable Results:

    step 4. The DUT must transmit an RA including a PIO with PF1/64
            and non-zero lifetimes.
    step 6. The DUT must reply to the Echo Request.
    step 8. The DUT must forward the Echo Request to REF-Host1.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.2A: Assigning Prefixes to LAN Interfaces, Prefix Length of /64

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /48 cpe-v6.tcl cpe_v6_14 Assign /64 Prefixes to LAN Interfaces, Prefix Length of /48


    Purpose: Verify that the DUT assigns /64 addresses from prefix delegation to
             the LAN interfaces.

    Procedure:

    step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
    step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
            and assign addresses to the LAN side hosts. The prefix length is 48.
    step 4. Observe the packets transmitted on the LAN.
    step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
    step 6. Observe the packets transmitted on the LAN.
    step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
    step 8. Observe the packets transmitted on the LAN.

    Observable Results:

    step 4. The DUT must transmit an RA including a PIO with PF1/64
            and non-zero lifetimes.
    step 6. The DUT must reply to the Echo Request.
    step 8. The DUT must forward the Echo Request to REF-Host1.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-2:   The IPv6 CE router MUST assign a separate /64 from its
                    delegated prefix(es) (and ULA prefix if configured to provide
                    ULA addressing) for each of its LAN interfaces.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /56 cpe-v6.tcl cpe_v6_15 Assign /64 Prefixes to LAN Interfaces, Prefix Length of /56


    Purpose: Verify an IPv6 CE Router properly assigns address from prefix
             delegation to LAN interfaces.

    Procedure:

    step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
    step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
            and assign addresses to the LAN side hosts. The prefix length is 56.
    step 4. Observe the packets transmitted on the LAN.
    step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
    step 6. Observe the packets transmitted on the LAN.
    step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
    step 8. Observe the packets transmitted on the LAN.

    Observable Results:

    step 4. The DUT must transmit an RA including a PIO with PF1/64
            and non-zero lifetimes.
    step 6. The DUT must reply to the Echo Request.
    step 8. The DUT must forward the Echo Request to REF-Host1.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.2B: Assigning Prefixes to LAN Interfaces, Prefix Length of /56

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
RA Route Information Option, Having WAN Connectivity cpe-v6.tcl cpe_v6_16 RA Route Information Option, Having WAN Connectivity


    Purpose: Verify an IPv6 CE Router advertises itself as a router for
    delegated prefixes.

    Procedure:
    step 1. Configure DHCP-Server1 to assign a /60 prefix through Prefix
            Delegation.
    step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
    step 3. Observe the packets transmitted on the WAN.
    step 4. Observe the packets transmitted on the LAN.
    step 5. REF-Host1 transmits an ICMPv6 Echo Request to TAR-Host1's global
            address.
    step 6. Observe the packets transmitted on the LAN and WAN.

    Observable Results:

    step 3. The DUT transmits a valid DHCP Solicit Message. DHCP-Server1
            transmits a valid DHCP Advertise Message to DUT. The DUT
            transmits a valid DHCP Request Message. DHCP-Server1 transmits a
            valid DHCP Reply message to DUT.
    step 4: The DUT transmits a Router Advertisement containing the Route
            Information Option containing a delegated prefix. The Prefix Length
            and Route Lifetime must match the information supplied from DHCPv6
            Prefix Delegation.
    step 6: TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
            with ICMPv6 Echo Replies.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3A: Router Advertisement, Route Information Option

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
RA Route Information Option, Without WAN Connectivity cpe-v6.tcl cpe_v6_17 RA Route Information Option, Without WAN Connectivity


    Purpose: Verify that the DUT advertises itself as a router for the delegated
             prefix using the Route Information Option and the advertising is
             independent of having or not IPv6 connectivity on WAN.

    Procedure:

    step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
    step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
            and assign addresses to the LAN side hosts. The prefix length is
            60. The IA_PD lifetime is three times that of the IA_NA lifetime.
    step 3. TAR-Host1 transmits a Router Solicitation. Observe the packets
            transmitted on the LAN.
    step 4. Disable the DUT's connection on the WAN network.
    step 5. Wait for the DUT's IA_NA lifetime to expire.
    step 6. TAR-Host1 transmits a Router Solicitation. Observe the packets
            transmitted on the LAN.

    Observable Results:

    step 3. The DUT must transmit an RA with a Route Information option for PF1.
            The Prefix, Prefix Length and Route Lifetime must match the
            information supplied from DHCPv6 Prefix Delegation.
    step 6. The DUT must transmit an RA with a Route Information option for PF1.
            The Prefix, Prefix Length and Route Lifetime must match the
            information supplied from DHCPv6 Prefix Delegation.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-3:   An IPv6 CE router MUST advertise itself as a router for the
                    delegated prefix(es) (and ULA prefix if configured to provide
                    ULA addressing) using the "Route Information Option" specified
                    in Section 2.3 of [RFC4191].  This advertisement is
                    independent of having or not having IPv6 connectivity on the
                    WAN interface.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
No Prefixes Delegated cpe-v6.tcl cpe_v6_18 No Prefixes Delegated


    Purpose: Verify an IPv6 CE Router advertises itself as a router for
             delegated prefixes.

    eure:

    step 1. Configure DHCP-Server1 to not assign IA_PD.
    step 2. Reboot the DUT.
    step 3. Observe the packets transmitted on the LAN and WAN.

    Observable Results:

    step 3. The DUT must not transmit Router Advertisements with a router
            lifetime greater zero on the LAN.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3B: Router Advertisement, No Prefixes

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
No Prefixes Delegated, Delegated Prefix Expired cpe-v6.tcl cpe_v6_19 No Prefixes Delegated, Delegated Prefix Expired


    Purpose: Verify that the DUT does not advertise itself as a default router
             if its delegated prefix has expired.

    Procedure:

    step 1. Wait for the DUT to perform the DHCPv6-PD process.
    step 2. TAR-Host1 transmits a Router Solicitation to the all-routers
            address.
    step 3. Observe the packets transmitted on the LAN.
    step 4. Wait for delegated prefix to expire.
    step 5. TAR-Host1 transmits RS1 to the all-routers address.
    step 6. Observe the packets transmitted on the LAN.

    Observable Results:

    step 3. The DUT must transmit an RA with router lifetime greater than 0 in
            response to the Router Solicitation.
    step 6. The DUT must not transmit an RA with Router Lifetime greater than
            0 in response to the Router Solicitation.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration

    L-4:   An IPv6 CE router MUST NOT advertise itself as a default
                    router with a Router Lifetime [RFC4861] greater than zero if
                    it has no prefixes configured or delegated to it.

    https://tools.ietf.org/html/rfc7084#section-4.3

Test Module Name Synopsis
Router Advertisement, Advertising Interface cpe-v6.tcl cpe_v6_20 Router Advertisement, Advertising Interface


    Purpose: Verify an IPv6 CE Router advertises itself as a router for
             delegated prefixes.

    Procedure:
    
    step 1. TAR-Host1 transmits RS1 to the all-routers address.
    step 2. Observe the packets transmitted on the LAN.

    Observable Results:

    step 2. The DUT must transmit a Router Advertisement. The Prefix
            Information Option A and L flags must be set to one.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3C: Router Advertisement, Advertising Interface

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Delegated Prefix Change cpe-v6.tcl cpe_v6_21 Delegated Prefix Change


    Purpose: Verify that the DUT properly advertises RA when the delegated
             prefix changed.

    Procedure:

    step 1.  Allow time for the DUT's DHCPv6 IA_PD lease to expire and
             restart DHCPv6 to be assigned Prefix X with a preferred and valid lifetime of 1 minute.
    step 2.  Allow time for DUT to distribute the Prefix X on LAN
             interfaces.
    step 3.  REF-Host1 transmits ICMPv6 Echo Request to TAR-Host1's Prefix X
             global address.
    step 4.  Observe the packets transmitted on the LAN and WAN.
    step 5.  Configure DHCP-Server1 to remove Prefix X from the available
             Prefixes. Configure Prefix Y to be available for DUT.
    step 6.  Wait for DUT to transmit a DHCPv6 Renew for Prefix X.
    step 7.  Observe the packets transmitted on the LAN and WAN.
    step 8.  Wait for the valid lifetime of Prefix X to timeout.
    step 9.  Assign REF-Host2 a global address using Prefix X from step 2.
    step 10. REF-Host1 transmits ICMPv6 Echo Request to Prefix Y global address
             of TAR-Host1.
    step 11. Observe the packets transmitted on the LAN and WAN.
    step 12. REF-Host2 transmits ICMPv6 Echo Request from Prefix X global
             address from Step 9 to REF-Host1.
    step 13. Observe the packets transmitted on the LAN and WAN.

    Observable Results:

    step 4:  TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
             with ICMPv6 Echo Replies.
    step 7:  The DUT transmits a valid DHCPv6 Renew message. DHCP-Server1
             transmits a valid DHCP Reply message with a new IPv6 prefix from
             Step 5 on the WAN. The DUT must transmit Router Advertisements with
             a Prefix Information Option containing a preferred lifetime of zero
             for all prefixes previous delegated on the LAN. The valid lifetime of
             the Prefix Option must not be greater then the value advertised in
             the IA_PD. Future DHCPv6 Renew messages from the DUT must NOT
             include the old IPv6 prefix. 
    step 11: TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
             with ICMPv6 Echo Replies.
    step 13: The DUT must not forward ICMPv6 Echo Request from REF-Host2.
             The DUT must transmit an ICMPv6 Destination Unreachable message
             with a code 5 to REF-Host2.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.6A: Prefix Change, Prefix Timeout

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Default Source Address Selection, Prefer Appropriate Scope cpe-v6.tcl cpe_v6_22 Default Source Address Selection, Prefer Appropriate Scope


    Purpose: Verify that the DUT properly selects a source address of the
             appropriate scope when originating IPv6 traffic.

    Procedure:

    step 1. Ref-Host1 transmits an Echo Request to an address on the DUT's LAN
            network.
            The Hop Limit of the Echo Request is set to 2.
    step 2. Observe the packets transmitted on the WAN.

    Observable Results:

    step 2. The DUT must transmit a Time Exceeded message with a global source
            address.


    References:

    IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection

    Rule 2: Prefer appropriate scope.
                    If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
                    otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
                    Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

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

Test Module Name Synopsis
Default Source Address Selection, Avoid Deprecated Addresses cpe-v6.tcl cpe_v6_23 Default Source Address Selection, Avoid Deprecated Addresses


    Purpose: Verify that the DUT properly selects default source address.

    Procedure:

    step 1. TAR-Router1 transmits RA1 on the WAN network. RA1 contains Prefix 1
            with valid lifetime set to 60 and preferred lifetime set to 20. It
            also contains Prefix 2 with the valid and preferred lifetimes set
            to 60.
    step 2. Wait 20 seconds.
    step 3. REFHost1 transmits an Echo Request to an address on the DUT's LAN
            network. The Hop Limit of the Echo Request is set to 2.
    step 4. Observe the packets transmitted on the WAN.
    
    Observable Results:

    step 5. The DUT must transmit a Time Exceeded message with Prefix 2 as the
            source address.


    References:

    IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection

    Rule 3: Avoid deprecated addresses.
    If one of the two source addresses is "preferred" and one of them is
    "deprecated" (in the RFC 4862 sense), then prefer the one that is
    "preferred".

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

Test Module Name Synopsis
Default Source Address Selection, Use Longest Matching Prefix cpe-v6.tcl cpe_v6_24 Default Source Address Selection, Use Longest Matching Prefix


    Purpose: Verify that the DUT properly selects default source address.

    Procedure:

    step 1. TR1 transmits an RA on the WAN network. The RA contains two
            prefixes, Prefix 1 and Prefix 2, that have only the first 56 bits
            in common. The preferred and valid lifetimes last the entire test.
    step 2. Allow the DUT time to bind both addresses.
    step 3. REFHost1 transmits an Echo Request to an address on the DUT's LAN
            network. The Hop Limit of the Echo Request is set to 2. REFHost1's
            source address matches only the first 60 bits of Prefix 2.
    step 4. Observe the packets transmitted on the WAN.

    Observable Results:

    step 4. The DUT must transmit a Time Exceeded message with its Prefix 2
            address as the source address.


    References:

    IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection

    Rule 8: Use longest matching prefix.
    If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
    Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
    prefer SB.

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

Test Module Name Synopsis
Default Router Lost cpe-v6.tcl cpe_v6_25 Default Router Lost


    Purpose: Verify an IPv6 CE Router does not advertise itself as a default
             route on LAN interfaces when no default route exists on the WAN
             interface.

    Procedure:

    step 1. Configure TAR-Router1 to transmit Router Advertisement with a
            Router Lifetime of 600. 
    step 2. Observe the packets transmitted on the LAN.
    step 3. REF-Host1 transmits ICMPv6 Echo Request to TAR-Host1.
    step 4. Observe the packets transmitted on the LAN.
    step 5. Configure TAR-Router1 to transmit Router Advertisement with a
            Router Lifetime of 0. 
    step 6. Observe the packets transmitted on the LAN.
    step 7. REF-Host1 transmits ICMPv6 Echo Request to DUT.
    step 8. Observe the packets transmitted on the WAN.

    Observable Results:

    step 2: The DUT must transmit a Router Advertisements with a Router
            Lifetime greater than zero.
    step 4: TAR-Host1 must transmit an ICMPv6 Echo Replies to REF-Host1.
    step 6: The DUT must immediately transmit Router Advertisements with a
            Router Lifetime with a lifetime of zero.
    step 8: The DUT must not transmit an ICMPv6 Echo Reply to REF-Host1.


    References:

    IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.3.3B: No Default Route, Loses Default Route

    https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf

Test Module Name Synopsis
Forwarding before address acquisition - DHCPv6 Leases Expired cpe-v6.tcl cpe_v6_26 Forwarding before address acquisition - DHCPv6 Leases Expired


    Purpose: Verify an IPv6 CE Router does not forward traffic between its WAN
             and LAN interfaces before it has completed address acquisition on
             the WAN

    Procedure:

    step 1. Wait for the DUT's DHCPv6 leases to expire on the WAN.
    step 2. Send an Echo Request from TAR-Host1 to REF-Host1.
    step 3. Observe the traffic on the WAN.
    step 4. Allow the DUT to acquire new DHCPv6 leases on the WAN.
    step 5. Send an Echo Request from TAR-Host1 to REF-Host1.
    step 6. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3: The DUT must not forward the Echo Request to the WAN.
    step 6: The DUT must forward the Echo Request to the WAN.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    G-3:  The IPv6 CE router MUST NOT forward any IPv6 traffic between
          its LAN interface(s) and its WAN interface until the router has
          successfully completed the IPv6 address and the delegated
          prefix acquisition process.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
Forwarding before address acquisition - Reboot cpe-v6.tcl cpe_v6_27 Forwarding before address acquisition - Reboot


    Purpose: Verify an IPv6 CE Router does not forward traffic between its WAN
             and LAN interfaces before it has completed address acquisition on
             the WAN

    Procedure:

    step 1. Disable the DHCPv6 Server on the WAN.
    step 2. Reboot the DUT.
    step 3. After receiving the first Solicit on the WAN, send traffic from
            TAR-Host1 to REF-Host1.
    step 4. Observe the traffic on the WAN.
    step 5. Wait for the DUT to retransmit a Solicit message and complete
            DHCPv6.
    step 6. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3: The DUT must not forward any traffic to the WAN,
    step 6. The DUT must forward the Echo Requests to the LAN after it completes
            DHCPv6.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    G-3:  The IPv6 CE router MUST NOT forward any IPv6 traffic between
          its LAN interface(s) and its WAN interface until the router has
          successfully completed the IPv6 address and the delegated
          prefix acquisition process.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
No Default Router cpe-v6.tcl cpe_v6_28 No Default Router


    Purpose: Verify an IPv6 CE Router does not advertise itself as a default
             route on LAN interfaces when no default route exists on the WAN
             interface.

    Procedure:

    step 1. Reboot the DUT.
    step 2. Configure TAR-Router1 to transmit Router Advertisement with a
            Router Lifetime of 0.
    step 3. Observe the packets transmitted on the LAN.
    step 4. REF-Host1 transmits ICMPv6 Echo Request to the DUT's WAN address.
    step 5. Observe the packets transmitted on the WAN.

    Observable Results:

    step 3: The DUT must not transmit a Router Advertisement with a Router
            Lifetime greater than zero.
    step 5. The DUT must not transmit an ICMPv6 Echo Reply to REF-Host1.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements

    G-4:  By default, an IPv6 CE router that has no default
    router(s) on its WAN interface MUST NOT advertise itself as an IPv6
    default router on its LAN interfaces.  That is, the "Router Lifetime"
    field is set to zero in all Router Advertisement messages it originates
    [RFC4861].

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

Test Module Name Synopsis
IPv6 Host on WAN cpe-v6.tcl cpe_v6_29 IPv6 Host on WAN


    Purpose: Verify that the DUT acts as an IPv6 Host on its WAN interface.

    Procedure:

    step 1. Wait for the DUT to send a DHCPv6 Renew message to learn the DUT's
            link-local address.
    step 2. Reboot the DUT.
    step 3. Observe the traffic on the WAN.
    step 4. TR1 transmits a Router Solicitation on the WAN.
    step 5. Observe the traffic on the WAN.

    Observable Results:

    step 3: The DUT must acquire a global IPv6 address on the WAN via stateless
            or stateful address assignment. The DUT must not transmit a Router
            Advertisement on the WAN.
    step 5. The DUT must not transmit a Router Advertisement on the WAN in
            response to the Router Solicitation.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    W-1:  When the router is attached to the WAN interface link, it MUST
    act as an IPv6 host for the purposes of stateless [RFC4862] or
    stateful [RFC3315] interface address assignment.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
Duplicate Address Detection before Router Discovery cpe-v6.tcl cpe_v6_30 Duplicate Address Detection before Router Discovery


    Purpose: Verify that the DUT completes Duplicate Address Detection before
             performing Router Discovery

    Procedure:

    step 1. Wait for the DUT to send a DHCPv6 Renew message to learn the DUT's
            link-local address.
    step 2. Reboot the DUT.
    step 3. Observe the traffic on the WAN.
    step 4. Send an ICMPv6 Echo Request from TAR-Host1 to REF-Host1.
    step 5. Observe the traffic on the WAN.

    Observable Results:

    step 3: The DUT must complete Duplicate Address Detection for its
            link-local address before it sends a Router Solicitation message
            on the WAN. The Router Solicitation must have a source address equal
            to the DUT's link-local address.
    step 5. The DUT must forward the Echo Request to TAR-Router1, indicating
            that it installed a default route.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    W-2:  The IPv6 CE router MUST generate a link-local address and
    finish Duplicate Address Detection according to [RFC4862] prior
    to sending any Router Solicitations on the interface.  The
    source address used in the subsequent Router Solicitation MUST
    be the link-local address on the WAN interface.

    W-3:  Absent other routing information, the IPv6 CE router MUST use
    Router Discovery as specified in [RFC4861] to discover a
    default router(s) and install a default route(s) in its routing
    table with the discovered router's address as the next hop.

    https://tools.ietf.org/html/rfc7084#section-4.2

Test Module Name Synopsis
Persistent DUID cpe-v6.tcl cpe_v6_31 Persistent DUID


    Purpose: Verify that the DUT uses a persistent DUID for DHCPv6 Messages

    Procedure:

    step 1. Wait for the DUT to send a DHCPv6 message on the WAN and record the
            DUID.
    step 2. Reboot the DUT.
    step 3. Observe the traffic on the WAN.

    Observable Results:

    step 3: The DUT must send a DHCPv6 Solicit that includes an IA_PD option
            with a DUID that matches the DUID in step 1.


    References:

    IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration

    W-4:  The router MUST act as a requesting router for the purposes of
    DHCPv6 prefix delegation ([RFC3633]).

    W-5:  The IPv6 CE router MUST use a persistent DHCP Unique Identifier
    (DUID) for DHCPv6 messages.  The DUID MUST NOT change between
    network-interface resets or IPv6 CE router reboots.

    https://tools.ietf.org/html/rfc7084#section-4.2


sip-v6.tcl

SIP over IPv6 testing

Test Module Name Synopsis
Verify SIPv6 registration sip-v6.tcl ipv6_sip_1 Verify SIPv6 registration


    step 1. Send a REGISTER from LAN client to SIP proxy on WAN
    step 2. Verify the LAN client's registration is successful


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify SIPv6 registration with short format SIP headers sip-v6.tcl ipv6_sip_2 Verify SIPv6 registration with short format SIP headers


    step 1. Configure the SIP client and server to use short
            header formats
    step 2. Send a REGISTER from LAN client to SIP proxy on WAN
    step 3. Verify the LAN client's registration is successful


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIPv6 outbound call sip-v6.tcl ipv6_sip_10 Verify SIPv6 outbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify the outbound call is successful


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify short format SIP headers during outbound SIPv6 call sip-v6.tcl ipv6_sip_11 Verify short format SIP headers during outbound SIPv6 call


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Verify the outbound call is successful


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIPv6 inbound call sip-v6.tcl ipv6_sip_20 Verify SIPv6 inbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call to LAN side SIP destination
    step 3. Verify the inbound call is successful


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify short format SIP headers during inbound SIPv6 call sip-v6.tcl ipv6_sip_21 Verify short format SIP headers during inbound SIPv6 call


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an inbound call to LAN side SIP destination
    step 4. Verify the inbound call is successful


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIPv6 calls with multiple DHCP LAN clients sip-v6.tcl ipv6_sip_200 Verify outbound SIPv6 calls with multiple DHCP LAN clients


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the
    testvar 'sipMaxOutboundCalls'. It defaults to 10.

    By default, the SIP server and client use port 5060. The SIP
    server port may be configured using the testvar sipScaleServerPort.
    The sipScaleClientPort testvar may be used to configure a specific
    SIP client source port for the clients. The value of unique may
    also be specified to dynamically allocate the SIP client port.

    Example:

    testvar sipScaleServerPort 10001
    testvar sipScaleClientPort unique

    For this testing scenario, the pace of the RTP stream is slowed down
    to allow fewer RTP packets per stream. The actual RTP send interval
    can be configured using the testvar 'rtpSendInterval'. This is the
    interval between each RTP packet in milliseconds. The default value is
    5000 milliseconds. If this is increased to a larger value, changing the
    value of 'sipScaleRunTime' should also be increased. This controls the
    duration must be long enough to allow each RTP stream to send and
    receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIPv6 calls with multiple DHCP LAN clients without registering a port sip-v6.tcl ipv6_sip_201 Verify outbound SIPv6 calls with multiple DHCP LAN clients without registering a port


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the
    testvar 'sipMaxOutboundCalls'. It defaults to 10.

    By default, the SIP server and client use port 5060. The SIP
    server port may be configured using the testvar sipScaleServerPort.
    The sipScaleClientPort testvar may be used to configure a specific
    SIP client source port for the clients. The value of unique may
    also be specified to dynamically allocate the SIP client port.

    Example:

    testvar sipScaleServerPort 10001
    testvar sipScaleClientPort unique

    For this testing scenario, the pace of the RTP stream is slowed down
    to allow fewer RTP packets per stream. The actual RTP send interval
    can be configured using the testvar 'rtpSendInterval'. This is the
    interval between each RTP packet in milliseconds. The default value is
    5000 milliseconds. If this is increased to a larger value, changing the
    value of 'sipScaleRunTime' should also be increased. This controls the
    duration must be long enough to allow each RTP stream to send and
    receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) sip-v6.tcl ipv6_sip_300 Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP)


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the
    testvar 'sipMaxOutboundCalls'. It defaults to 10.

    By default, the SIP server and client use port 5060. The SIP
    server port may be configured using the testvar sipScaleServerPort.
    The sipScaleClientPort testvar may be used to configure a specific
    SIP client source port for the clients. The value of unique may
    also be specified to dynamically allocate the SIP client port.

    Example:

    testvar sipScaleServerPort 10001
    testvar sipScaleClientPort unique

    For this testing scenario, the pace of the RTP stream is slowed down
    to allow fewer RTP packets per stream. The actual RTP send interval
    can be configured using the testvar 'rtpSendInterval'. This is the
    interval between each RTP packet in milliseconds. The default value is
    5000 milliseconds. The call duration can be changed using the testvar
    'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) without registering a port sip-v6.tcl ipv6_sip_301 Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) without registering a port


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the
    testvar 'sipMaxOutboundCalls'. It defaults to 10.

    This test will start the SIP server and SIP clients on the default
    port of 5060.

    For this testing scenario, the pace of the RTP stream is slowed down
    to allow fewer RTP packets per stream. The actual RTP send interval
    can be configured using the testvar 'rtpSendInterval'. This is the
    interval between each RTP packet in milliseconds. The default value is
    5000 milliseconds. The call duration can be changed using the testvar
    'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1


triggerp-v6.tcl

Tests to verify configured IPv6 trigger ports on the router

Test Module Name Synopsis
Verify basic case for each configured IPv6 trigger port application triggerp-v6.tcl ipv6_tport_10 Verify basic case for each configured IPv6 trigger port application


    step 1. Read all the configured trigger ports
    step 2. For each port, verify that none of the public triggered ports
            are currently open on the WAN side.
    step 3. Initiate a TCP or UDP session from the LAN to the WAN side
            using the triggered port as the destination port.
    step 4. Verify the TCP or UDP session is created
    step 5. For each public port that should now be triggered, open
            a connection from the WAN to the LAN using the public
            port as the destination port and the router's nat IP address
            as the destination IP address
    step 5. Verify a connection can be estabished for each public port
    step 6. Close down each public port
    step 7. Close down the original LAN side connection used for the trigger
    step 8. Repeat for each configured port trigger

    NOTE: Up to 4096 trigger ports can be configured in your configuration
    file. For example,

    testvar triggerName1                  net2phone-1
    testvar triggerAddrType1              ipv6
    testvar triggerPort1                  6801
    testvar triggerType1                  udp
    testvar triggerPublic1                30000
    testvar triggerPublicType1            both

    testvar triggerName2                  app1
    testvar triggerAddrType2              ipv6
    testvar triggerPort2                  20000
    testvar triggerType2                  udp
    testvar triggerPublic2                20001-20010
    testvar triggerPublicType2            udp

    NOTE: Many routers will not time out the triggered port connection once
    it is open. This will cause this test to fail if it is executed more
    than once.

    The PublicType may be either "tcp", "udp", or "both". If "both" is used,
    the test case will verify both a TCP and UDP connection for each port
    in the Public range.

    A delay can be configured between each trigger port. This is sometimes
    required for port trigger implementations using Smart ALGs. To configure
    the delay, configure the testvar 'portTriggerDelay' with the number of
    milliseconds.

    A delay can also be configured before a trigger port is verified as being
    open with WAN to LAN traffic. This is sometimes required for
    implemenatations that have a delay associated with processing the outbound
    trigger packet. To configure the delay, configure the testvar
    'portTriggerOpenDelay' with the number of milliseconds.

    Examples:

    testvar portTriggerDelay 5000
    testvar portTriggerOpenDelay 1000


Test Module Name Synopsis
Verify multiple LAN hosts can use IPv6 trigger ports after mappings are aged out triggerp-v6.tcl ipv6_tport_30 Verify multiple LAN hosts can use IPv6 trigger ports after mappings are aged out


    step 1. Read all the configured trigger ports
    step 2. Create a second DHCP LAN client
    step 3. Initiate a TCP or UDP session from the LAN to the WAN side
            using the triggered port as the destination port
    step 4. Verify the TCP or UDP session is created
    step 5. For each public port that should now be triggered, open
            a connection from the WAN to the LAN using the public
            port as the destination port and the router's nat IP address
            as the destination IP address.
    step 6. Verify a connection can be estabished for each public port
    step 7. Close down each public port
    step 8. Close down the original LAN side connection used for the trigger
    step 9. Wait for port mappings to be aged out
    step 10. Repeat from step 2. using the second LAN client
    step 11. Repeat for each configured port trigger

    NOTE: The port mapping aging time for trigger ports is configured
    using the portTriggerTimeout variable in your config file. Your
    router must support the aging of trigger ports in order to run this
    test.

    NOTE: Up to 4096 trigger ports can be configured in your configuration
    file. For example,

    testvar triggerName1                  net2phone-1
    testvar triggerAddrType1              ipv6
    testvar triggerPort1                  6801
    testvar triggerType1                  udp
    testvar triggerPublic1                30000
    testvar triggerPublicType1            both

    NOTE: Many routers will not time out the triggered port connection once
    it is open. This will cause this test to fail if it is executed more
    than once.

    The PublicType may be either tcp, udp, or both. If "both" is used,
    the test case will verify both a TCP and UDP connection for each port
    in the Public range.

    A delay can be configured between each trigger port. This is sometimes
    required for port trigger implementations using Smart ALGs. To configure
    the delay, configure the testvar 'portTriggerDelay' with the number of
    milliseconds.

    A delay can also be configured before a trigger port is verified as being
    open with WAN to LAN traffic. This is sometimes required for
    implemenatations that have a delay associated with processing the outbound
    trigger packet. To configure the delay, configure the testvar
    'portTriggerOpenDelay' with the number of milliseconds.

    Examples:

    testvar portTriggerDelay 5000
    testvar portTriggerOpenDelay 1000



rfc6092.tcl

IETF RFC 6092 simple security in IPv6 gateway CPE tests

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-1 rfc6092.tcl rfc6092_rec_1 Section 3.1: Stateless filters, REC-1


    step 1. Forward a packet with a node-local multicast source address from LAN to WAN
    step 2. Verify packet in Step 1 is not forwarded to the WAN
    step 3. Repeat steps 1 and 2 with a site-local multicast source address
    step 4. Repeat steps 1 and 2 with a global multicast source address
    step 5. Forward a packet with a node-local multicast source address from WAN to LAN
    step 6. Verify packet in Step 3 is not forwarded to the LAN
    step 7. Repeat steps 5 and 6 with a site-local multicast source address
    step 8. Repeat steps 5 and 6 with a global multicast source address


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-1: Packets bearing multicast source addresses in their outer IPv6
    headers MUST NOT be forwarded or transmitted on any interface.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-2 rfc6092.tcl rfc6092_rec_2 Section 3.1: Stateless filters, REC-2


    step 1. Forward a packet with a node-local multicast destination
            address from WAN to LAN
    step 2. Verify packet in Step 1 is not forwarded to the LAN
    step 3. Forward a packet with a node-local multicast destination
            address from LAN to WAN
    step 4. Verify packet in Step 3 is not forwarded to the WAN
    step 5. Repeat steps 1-4 with a link-local multicast destination
            address
    step 6. Repeat steps 1-4 with a site-local multicast destination
            address
    step 7. Repeat steps 1-4 with a organization-local multicast
            destination address


    References:

    IETF RFC 2464 "Transmission of IPv6 Packets over Ethernet Networks" Section 7: Address Mapping -- Multicast

    An IPv6 packet with a multicast destination address DST, consisting
    of the sixteen octets DST[1] through DST[16], is transmitted to the
    Ethernet multicast address whose first two octets are the value 3333
    hexadecimal and whose last four octets are the last four octets of
    DST.

    https://tools.ietf.org/html/rfc2464#section-7

    IETF RFC 6085 "Address Mapping of IPv6 Multicast Packets on Ethernet" Section 3: Receiving IPv6 Multicast Packets

    An IPv6 node receiving an IPv6 packet with a multicast destination
    address and an Ethernet link-layer unicast address MUST NOT drop the
    packet as a result of the use of this form of address mapping.

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

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-2: Packets bearing multicast destination addresses in their outer
    IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
    Architecture" [RFC4007]) than the configured scope boundary level of
    the gateway MUST NOT be forwarded in any direction.  The DEFAULT
    scope boundary level SHOULD be organization-local scope, and it
    SHOULD be configurable by the network administrator.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-3 rfc6092.tcl rfc6092_rec_3 Section 3.1: Stateless filters, REC-3


    step 1. Forward a packet with a non-routable source address from LAN to WAN
    step 2. Verify packet in Step 1 is not forwarded to the WAN
    step 3. Forward a packet with a non-routable destination address from LAN to
            WAN
    step 4. Verify packet in Step 3 is not forwarded to the WAN
    step 5. Repeat steps 1 through 4 for various well known non-routable
            addresses


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-3: Packets bearing source and/or destination addresses forbidden
    to appear in the outer headers of packets transmitted over the public
    Internet MUST NOT be forwarded.  In particular, site-local addresses
    are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
    of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible
    Addresses, Documentation Prefix, and Overlay Routable Cryptographic
    Hash IDentifiers (ORCHID).

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-4 rfc6092.tcl rfc6092_rec_4 Section 3.1: Stateless filters, REC-4


    step 1. Forward a packet with routing extension header type 0 from LAN to
            WAN
    step 2. Verify packet in Step 1 is not forwarded to the WAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-4: Packets bearing deprecated extension headers prior to their
    first upper-layer-protocol header SHOULD NOT be forwarded or
    transmitted on any interface.  In particular, all packets with
    routing extension header type 0 [RFC2460] preceding the first upper-
    layer-protocol header MUST NOT be forwarded.  See [RFC5095] for
    additional background.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-5 rfc6092.tcl rfc6092_rec_5 Section 3.1: Stateless filters, REC-5


    step 1. Create a new LAN client
    step 2. Assign a global prefix to the LAN client that is different
            from the one belonging to the LAN
    step 3. Send traffic to the WAN from the martian source address
    step 4. Verify traffic is not forwarded


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-5: Outbound packets MUST NOT be forwarded if the source address
    in their outer IPv6 header does not have a unicast prefix configured
    for use by globally reachable nodes on the interior network.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-6 rfc6092.tcl rfc6092_rec_6 Section 3.1: Stateless filters, REC-6


    step 1. Create a new stack on the remoteHost
    step 2. Assign the stack the same global prefix as is used on the LAN
    step 3. Send traffic to the LAN from the remote stack
    step 4. Verify traffic is NOT forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-6: Inbound packets MUST NOT be forwarded if the source address in
    their outer IPv6 header has a global unicast prefix assigned for use
    by globally reachable nodes on the interior network.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-7 rfc6092.tcl rfc6092_rec_7 Section 3.1: Stateless filters, REC-7


    step 1. Send traffic from the LAN to the WAN with a unique-local source address
    step 2. Verify traffic is not forwarded to the WAN
    step 3. Initiate a new UDP session with the device to allow inbound traffic
    step 4. Configure a new stack on the WAN with a unique-local prefix as the source
    step 5. Send traffic from this new stack to the LAN
    step 6. Verify traffic is not forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-7: By DEFAULT, packets with unique local source and/or
    destination addresses [RFC4193] SHOULD NOT be forwarded to or from
    the exterior network.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-8 rfc6092.tcl rfc6092_rec_8 Section 3.1: Stateless filters, REC-8


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT's
            global IPv6 address
    step 2. Verify that the query is received by either the primary or backup
            DNS server on the WAN
    step 3. Verify that the DNS response is received by the LAN client
    step 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to the
            DUT's global IPv6 address
    step 5. Verify that a DNS response is not received by the remote host on the
            WAN that initiated the original request


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-8: By DEFAULT, inbound DNS queries received on exterior
    interfaces MUST NOT be processed by any integrated DNS resolving
    server.

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

Test Module Name Synopsis
Section 3.1: Stateless filters, REC-9 rfc6092.tcl rfc6092_rec_9 Section 3.1: Stateless filters, REC-9


    step 1. Start new DHCPv6 client on WAN interface
    step 2. Verify new client does not obtain an IPv6 address via DHCPv6 from
            the DUT
    step 3. Send three pings from LAN to WAN to verify that the DUT is still
            operating properly


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters

    Certain kinds of IPv6 packets MUST NOT be forwarded in either
    direction by residential Internet gateways regardless of network
    state.  These include packets with multicast source addresses,
    packets to destinations with certain non-routable and/or reserved
    prefixes, and packets with deprecated extension headers.

    Other stateless filters are recommended to implement ingress
    filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
    boundaries, and to isolate certain local network services from the
    public Internet.

    REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
    exterior interfaces MUST NOT be processed by any integrated DHCPv6
    server or relay agent.

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

Test Module Name Synopsis
Section 3.2.1: Internet Control and Management, REC-10 rfc6092.tcl rfc6092_rec_10 Section 3.2.1: Internet Control and Management, REC-10


    step 1. Send UDP message from LAN client to WAN server
    step 2. Verify UDP message is received by WAN server
    step 3. Send ICMPv6 Destination Unreachable message from WAN
            server to LAN client containing a different UDP port than
            the UDP message sent by the LAN client in step 1.
    step 4. Verify the DUT does not forward the ICMPv6 message to the
            LAN client
    step 5. Repeat steps 3 and 4 with an ICMPv6 Packet Too Big
            message


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.1: Internet Control and Management

    Recommendations for filtering ICMPv6 messages in firewall devices are
    described separately in [RFC4890] and apply to residential gateways,
    with the additional recommendation that incoming "Destination
    Unreachable" and "Packet Too Big" error messages that don't match any
    filtering state should be dropped.

    REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
    Unreachable" and "Packet Too Big" messages containing IP headers that
    do not match generic upper-layer transport state records.

    https://tools.ietf.org/html/rfc6092#section-3.2.1

Test Module Name Synopsis
Section 3.2.2: Upper Layer Transport Protocols, REC-12 rfc6092.tcl rfc6092_rec_12 Section 3.2.2: Upper Layer Transport Protocols, REC-12


    step 1. Initiate LAN client UDP ping to WAN server
    step 2. Verify LAN client receives response
    step 3. Wait 115 seconds
    step 4. Initiate WAN client UDP ping on same connection as step 1
            from WAN side
    step 5. Verify WAN client receives a response


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.2: Upper Layer Transport Protocols

    Residential IPv6 gateways are not expected to prohibit the use of
    applications to be developed using future upper-layer transport
    protocols.  In particular, transport protocols not otherwise
    discussed in subsequent sections of this document are expected to be
    treated consistently, i.e., as having connection-free semantics and
    no special requirements to inspect the transport headers.

    In general, upper-layer transport filter state records are expected
    to be created when an interior endpoint sends a packet to an exterior
    address.  The filter allocates (or reuses) a record for the duration
    of communications, with an idle timer to delete the state record when
    no further communications are detected.

    One key aspect of how a packet filter behaves is the way it evaluates
    the exterior address of an endpoint when applying a filtering rule.
    A gateway is said to have "endpoint-independent filtering" behavior
    when the exterior address is not evaluated when matching a packet
    with a flow.  A gateway is said to have "address-dependent filtering"
    behavior when the exterior address of a packet is required to match
    the exterior address for its flow.

    REC-12: Filter state records for generic upper-layer transport
    protocols MUST NOT be deleted or recycled until an idle timer not
    less than two minutes has expired without having forwarded a packet
    matching the state in some configurable amount of time.  By DEFAULT,
    the idle timer for such state records is five minutes.

    https://tools.ietf.org/html/rfc6092#section-3.2.2

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-14 rfc6092.tcl rfc6092_rec_14 Section 3.2.3: UDP Filters, REC-14


    step 1. Initiate LAN client UDP ping to WAN server
    step 2. Verify LAN client receives response
    step 3. Wait natUdpTimeout - 10 seconds
    step 4. Send UDP ping on same connection from WAN side
    step 5. Verify WAN client receives response


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    "Network Address Translation (NAT) Behavioral Requirements for
    Unicast UDP" [RFC4787] defines the terminology and best current
    practice for stateful filtering of UDP applications in IPv4 with NAT,
    which serves as the model for behavioral requirements for simple UDP
    security in IPv6 gateways, notwithstanding the requirements related
    specifically to network address translation.

    An interior endpoint initiates a UDP flow through a stateful packet
    filter by sending a packet to an exterior address.  The filter
    allocates (or reuses) a filter state record for the duration of the
    flow.  The state record defines the interior and exterior IP
    addresses and ports used between all packets in the flow.

    State records for UDP flows remain active while they are in use and
    are only abandoned after an idle period of some time.

    REC-14: A state record for a UDP flow where both source and
    destination ports are outside the well-known port range
    (ports 0-1023) MUST NOT expire in less than two minutes of idle time.
    The value of the UDP state record idle timer MAY be configurable.
    The DEFAULT is five minutes.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-16 rfc6092.tcl rfc6092_rec_16 Section 3.2.3: UDP Filters, REC-16


    step 1. Initiate a LAN client UDP ping to WAN server
    step 2. Verify LAN client receives response
    step 3. Wait natUdpTimeout/2 seconds
    step 4. Initiate a LAN client UDP ping to WAN server
    step 5. Verify LAN client receives a response
    step 6. Wait natUdpTimeout - 10 seconds
    step 7. Initiate a WAN server UDP ping to LAN client
    step 8. Verify WAN server received a response


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    As [RFC4787] notes, outbound refresh is necessary for allowing the
    interior endpoint to keep the state record alive.  Inbound refresh
    may be useful for applications with no outbound UDP traffic.
    However, allowing inbound refresh can allow an attacker in the
    exterior or a misbehaving application to keep a state record alive
    indefinitely.  This could be a security risk.  Also, if the process
    is repeated with different ports, over time, it could use up all the
    state record memory and resources in the filter.

    REC-16: A state record for a UDP flow MUST be refreshed when a packet
    is forwarded from the interior to the exterior, and it MAY be
    refreshed when a packet is forwarded in the reverse direction.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-17 rfc6092.tcl rfc6092_rec_17 Section 3.2.3: UDP Filters, REC-17


    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

    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 IPv6 address and same source port
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv6 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 IPv6 address and same source port
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using a different source port but same IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv6 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 the same source port and IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    As described in Section 5 of [RFC4787], the connection-free semantics
    of UDP pose a difficulty for packet filters in trying to recognize
    which packets comprise an application flow and which are unsolicited.
    Various strategies have been used in IPv4/NAT gateways with differing
    effects.

    REC-17: If application transparency is most important, then a
    stateful packet filter SHOULD have "endpoint-independent filtering"
    behavior for UDP.  If a more stringent filtering behavior is most
    important, then a filter SHOULD have "address-dependent filtering"
    behavior.  The filtering behavior MAY be an option configurable by
    the network administrator, and it MAY be independent of the filtering
    behavior for TCP and other protocols.  Filtering behavior SHOULD be
    endpoint independent by DEFAULT in gateways intended for provisioning
    without service-provider management.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-18 rfc6092.tcl rfc6092_rec_18 Section 3.2.3: UDP Filters, REC-18


    step 1. Send IPv6 UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
    step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
    step 4. Send IPv6 UDP packet from LAN to WAN
    step 5. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
    step 6. Verify ICMPv6 Too Big message is received on the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    Application mechanisms may depend on the reception of ICMPv6 error
    messages triggered by the transmission of UDP messages.  One such
    mechanism is path MTU discovery [RFC1981].

    REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    UDP headers that match the flow state record.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-19 rfc6092.tcl rfc6092_rec_19 Section 3.2.3: UDP Filters, REC-19


    step 1. Send IPv6 UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
    step 3. Verify ICMPv6 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 IPv6 firewall state is still present
    step 6. Send IPv6 UDP packet from LAN to WAN
    step 7. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
    step 8. Verify ICMPv6 Too Big message is received on the LAN
    step 9. Send UDP response from WAN to LAN
    step 10. Verify UDP response is received on LAN since IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    Application mechanisms may depend on the reception of ICMPv6 error
    messages triggered by the transmission of UDP messages.  One such
    mechanism is path MTU discovery [RFC1981].

    REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a UDP flow.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.3: UDP Filters, REC-20 rfc6092.tcl rfc6092_rec_20 Section 3.2.3: UDP Filters, REC-20


    step 1. Forward UDP packet from LAN to WAN
    step 2. Verify UDP packet in step 1 is forwarded to the WAN
    step 3. Forward matching UDP-Lite packet from WAN to LAN
    step 4. Verify UDP-Lite packet in step 3 is not forwarded to the
            LAN
    step 5. Forward UDP-Lite packet from LAN to WAN
    step 6. Verify UDP-Lite packet in step 5 is forwarded to the WAN
    step 7. Forward matching UDP packet from WAN to LAN
    step 8. Verify UDP packet in step 7 is not forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters

    Application mechanisms may depend on the reception of ICMPv6 error
    messages triggered by the transmission of UDP messages.  One such
    mechanism is path MTU discovery [RFC1981].

    REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
    UDP flows, except that the upper-layer transport protocol identifier
    for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT
    match UDP-Lite state records, and vice versa.

    https://tools.ietf.org/html/rfc6092#section-3.2.3

Test Module Name Synopsis
Section 3.2.4: IPSec and Internet Key Exchange (IKE), REC-21 rfc6092.tcl rfc6092_rec_21 Section 3.2.4: IPSec and Internet Key Exchange (IKE), REC-21


    step 1. Forward UDP packet with IPv6 Authentication Header from
            LAN to WAN
    step 2. Verify UDP packet is forwarded to the WAN
    step 3. Forward UDP packet with IPv6 Authentication Header from
            WAN to LAN
    step 4. Verify UDP packet is forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.4: IPSec and Internet Key Exchange (IKE)

    The Internet Protocol security (IPsec) suite offers greater
    flexibility and better overall security than the simple security of
    stateful packet filtering at network perimeters.  Therefore,
    residential IPv6 gateways need not prohibit IPsec traffic flows.

    REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
    prohibit the forwarding of packets, to and from legitimate node
    addresses, with destination extension headers of type "Authentication
    Header (AH)" [RFC4302] in their outer IP extension header chain.

    https://tools.ietf.org/html/rfc6092#section-3.2.4

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-31 rfc6092.tcl rfc6092_rec_31 Section 3.3.1: TCP Filters, REC-31


    step 1. Initiate an outbound TCP session from LAN client to WAN
            server
    step 2. Verify session initiation is successful
    step 3. Terminate TCP session from LAN side
    step 4. Verify session is terminated successfully

    NOTE: This test case only verifies that the normal TCP 3-way
    handshake mode is supported.


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    An interior endpoint initiates a TCP flow through a stateful packet
    filter by sending a SYN packet.  The filter allocates (or reuses) a
    filter state record for the flow.  The state record defines the
    interior and exterior IP addresses and ports used for forwarding all
    packets for that flow.

    Some peer-to-peer applications use an alternate method of connection
    initiation termed "simultaneous-open" ([RFC0793], Figure 8) to
    traverse stateful filters.  In the simultaneous-open mode of
    operation, both peers send SYN packets for the same TCP flow.  The
    SYN packets cross in the network.  Upon receiving the other end's SYN
    packet, each end responds with a SYN-ACK packet, which also cross in
    the network.  The connection is established at each endpoint once the
    SYN-ACK packets are received.

    To provide stateful packet filtering service for TCP, it is necessary
    for a filter to receive, process, and forward all packets for a flow
    that conform to valid transitions of the TCP state machine
    ([RFC0793], Figure 6).

    REC-31: All valid sequences of TCP packets (defined in [RFC0793])
    MUST be forwarded for outbound flows and explicitly permitted inbound
    flows.  In particular, both the normal TCP 3-way handshake mode of
    operation and the simultaneous-open mode of operation MUST be
    supported.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-32 rfc6092.tcl rfc6092_rec_32 Section 3.3.1: TCP Filters, REC-32


    step 1. Configure TCP LAN client and TCP WAN server to use a TCP
            window size of 10 bytes
    step 2. Configure LAN client and WAN server to be in an
            established TCP session
    step 3. Transmit 20 bytes of TCP data from LAN client to WAN
            server
    step 4. Verify WAN server receives 20 bytes of TCP data
    step 5. Transmit 20 bytes of TCP data from WAN server to LAN
            client
    step 6. Verify LAN client receives 20 bytes of TCP data
    step 7. Terminate TCP session from LAN side


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    It is possible to reconstruct enough of the state of a TCP flow to
    allow forwarding between an interior and exterior node, even when the
    filter starts operating after TCP enters the established state.  In
    this case, because the filter has not seen the TCP window-scale
    option, it is not possible for the filter to enforce the TCP window
    invariant by dropping out-of-window segments.

    REC-32: The TCP window invariant MUST NOT be enforced on flows for
    which the filter did not detect whether the window-scale option (see
    [RFC1323]) was sent in the 3-way handshake or simultaneous-open.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-33 rfc6092.tcl rfc6092_rec_33 Section 3.3.1: TCP Filters, REC-33


    step 1. Forward a TCP 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

    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 IPv6 address and same source port
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv6 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 IPv6 address and same source port
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using a different source port but same IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv6 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 the same source port and IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    A stateful filter can allow an existing state record to be reused by
    an externally initiated flow if its security policy permits.  Several
    different policies are possible, as described in [RFC4787] and
    extended in [RFC5382].

    REC-33: If application transparency is most important, then a
    stateful packet filter SHOULD have "endpoint-independent filtering"
    behavior for TCP.  If a more stringent filtering behavior is most
    important, then a filter SHOULD have "address-dependent filtering"
    behavior.  The filtering behavior MAY be an option configurable by
    the network administrator, and it MAY be independent of the filtering
    behavior for UDP and other protocols.  Filtering behavior SHOULD be
    endpoint independent by DEFAULT in gateways intended for provisioning
    without service-provider management.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-34 rfc6092.tcl rfc6092_rec_34 Section 3.3.1: TCP Filters, REC-34


    step 1. Initiate an unsolicited inbound TCP session from WAN
            server to LAN client
    step 2. Verify WAN server receives an ICMPv6 Destination
            Unreachable message with error code 1


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    If an inbound SYN packet is filtered, either because a corresponding
    state record does not exist or because of the filter's normal
    behavior, a filter has two basic choices: to discard the packet
    silently, or to signal an error to the sender.  Signaling an error
    through ICMPv6 messages allows the sender to detect that the SYN did
    not reach the intended destination.  Discarding the packet, on the
    other hand, allows applications to perform simultaneous-open more
    reliably.  A more detailed discussion of this issue can be found in
    [RFC5382], but the basic outcome of it is that filters need to wait
    on signaling errors until simultaneous-open will not be impaired.

    REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
    "Destination Unreachable" error code 1 (Communication with
    destination administratively prohibited) to any unsolicited inbound
    SYN packet after waiting at least 6 seconds without first forwarding
    the associated outbound SYN or SYN/ACK from the interior peer.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-35 rfc6092.tcl rfc6092_rec_35 Section 3.3.1: TCP Filters, REC-35


    step 1. Initiate an outbound TCP session from LAN client to WAN
            server
    step 2. Verify session initiation is successful
    step 3. Allow TCP session to idle for 2 hours
    step 4. Transfer TCP data from WAN server to LAN client
    step 5. Verify LAN client receives TCP data
    step 6. Terminate TCP session from LAN side


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    A TCP filter maintains state associated with in-progress connections
    and established flows.  Because of this, a filter is susceptible to a
    resource-exhaustion attack whereby an attacker (or virus) on the
    interior attempts to cause the filter to exhaust its capacity for
    creating state records.  To defend against such attacks, a filter
    needs to abandon unused state records after a sufficiently long
    period of idleness.

    A common method used for TCP filters in IPv4/NAT gateways is to
    abandon preferentially flow state records for crashed endpoints,
    followed by closed flows and partially open flows.  A gateway can
    check if an endpoint for a session has crashed by sending a TCP keep-
    alive packet on behalf of the other endpoint and receiving a TCP RST
    packet in response.  If the gateway cannot determine whether the
    endpoint is active, then the associated state record needs to be
    retained until the TCP flow has been idle for some time.

      Note: An established TCP flow can stay idle (but live)
      indefinitely; hence, there is no fixed value for an idle-timeout
      that accommodates all applications.  However, a large idle-timeout
      motivated by recommendations in [RFC1122] and [RFC4294] can reduce
      the chances of abandoning a live flow.

    TCP flows can stay in the established phase indefinitely without
    exchanging packets.  Some end-hosts can be configured to send keep-
    alive packets on such idle flows; by default, such packets are sent
    every two hours, if enabled [RFC1122].  Consequently, a filter that
    waits for slightly over two hours can detect idle flows with keep-
    alive packets being sent at the default rate.  TCP flows in the
    partially open or closing phases, on the other hand, can stay idle
    for at most four minutes while waiting for in-flight packets to be
    delivered [RFC1122].

    The "established flow idle-timeout" for a stateful packet filter is
    defined as the minimum time a TCP flow in the established phase must
    remain idle before the filter considers the associated state record a
    candidate for collection.  The "transitory flow idle-timeout" for a
    filter is defined as the minimum time a TCP flow in the partially
    open or closing phases must remain idle before the filter considers
    the associated state record a candidate for collection.  TCP flows in
    the TIME-WAIT state are not affected by the "transitory flow idle-
    timeout" parameter.

    REC-35: If a gateway cannot determine whether the endpoints of a TCP
    flow are active, then it MAY abandon the state record if it has been
    idle for some time.  In such cases, the value of the "established
    flow idle-timeout" MUST NOT be less than two hours four minutes, as
    discussed in [RFC5382].  The value of the "transitory flow idle-
    timeout" MUST NOT be less than four minutes.  The value of the idle-
    timeouts MAY be configurable by the network administrator.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-36 rfc6092.tcl rfc6092_rec_36 Section 3.3.1: TCP Filters, REC-36


    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
    step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
    step 4. Send an ICMPv6 Packet Too Big message from the WAN for the connection
    step 5. Verify ICMPv6 Packet Too Big message is received on the LAN


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    Behavior for handling RST packets or TCP flows in the TIME-WAIT state
    is left unspecified.  A gateway MAY hold state for a flow in the
    TIME-WAIT state to accommodate retransmissions of the last ACK.
    However, since the TIME-WAIT state is commonly encountered by
    interior endpoints properly closing the TCP flow, holding state for a
    closed flow can limit the throughput of flows through a gateway with
    limited resources.  [RFC1337] discusses hazards associated with
    TIME-WAIT assassination.

    The handling of non-SYN packets for which there is no active state
    record is left unspecified.  Such packets can be received if the
    gateway abandons a live flow, or abandons a flow in the TIME-WAIT
    state before the four-minute TIME-WAIT period expires.  The decision
    either to discard or to respond with an ICMPv6 "Destination
    Unreachable" error code 1 (Communication with destination
    administratively prohibited) is left up to the implementation.

    Behavior for notifying endpoints when abandoning live flows is left
    unspecified.  When a gateway abandons a live flow, for example due to
    a timeout expiring, the filter MAY send a TCP RST packet to each
    endpoint on behalf of the other.  Sending a RST notification allows
    endpoint applications to recover more quickly; however, notifying
    endpoints might not always be possible if, for example, state records
    are lost due to power interruption.

    Several TCP mechanisms depend on the reception of ICMPv6 error
    messages triggered by the transmission of TCP segments.  One such
    mechanism is path MTU discovery, which is required for correct
    operation of TCP.

    REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
    "Destination Unreachable" and "Packet Too Big" messages containing
    TCP headers that match the flow state record.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.1: TCP Filters, REC-37 rfc6092.tcl rfc6092_rec_37 Section 3.3.1: TCP Filters, REC-37


    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
    step 3. Send TCP data segment from WAN to LAN for the session
    step 4. Verify TCP data segment is received on LAN since IPv6 firewall state is still present
    step 5. Send an ICMPv6 Packet Too Big message from the WAN for the connection
    step 6. Send TCP data segment from WAN to LAN for the session
    step 7. Verify TCP data segment is received on LAN since IPv6 firewall state is still present


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters

    Behavior for handling RST packets or TCP flows in the TIME-WAIT state
    is left unspecified.  A gateway MAY hold state for a flow in the
    TIME-WAIT state to accommodate retransmissions of the last ACK.
    However, since the TIME-WAIT state is commonly encountered by
    interior endpoints properly closing the TCP flow, holding state for a
    closed flow can limit the throughput of flows through a gateway with
    limited resources.  [RFC1337] discusses hazards associated with
    TIME-WAIT assassination.

    The handling of non-SYN packets for which there is no active state
    record is left unspecified.  Such packets can be received if the
    gateway abandons a live flow, or abandons a flow in the TIME-WAIT
    state before the four-minute TIME-WAIT period expires.  The decision
    either to discard or to respond with an ICMPv6 "Destination
    Unreachable" error code 1 (Communication with destination
    administratively prohibited) is left up to the implementation.

    Behavior for notifying endpoints when abandoning live flows is left
    unspecified.  When a gateway abandons a live flow, for example due to
    a timeout expiring, the filter MAY send a TCP RST packet to each
    endpoint on behalf of the other.  Sending a RST notification allows
    endpoint applications to recover more quickly; however, notifying
    endpoints might not always be possible if, for example, state records
    are lost due to power interruption.

    Several TCP mechanisms depend on the reception of ICMPv6 error
    messages triggered by the transmission of TCP segments.  One such
    mechanism is path MTU discovery, which is required for correct
    operation of TCP.

    REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for a TCP flow.

    https://tools.ietf.org/html/rfc6092#section-3.3.1

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-38 rfc6092.tcl rfc6092_rec_38 Section 3.3.2: SCTP Filters, REC-38


    step 1. Initiate SCTP association from LAN client to WAN server
    step 2. Verify association initiation is successful
    step 3. Terminate SCTP association from LAN side
    step 4. Verify association is terminated successful

    NOTE: This test case only verifies that the normal SCTP
    association establishment is supported.


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
    can be terminated at multiple network addresses, IPv6 simple security
    functions cannot achieve full transparency for SCTP applications.  In
    multipath traversal scenarios, full transparency requires
    coordination between all the packet filter processes in the various
    paths between the endpoint network addresses.  Such coordination is
    not "simple", and it is, therefore, beyond the scope of this
    recommendation.

    However, some SCTP applications are capable of tolerating the
    inherent unipath restriction of IPv6 simple security, even in
    multipath traversal scenarios.  They expect connection-oriented
    filtering behaviors similar to those for TCP, but at the level of
    SCTP associations, not stream connections.  This section describes
    specific recommendations for SCTP filtering for such traversal
    scenarios.

    An interior endpoint initiates SCTP associations through a stateful
    packet filter by sending a packet comprising a single INIT chunk.
    The filter allocates (or reuses) a filter state record for the
    association.  The state record defines the interior and exterior IP
    addresses and the observed verification tag used for forwarding
    packets in that association.

    Some peer-to-peer SCTP applications use an alternate method of
    association initiation, termed "simultaneous-open", to traverse
    stateful filters.  In the simultaneous-open mode of operation, both
    peers send INIT chunks at the same time to establish an association.
    Upon receiving the other end's INIT chunk, each end responds with an
    INIT-ACK packet, which is expected to traverse the same path in
    reverse.  Because only one SCTP association may exist between any two
    network addresses, one of the peers in the simultaneous-open mode of
    operation will send an ERROR or ABORT chunk along with the INIT-ACK
    chunk.  The association is established at each endpoint once an
    INIT-ACK chunk without an ERROR or ABORT chunk is received at one
    end.

    To provide stateful packet filtering service for SCTP, it is
    necessary for a filter to receive, process, and forward all packets
    for an association that conform to valid transitions of the SCTP
    state machine ([RFC4960], Figure 3).

    REC-38: All valid sequences of SCTP packets (defined in [RFC4960])
    MUST be forwarded for outbound associations and explicitly permitted
    inbound associations.  In particular, both the normal SCTP
    association establishment and the simultaneous-open mode of operation
    MUST be supported.

    https://tools.ietf.org/html/rfc6092#section-3.3.2

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-39 rfc6092.tcl rfc6092_rec_39 Section 3.3.2: SCTP Filters, REC-39


    step 1. Initiate an unsolicited inbound SCTP association from WAN
            client to LAN server
    step 2. Verify WAN client receives ICMPv6 Destination Unreachable
            message with error code 1


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    If an inbound INIT packet is filtered, either because a corresponding
    state record does not exist or because of the filter's normal
    behavior, a filter has two basic choices: to discard the packet
    silently, or to signal an error to the sender.  Signaling an error
    through ICMPv6 messages allows the sender to detect that the INIT
    packet did not reach the intended destination.  Discarding the
    packet, on the other hand, allows applications to perform
    simultaneous-open more reliably.  Delays in signaling errors can
    prevent the impairment of the simultaneous-open mode of operation.

    REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6
    "Destination Unreachable" error code 1 (Communication with
    destination administratively prohibited), to any unsolicited inbound
    INIT packet after waiting at least 6 seconds without first forwarding
    the associated outbound INIT from the interior peer.

    https://tools.ietf.org/html/rfc6092#section-3.3.2

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-40, Part A rfc6092.tcl rfc6092_rec_40a Section 3.3.2: SCTP Filters, REC-40, Part A


    step 1. Initiate an outbound SCTP association from LAN client to
            WAN server
    step 2. Verify association initiation is successful
    step 3. Allow association to idle for 2 hours
    step 4. Transmit SCTP data from WAN server to LAN client
    step 5. Verify LAN client receives SCTP data
    step 6. Terminate SCTP association from LAN client
    step 7. Verify association is terminated successfully


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    An SCTP filter maintains state associated with in-progress and
    established associations.  Because of this, a filter is susceptible
    to a resource-exhaustion attack whereby an attacker (or virus) on the
    interior attempts to cause the filter to exhaust its capacity for
    creating state records.  To defend against such attacks, a filter
    needs to abandon unused state records after a sufficiently long
    period of idleness.

    A common method used for TCP filters in IPv4/NAT gateways is to
    abandon preferentially sessions for crashed endpoints, followed by
    closed associations and partially opened associations.  A similar
    method is an option for SCTP filters in IPv6 gateways.  A gateway can
    check if an endpoint for an association has crashed by sending
    HEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If the
    gateway cannot determine whether the endpoint is active, then the
    associated state record needs to be retained until the SCTP
    association has been idle for some time.

      Note: An established SCTP association can stay idle (but live)
      indefinitely; hence, there is no fixed value of an idle-timeout
      that accommodates all applications.  However, a large idle-timeout
      motivated by recommendations in [RFC4294] can reduce the chances
      of abandoning a live association.

    SCTP associations can stay in the ESTABLISHED state indefinitely
    without exchanging packets.  Some end-hosts can be configured to send
    HEARTBEAT chunks on such idle associations, but [RFC4960] does not
    specify (or even suggest) a default time interval.  A filter that
    waits for slightly over two hours can detect idle associations with
    HEARTBEAT packets being sent at the same rate as most hosts use for
    TCP keep-alive, which is a reasonably similar system for this
    purpose.  SCTP associations in the partially open or closing states,
    on the other hand, can stay idle for at most four minutes while
    waiting for in-flight packets to be delivered (assuming the suggested
    SCTP protocol parameter values in Section 15 of [RFC4960]).

    The "established association idle-timeout" for a stateful packet
    filter is defined as the minimum time an SCTP association in the
    established phase must remain idle before the filter considers the
    corresponding state record a candidate for collection.  The
    "transitory association idle-timeout" for a filter is defined as the
    minimum time an SCTP association in the partially open or closing
    phases must remain idle before the filter considers the corresponding
    state record a candidate for collection.

    REC-40: If a gateway cannot determine whether the endpoints of an
    SCTP association are active, then it MAY abandon the state record if
    it has been idle for some time.  In such cases, the value of the
    "established association idle-timeout" MUST NOT be less than
    two hours four minutes.

    https://tools.ietf.org/html/rfc6092#section-3.3.2

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-40, Part B rfc6092.tcl rfc6092_rec_40b Section 3.3.2: SCTP Filters, REC-40, Part B


    step 1. Disable SCTP WAN server on port A
    step 2. Initiate an outbound SCTP association from LAN client to
            WAN server on port A
    step 3. Wait 230 seconds
    step 4. Enable SCTP WAN server on port A
    step 5. Wait 5 seconds
    step 6. Verify association initiation from step 2 is successful
    step 7. Terminate SCTP association from LAN side
    step 8. Verify association is terminated successful


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    An SCTP filter maintains state associated with in-progress and
    established associations.  Because of this, a filter is susceptible
    to a resource-exhaustion attack whereby an attacker (or virus) on the
    interior attempts to cause the filter to exhaust its capacity for
    creating state records.  To defend against such attacks, a filter
    needs to abandon unused state records after a sufficiently long
    period of idleness.

    A common method used for TCP filters in IPv4/NAT gateways is to
    abandon preferentially sessions for crashed endpoints, followed by
    closed associations and partially opened associations.  A similar
    method is an option for SCTP filters in IPv6 gateways.  A gateway can
    check if an endpoint for an association has crashed by sending
    HEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If the
    gateway cannot determine whether the endpoint is active, then the
    associated state record needs to be retained until the SCTP
    association has been idle for some time.

      Note: An established SCTP association can stay idle (but live)
      indefinitely; hence, there is no fixed value of an idle-timeout
      that accommodates all applications.  However, a large idle-timeout
      motivated by recommendations in [RFC4294] can reduce the chances
      of abandoning a live association.

    SCTP associations can stay in the ESTABLISHED state indefinitely
    without exchanging packets.  Some end-hosts can be configured to send
    HEARTBEAT chunks on such idle associations, but [RFC4960] does not
    specify (or even suggest) a default time interval.  A filter that
    waits for slightly over two hours can detect idle associations with
    HEARTBEAT packets being sent at the same rate as most hosts use for
    TCP keep-alive, which is a reasonably similar system for this
    purpose.  SCTP associations in the partially open or closing states,
    on the other hand, can stay idle for at most four minutes while
    waiting for in-flight packets to be delivered (assuming the suggested
    SCTP protocol parameter values in Section 15 of [RFC4960]).

    The "established association idle-timeout" for a stateful packet
    filter is defined as the minimum time an SCTP association in the
    established phase must remain idle before the filter considers the
    corresponding state record a candidate for collection.  The
    "transitory association idle-timeout" for a filter is defined as the
    minimum time an SCTP association in the partially open or closing
    phases must remain idle before the filter considers the corresponding
    state record a candidate for collection.

    REC-40: If a gateway cannot determine whether the endpoints of an
    SCTP association are active, then it MAY abandon the state record if
    it has been idle for some time.  In such cases, the value of the
    "established association idle-timeout" MUST NOT be less than
    two hours four minutes.

    https://tools.ietf.org/html/rfc6092#section-3.3.2

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-41 rfc6092.tcl rfc6092_rec_41 Section 3.3.2: SCTP Filters, REC-41


    step 1. Initiate an outbound SCTP association from LAN client to
            WAN server
    step 2. Verify association initiation is successful
    step 3. Forward an ICMPv6 Destination Unreachable message from LAN
            client to WAN server
    step 4. Verify message is received by WAN server
    step 5. Forward an ICMPv6 Destination Unreachable message from WAN
            server to LAN client
    step 6. Verify message is received by LAN client
    step 7. Forward an ICMPv6 Packet Too Big message from LAN client
            to WAN server
    step 8. Verify message is received by WAN server
    step 9. Forward an ICMPv6 Packet Too Big message from WAN server
            to LAN client
    step 10. Verify message is received by LAN client
    step 11. Terminate SCTP association from LAN side
    step 12. Verify association is terminated successful


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    Behavior for handling ERROR and ABORT packets is left unspecified.  A
    gateway MAY hold state for an association after its closing phases
    have completed to accommodate retransmissions of its final SHUTDOWN
    ACK packets.  However, holding state for a closed association can
    limit the throughput of associations traversing a gateway with
    limited resources.  The discussion in [RFC1337] regarding the hazards
    of TIME-WAIT assassination is relevant.

    The handling of inbound non-INIT packets for which there is no active
    state record is left unspecified.  Such packets can be received if
    the gateway abandons a live flow, or abandons an association in the
    closing states before the transitory association idle-timeout
    expires.  The decision either to discard or to respond with an ICMPv6
    "Destination Unreachable" error code 1 (Communication with
    destination administratively prohibited) is left to the
    implementation.

    Behavior for notifying endpoints when abandoning live associations is
    left unspecified.  When a gateway abandons a live association, for
    example due to a timeout expiring, the filter MAY send an ABORT
    packet to each endpoint on behalf of the other.  Sending an ABORT
    notification allows endpoint applications to recover more quickly;
    however, notifying endpoints might not always be possible if, for
    example, state records are lost due to power interruption.

    Several SCTP mechanisms depend on the reception of ICMPv6 error
    messages triggered by the transmission of SCTP packets.

    REC-41: If a gateway forwards an SCTP association, it MUST also
    forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
    messages containing SCTP headers that match the association state
    record.

    https://tools.ietf.org/html/rfc6092#section-3.3.2

Test Module Name Synopsis
Section 3.3.2: SCTP Filters, REC-42 rfc6092.tcl rfc6092_rec_42 Section 3.3.2: SCTP Filters, REC-42


    step 1. Initiate an outbound SCTP association from LAN client to WAN
            server
    step 2. Verify association initiation is successful
    step 3. Forward an ICMPv6 Destination Unreachable message from LAN
            client to WAN server
    step 4. Transmit SCTP data from WAN server to LAN client
    step 5. Verify LAN client receives SCTP data
    step 6. Verify SCTP association is still established
    step 7. Forward an ICMPv6 Destination Unreachable message from WAN
            server to LAN client
    step 8. Transmit SCTP data from WAN server to LAN client
    step 9. Verify LAN client receives SCTP data
    step 10. Verify SCTP association is still established
    step 11. Forward an ICMPv6 Packet Too Big message from LAN client
             to WAN server
    step 12. Transmit SCTP data from WAN server to LAN client
    step 13. Verify LAN client receives SCTP data
    step 14. Verify SCTP association is still established
    step 15. Forward an ICMPv6 Packet Too Big message from WAN server
             to LAN client
    step 16. Transmit SCTP data from WAN server to LAN client
    step 17. Verify LAN client receives SCTP data
    step 18. Verify SCTP association is still established
    step 19. Transmit SCTP data from WAN server to LAN client
    step 20. Verify LAN client receives SCTP data
    step 21. Verify SCTP association is still established
    step 22. Terminate SCTP association from LAN side
    step 23. Verify association is terminated successful


    References:

    IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters

    Behavior for handling ERROR and ABORT packets is left unspecified.  A
    gateway MAY hold state for an association after its closing phases
    have completed to accommodate retransmissions of its final SHUTDOWN
    ACK packets.  However, holding state for a closed association can
    limit the throughput of associations traversing a gateway with
    limited resources.  The discussion in [RFC1337] regarding the hazards
    of TIME-WAIT assassination is relevant.

    The handling of inbound non-INIT packets for which there is no active
    state record is left unspecified.  Such packets can be received if
    the gateway abandons a live flow, or abandons an association in the
    closing states before the transitory association idle-timeout
    expires.  The decision either to discard or to respond with an ICMPv6
    "Destination Unreachable" error code 1 (Communication with
    destination administratively prohibited) is left to the
    implementation.

    Behavior for notifying endpoints when abandoning live associations is
    left unspecified.  When a gateway abandons a live association, for
    example due to a timeout expiring, the filter MAY send an ABORT
    packet to each endpoint on behalf of the other.  Sending an ABORT
    notification allows endpoint applications to recover more quickly;
    however, notifying endpoints might not always be possible if, for
    example, state records are lost due to power interruption.

    Several SCTP mechanisms depend on the reception of ICMPv6 error
    messages triggered by the transmission of SCTP packets.

    REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the
    state record for an SCTP association.

    https://tools.ietf.org/html/rfc6092#section-3.3.2


rip-ng.tcl

RIPng tests for LAN side of the router

Test Module Name Synopsis
Verify router sends RIPng update on LAN side rip-ng.tcl ipv6_ripng_1 Verify router sends RIPng update on LAN side


    step 1. Listen for RIPng reply from LAN side IP address of router
    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'.


    References:

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

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

Test Module Name Synopsis
Verify router learns new RIPng routes from LAN side RIPng router rip-ng.tcl ipv6_ripng_2 Verify router learns new RIPng routes from LAN side RIPng router


    step 1. Start new IPv6 client on LAN interface
    step 2. Announce new RIPng route with metric 1 from new IPv6 client
    step 3. Forward from original LAN client to IP address within the
            new RIPng route range
    step 4. Verify the packet is forwarded to the new IPv6 client


    References:

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

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

Test Module Name Synopsis
Verify router responds to RIPng requests on LAN interface rip-ng.tcl ipv6_ripng_5 Verify router responds to RIPng requests on LAN interface


    step 1. Send RIPng Request from new UDP src 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


    References:

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

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

Test Module Name Synopsis
Verify router selects RIPng route with lowest metric rip-ng.tcl ipv6_ripng_10 Verify router selects RIPng route with lowest metric


    step 1. Start 2 new IPv6 clients on LAN interface (R1 and R2)
    step 2. Announce new RIPng route with metric 10 from R1
    step 3. Announce same RIPng route with metric 9 from R2
    step 4. Forward from original LAN client to IP address within the
            new RIng route range
    step 5. Verify the packet is forwarded to R2


    References:

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

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

Test Module Name Synopsis
Verify router ignores routes with a metric of 16 rip-ng.tcl ipv6_ripng_12 Verify router ignores routes with a metric of 16


    step 1. Start new IPv6 client on LAN interface
    step 2. Announce new RIPng route with metric 16 from new IPv6 client
    step 3. Forward from original LAN client to IP address within the
            new RIPng route range
    step 4. Verify the packet is not forwarded to the new IPv6 client
    step 5. Verify the packet is forwarded to WAN side


    References:

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

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

Test Module Name Synopsis
Verify router uses split horizon or poison reverse for learned RIPng routes rip-ng.tcl ipv6_ripng_20 Verify router uses split horizon or poison reverse for learned RIPng routes


    step 1. Start new IPv6 client on LAN interface
    step 2. Announce new RIPng route with metric 1 from new IPv6 client
    step 3. Wait for new RIPng update
    step 4. Verify route is not announced (split horizon) or announced as
            unreachable (poison reverse)


    References:

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

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

Test Module Name Synopsis
Verify router announces default route on LAN side rip-ng.tcl ipv6_ripng_30 Verify router announces default route on LAN side


    step 1. Listen for RIPng updates for 1 minute
    step 2. Verify default route (/0) is announced as reachable


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.2: Addressing Considerations

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

Test Module Name Synopsis
Verify the maximum number of RIPng routes supported rip-ng.tcl ipv6_ripng_100 Verify the maximum number of RIPng routes supported


    step 1. Start a new IPv6 client on LAN interface
    step 2. Announce new RIPng routes with metric 1 from new IPv6 client

            NOTE: The 'ripMaxRoutes' variable in your configuration file
            determines the number of RIPng routes that are announced.

    step 3. Forward from original LAN client to IP address within the
            each new route range
    step 4. Verify packets are forwarded for each new route


    References:

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

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

Test Module Name Synopsis
Verify router learns new RIPng routes from WAN side RIPng router rip-ng.tcl ipv6_ripng_200 Verify router learns new RIPng routes from WAN side RIPng router


    step 1. Announce new RIPng route with metric 1 from WAN side
    step 2. Wait for new RIPng update on the LAN
    step 3. Verify new route is announced on the LAN
    step 4. Forward packet from LAN to new IP destination
    step 5. Verify packet is forwarded to WAN side

    NOTE: This test is only enabled when testvar ripAcceptWanUpdate
          is set to yes. The default is no.

          testvar ripAcceptWanUpdate yes


    References:

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

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

Test Module Name Synopsis
Verify router processes Next Hop RTEs in RIPng route list rip-ng.tcl ipv6_ripng_300 Verify router processes Next Hop RTEs in RIPng route list


    step 1. Start 2 new IPv6 clients on LAN interface (R1 and R2)
    step 2. Announce new RIPng route with metric 1 from R1 whose next hop is R2.
    step 3. Forward from original LAN client to IP address within the
            new RIng route range
    step 4. Verify the packet is forwarded to R2


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.1.1: Next Hop

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


mdns-v6.tcl

IPv6 mDNS related test cases

Test Module Name Synopsis
Verify DUT responds to IPv6 mDNS query of its hostname mdns-v6.tcl ipv6_mdns_10 Verify DUT responds to IPv6 mDNS query of its hostname


    step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
            AAAA record of the DUT's LAN hostname in the top-level
            domain 'local'.
    step 2. Verify the mDNS query succeeds and the response contains
            the DUT's IPv6 LAN address.

    NOTE: The DUT's expected LAN hostname is taken from the testvar
          lanHostname.


    References:

    IETF RFC 6762 "Multicast DNS" Section 3: Multicast DNS Names

    This document specifies that the DNS top-level domain ".local." is a
    special domain with special semantics, namely that any fully
    qualified name ending in ".local." is link-local, and names within
    this domain are meaningful only on the link where they originate.
    This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
    addresses in the FE80::/10 prefix, which are link-local and
    meaningful only on the link where they originate.

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

Test Module Name Synopsis
Verify DUT responds to IPv6 mDNS reverse query of its LAN IP mdns-v6.tcl ipv6_mdns_11 Verify DUT responds to IPv6 mDNS reverse query of its LAN IP


    step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
            reverse mapping of the DUT's IPv6 link-local address.
    step 2. Verify the mDNS query succeeds and the response contains
            the DUT's IPv6 LAN hostname in the top-level domain
            'local'.

    NOTE: The DUT's expected LAN hostname is taken from the testvar
          lanHostname.


    References:

    IETF RFC 6762 "Multicast DNS"

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

Test Module Name Synopsis
Verify DUT returns DNS-Service Discovery records for its web server over IPv6 mdns-v6.tcl ipv6_mdns_12 Verify DUT returns DNS-Service Discovery records for its web server over IPv6


    step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
            DUT's _services._dns-sd._udp.local PTR record.
    step 2. Verify that the mDNS query succeeds and the response
            contains the _http._tcp.local domain.
    step 3. Initiate a one-shot IPv6 mDNS query from the LAN for the
            DUT's _http._tcp.local PTR record.
    step 4. Verify that mDNS query succeeds.
    step 5. Initiate a one-shot IPv6 mDNS query from the LAN for the
            SRV record of the resource returned in step 4.
    step 6. Verify that the mDNS query succeeds and the response
            contains the DUT's management port and the domain
            LANHOSTNAME.local.
    step 7. Initiate a one-shot IPv6 mDNS query from the LAN for the
            AAAA record of LANHOSTNAME.local.
    step 8. Verify that the mDNS query succeeds and the response
            contains the DUT's IPv6 LAN address.
    step 9. Initiate an HTTP GET over IPv6 of the URL
            http://LANHOSTNAME:dutMgmtPort from the LAN.
    step 10. Verify that the HTTP GET succeeds.

    NOTE: The value of LANHOSTNAME is taken from the value of the
          lanHostname testvar.

    NOTE: The value of the DUT's management port is taken from the
          default insecure management port defined as the first port
          in the value of testvar dutMgmtPort.  Please read the
          documentation for dutMgmtPort for more information about the
          default insecure management port concept and its usage.


    References:

    IETF RFC 6762 "Multicast DNS" Section 3: Multicast DNS Names

    This document specifies that the DNS top-level domain ".local." is a
    special domain with special semantics, namely that any fully
    qualified name ending in ".local." is link-local, and names within
    this domain are meaningful only on the link where they originate.
    This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
    addresses in the FE80::/10 prefix, which are link-local and
    meaningful only on the link where they originate.

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

    IETF RFC 6763 "DNS-Based Service Discovery"

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

Test Module Name Synopsis
Verify DUT does not forward IPv6 LAN mDNS query onto the WAN mdns-v6.tcl ipv6_mdns_13 Verify DUT does not forward IPv6 LAN mDNS query onto the WAN


    step 1. Initiate a one-shot mDNS query from the LAN destined for
            IPv6 link-local multicast address ff02::fb.
    step 2. Verify that the mDNS query is not forwarded on the WAN.


    References:

    IETF RFC 3513 "Internet Protocol Version 6 (IPv6) Addressing Architecture" Section 2.7: Multicast Addresses

    Routers must not forward any multicast packets beyond of the scope
    indicated by the scop field in the destination multicast address.

    https://tools.ietf.org/html/rfc3513#section-2.7


http-v6.tcl

IPv6 HTTP related test cases

Test Module Name Synopsis
Verify IPv6 HTTP/1.0 GET connections http-v6.tcl ipv6_http_100 Verify IPv6 HTTP/1.0 GET connections


    step 1. Send an IPv6 HTTP/1.0 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.0 POST connections http-v6.tcl ipv6_http_101 Verify IPv6 HTTP/1.0 POST connections


    step 1. Send an IPv6 HTTP/1.0 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.0 HEAD connections http-v6.tcl ipv6_http_102 Verify IPv6 HTTP/1.0 HEAD connections


    step 1. Send an IPv6 HTTP/1.0 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.0 GET connections with large number of headers http-v6.tcl ipv6_http_103 Verify IPv6 HTTP/1.0 GET connections with large number of headers

    
    step 1. Send an IPv6 HTTP/1.0 GET request to the server with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 GET connections http-v6.tcl ipv6_http_200 Verify IPv6 HTTP/1.1 GET connections


    step 1. Send an IPv6 HTTP/1.1 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 POST connections http-v6.tcl ipv6_http_201 Verify IPv6 HTTP/1.1 POST connections


    step 1. Send an IPv6 HTTP/1.1 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 HEAD connections http-v6.tcl ipv6_http_202 Verify IPv6 HTTP/1.1 HEAD connections


    step 1. Send an IPv6 HTTP/1.1 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 PUT connections http-v6.tcl ipv6_http_203 Verify IPv6 HTTP/1.1 PUT connections


    step 1. Send an IPv6 HTTP/1.1 PUT request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 OPTIONS connections http-v6.tcl ipv6_http_204 Verify IPv6 HTTP/1.1 OPTIONS connections


    step 1. Send an IPv6 HTTP/1.1 OPTIONS request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 DELETE connections http-v6.tcl ipv6_http_205 Verify IPv6 HTTP/1.1 DELETE connections


    step 1. Send an IPv6 HTTP/1.1 DELETE request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 GET connections with large number of headers http-v6.tcl ipv6_http_206 Verify IPv6 HTTP/1.1 GET connections with large number of headers

    
    step 1. Send an IPv6 HTTP/1.1 GET request to the server with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 GET connections with chunked encoding http-v6.tcl ipv6_http_250 Verify IPv6 HTTP/1.1 GET connections with chunked encoding


    step 1. Send an IPv6 HTTP/1.1 GET request to server
    step 2. Verify HTTP response with chunked encoding is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 proxy idle timeout http-v6.tcl ipv6_http_260 Verify IPv6 HTTP/1.1 proxy idle timeout


    step 1. Configure HTTP server to delay sending responses by the
            time period specified by httpProxyIdleTimeout.
    step 2. Send an IPv6 HTTP/1.1 GET request to server
    step 3. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

    IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 5.5: Timeouts

    https://tools.ietf.org/html/rfc6202#section-5.5

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 WebSocket Ping message http-v6.tcl ipv6_http_300 Verify IPv6 HTTP/1.1 WebSocket Ping message


    step 1. Send an IPv6 HTTP/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket Ping opcode (0x9)
    step 4. Verify server side returns WebSocket Pong opcode (0xA)
    step 5. Close the WebSocket server


    References:

    IETF RFC 6455 "The WebSocket Protocol"

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

Test Module Name Synopsis
Verify IPv6 HTTP/1.1 WebSocket Text message http-v6.tcl ipv6_http_301 Verify IPv6 HTTP/1.1 WebSocket Text message


    step 1. Send an IPv6 HTTP/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket data message with text 
    step 4. Verify server side echos back the same text data
    step 5. Close the WebSocket server


    References:

    IETF RFC 6455 "The WebSocket Protocol"

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


https-v6.tcl

IPv6 HTTPS related test cases

Test Module Name Synopsis
Verify IPv6 HTTPS/1.0 GET connections https-v6.tcl ipv6_https_100 Verify IPv6 HTTPS/1.0 GET connections


    step 1. Send an IPv6 HTTPS/1.0 GET request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.0 POST connections https-v6.tcl ipv6_https_101 Verify IPv6 HTTPS/1.0 POST connections


    step 1. Send an IPv6 HTTPS/1.0 POST request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.0 HEAD connections https-v6.tcl ipv6_https_102 Verify IPv6 HTTPS/1.0 HEAD connections


    step 1. Send an IPv6 HTTPS/1.0 HEAD request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.0 GET connections with large number of headers https-v6.tcl ipv6_https_103 Verify IPv6 HTTPS/1.0 GET connections with large number of headers

    
    step 1. Send a IPv6 HTTPS/1.0 GET request to the server with the maximum allowed headers
    step 2. Verify the HTTPS response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 GET connections https-v6.tcl ipv6_https_200 Verify IPv6 HTTPS/1.1 GET connections


    step 1. Send an IPv6 HTTPS/1.1 GET request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 POST connections https-v6.tcl ipv6_https_201 Verify IPv6 HTTPS/1.1 POST connections


    step 1. Send an IPv6 HTTPS/1.1 POST request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 HEAD connections https-v6.tcl ipv6_https_202 Verify IPv6 HTTPS/1.1 HEAD connections


    step 1. Send an IPv6 HTTPS/1.1 HEAD request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 PUT connections https-v6.tcl ipv6_https_203 Verify IPv6 HTTPS/1.1 PUT connections


    step 1. Send an IPv6 HTTPS/1.1 PUT request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 OPTIONS connections https-v6.tcl ipv6_https_204 Verify IPv6 HTTPS/1.1 OPTIONS connections


    step 1. Send an IPv6 HTTPS/1.1 OPTIONS request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 DELETE connections https-v6.tcl ipv6_https_205 Verify IPv6 HTTPS/1.1 DELETE connections


    step 1. Send an IPv6 HTTPS/1.1 DELETE request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 GET connections with large number of headers https-v6.tcl ipv6_https_206 Verify IPv6 HTTPS/1.1 GET connections with large number of headers


    step 1. Send an IPv6 HTTPS/1.1 GET request to the server with the maximum allowed headers
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 GET connections with chunked encoding https-v6.tcl ipv6_https_250 Verify IPv6 HTTPS/1.1 GET connections with chunked encoding


    step 1. Send an IPv6 HTTPS/1.1 GET request to server
    step 2. Verify HTTPS response with chunked encoding is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 WebSocket Ping message https-v6.tcl ipv6_https_300 Verify IPv6 HTTPS/1.1 WebSocket Ping message


    step 1. Send an IPv6 HTTPS/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket Ping opcode (0x9)
    step 4. Verify server side returns WebSocket Pong opcode (0xA)
    step 5. Close the WebSocket server


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 6455 "The WebSocket Protocol"

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

Test Module Name Synopsis
Verify IPv6 HTTPS/1.1 WebSocket Text message https-v6.tcl ipv6_https_301 Verify IPv6 HTTPS/1.1 WebSocket Text message


    step 1. Send an IPv6 HTTPS/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket data message with text 
    step 4. Verify server side echos back the same text data
    step 5. Close the WebSocket server


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 6455 "The WebSocket Protocol"

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


http2-v6.tcl

IPv6 HTTP/2 related test cases

Test Module Name Synopsis
Verify HTTP/2 GET connections http2-v6.tcl ipv6_http2_100 Verify HTTP/2 GET connections


    step 1. Send an HTTP/2 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 POST connections http2-v6.tcl ipv6_http2_101 Verify HTTP/2 POST connections


    step 1. Send an HTTP/2 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 HEAD connections http2-v6.tcl ipv6_http2_102 Verify HTTP/2 HEAD connections


    step 1. Send an HTTP/2 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 PUT connections http2-v6.tcl ipv6_http2_103 Verify HTTP/2 PUT connections


    step 1. Send an HTTP/2 PUT request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 OPTIONS connections http2-v6.tcl ipv6_http2_104 Verify HTTP/2 OPTIONS connections


    step 1. Send an HTTP/2 OPTIONS request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 DELETE connections http2-v6.tcl ipv6_http2_105 Verify HTTP/2 DELETE connections


    step 1. Send an HTTP/2 DELETE request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 GET connections with large number of headers http2-v6.tcl ipv6_http2_106 Verify HTTP/2 GET connections with large number of headers

    
    step 1. Send an HTTP/2 GET request to the server with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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


http2-tls-v6.tcl

IPv6 HTTP/2 over TLS related test cases

Test Module Name Synopsis
Verify HTTP/2 GET connections over TLS http2-tls-v6.tcl ipv6_http2_tls_100 Verify HTTP/2 GET connections over TLS


    step 1. Send an HTTP/2 GET request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 POST connections over TLS http2-tls-v6.tcl ipv6_http2_tls_101 Verify HTTP/2 POST connections over TLS


    step 1. Send an HTTP/2 POST request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 HEAD connections over TLS http2-tls-v6.tcl ipv6_http2_tls_102 Verify HTTP/2 HEAD connections over TLS


    step 1. Send an HTTP/2 HEAD request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 PUT connections over TLS http2-tls-v6.tcl ipv6_http2_tls_103 Verify HTTP/2 PUT connections over TLS


    step 1. Send an HTTP/2 PUT request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 OPTIONS connections over TLS http2-tls-v6.tcl ipv6_http2_tls_104 Verify HTTP/2 OPTIONS connections over TLS


    step 1. Send an HTTP/2 OPTIONS request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 DELETE connections over TLS http2-tls-v6.tcl ipv6_http2_tls_105 Verify HTTP/2 DELETE connections over TLS


    step 1. Send an HTTP/2 DELETE request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 GET connections over TLS with large number of headers http2-tls-v6.tcl ipv6_http2_tls_106 Verify HTTP/2 GET connections over TLS with large number of headers

    
    step 1. Send an HTTP/2 GET request to the server over TLS with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.



    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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


upnp-v6.tcl

IPv6 UPnP tests for routers that support IGDv1/IGDv2 devices

Test Module Name Synopsis
Verify UPnP router responds to SSDP Discovery Requests on LAN (IPv6) upnp-v6.tcl ipv6_ssdp_1 Verify UPnP router responds to SSDP Discovery Requests on LAN (IPv6)


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify UPnP router does not respond to SSDP Discovery Requests on WAN (IPv6) upnp-v6.tcl ipv6_ssdp_2 Verify UPnP router does not respond to SSDP Discovery Requests on WAN (IPv6)


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request on WAN side of router
    step 3. Wait up to 5 seconds for all responses sent
    step 4. Verify no responses are received


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify UPnP router supports discovery of required IGD devices and services (IPv6) upnp-v6.tcl ipv6_ssdp_3 Verify UPnP router supports discovery of required IGD devices and services (IPv6)


    step 1. Build a M-SEARCH request for search for each required device/service
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included

    Required device and service URNs:

      urn:schemas-upnp-org:device:InternetGatewayDevice:1
      urn:schemas-upnp-org:device:WANDevice:1
      urn:schemas-upnp-org:device:WANConnectionDevice:1
      urn:schemas-upnp-org:device:LANDevice:1

      urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
      urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
      urn:schemas-upnp-org:service:WANIPConnection:1  (not required for PPP)

    NOTE: Support for UPnP LANDevice:1 template is now configurable. If
    the router under test does not support the LANDevice:1
    template, the 'upnpLANDevice' testvar should be configured to
    no. If LANDevice is supported, the testvar should be configured
    to yes.


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

    WANIPConnection:1 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf

    WANIPConnection:2 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

Test Module Name Synopsis
Verify UPnP router does not respond to SSDP Discovery Requests without MX header (IPv6) upnp-v6.tcl ipv6_ssdp_4 Verify UPnP router does not respond to SSDP Discovery Requests without MX header (IPv6)


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
            that does not include an MX header
    step 2. Send M-SEARCH request on LAN side of router
    step 3. Wait up to 5 seconds for all responses sent
    step 4. Verify no responses are received


    References:

    UPnP Device Architecture 1.1 Section 1.3.3: Search response

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1.3.3

Test Module Name Synopsis
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN (IPv6) upnp-v6.tcl ipv6_ssdp_5 Verify UPnP router responds to unicast SSDP Discovery Requests on LAN (IPv6)


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send a unicast M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify required headers of M-SEARCH responses on LAN (IPv6) upnp-v6.tcl ipv6_ssdp_6 Verify required headers of M-SEARCH responses on LAN (IPv6)


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify XML description of IGD root device can be parsed (IPv6) upnp-v6.tcl ipv6_upnp_10 Verify XML description of IGD root device can be parsed (IPv6)


    step 1. Find the description URL for the root device using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required root device:

      urn:schemas-upnp-org:device:InternetGatewayDevice:1


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

Test Module Name Synopsis
Verify XML descriptions cannot be loaded from the WAN side of router (IPv6) upnp-v6.tcl ipv6_upnp_12 Verify XML descriptions cannot be loaded from the WAN side of router (IPv6)


    step 1. Find the description URL for the root device using SSDP on LAN
    step 2. Send HTTP GET from the WAN side to load description URL
    step 3. Send HTTP GET using router's WAN side public IP and private IP
    step 4. Verify description cannot be loaded using HTTP


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IPv6) upnp-v6.tcl ipv6_upnp_20 Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IPv6)


    step 1. Find the description URL for the WANIPConnection or
            WANPPPConnection service using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required service name:

    urn:schemas-upnp-org:service:WANIPConnection:1
    urn:schemas-upnp-org:service:WANPPPConnection:1

    NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
    test case to use the WANPPPConnection service. Otherwise, the
    router uses the WANIPConnection service.


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

Test Module Name Synopsis
Verify router responds to UPnP Query for ConnectionStatus (IPv6) upnp-v6.tcl ipv6_upnp_25 Verify router responds to UPnP Query for ConnectionStatus (IPv6)


    step 1. Find Control URL for WANIPConnection service
    step 2. Send UPnP Query for ConnectionStatus via SOAP POST
    step 3. Verify ConnectionStatus variable is returned in SOAP response

    NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
    This test should be skipped if the device does not support the
    QueryStateVariable action.


    References:

    UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1

Test Module Name Synopsis
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IPv6) upnp-v6.tcl ipv6_upnp_30 Verify UPnP GetExternalIPAddress Action returns WAN IP address (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetExternalIPAddress
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify IP address returned in the NewExternalIPAddress
            attribute is the correct WAN IP address


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.18: GetExternalIPAddress

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.18

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IPv6) upnp-v6.tcl ipv6_upnp_31 Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify returned ConnectionStatus is in the 'Connected' state


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IPv6) upnp-v6.tcl ipv6_upnp_32 Verify UPnP GetStatusInfo Action returns increasing Uptime value (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Save the current Uptime
    step 5. Wait 10 seconds
    step 6. Send UPnP Action for GetStatusInfo
    step 7. Verify Action succeeds with HTTP return code 200
    step 8. Verify Uptime has increased by at least 10 seconds


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IPv6) upnp-v6.tcl ipv6_upnp_35 Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IPv6) upnp-v6.tcl ipv6_upnp_36 Add/delete dynamic UPnP TCP port mapping for specific IP source address (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection from specific IP address (A)
            to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd TCP connection is blocked
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
             from specific ip address (A)
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IPv6) upnp-v6.tcl ipv6_upnp_40 Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd UDP connection is established
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IPv6) upnp-v6.tcl ipv6_upnp_41 Add/delete dynamic UPnP UDP port mapping for specific IP source address (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection from specific IP address (A)
            to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd UDP connection is blocked
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
             from specific ip address (A)
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Verify UPnP Router rejects new port mappings that conflict (IPv6) upnp-v6.tcl ipv6_upnp_45 Verify UPnP Router rejects new port mappings that conflict (IPv6)


    step 1. Start second DHCP client on LAN interface
    step 2. Find Control URL for WANIPConnection or WANPPPConnection service
    step 3. Send UPnP Action for AddPortMapping from the first DHCP client
    step 4. Verify Action returns HTTP 200 status code
    step 5. Send 2nd UPnP Action for AddPortMapping from the second DHCP client
            using the same external port number and protocol
    step 6. Verify AddPortMapping Action fails
    step 7. Delete port mapping using DeletePortMapping Action


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

Test Module Name Synopsis
Verify dynamic UPnP port mapping is deleted when lease expires (IPv6) upnp-v6.tcl ipv6_upnp_50 Verify dynamic UPnP port mapping is deleted when lease expires (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 45 seconds for lease to be deleted
    step 8. Initiate inbound TCP connection to new port mapping
    step 9. Verify TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Maximum number of UPnP TCP dynamic port mappings (IPv6) upnp-v6.tcl ipv6_upnp_100 Maximum number of UPnP TCP dynamic port mappings (IPv6)


    step 1. Determine the maximum number of UPnP TCP port mappings

    NOTE: This is configured in your configuration file using  the
    the testvar 'upnpMaxTcpMappings'.

    step 2. Create a unique port mapping using the AddPortMapping Action
            up to the maximum number supported
    step 3. For each mapping, establish an inbound TCP connection
    step 4. Verify each TCP connection can be established
    step 5. Delete each port mapping using the DeletePortMapping Action


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IPv6) upnp-v6.tcl ipv6_upnp_200 Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can subscribe to events with infinite subscription time (IPv6) upnp-v6.tcl ipv6_upnp_201 Verify UPnP clients can subscribe to events with infinite subscription time (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IPv6) upnp-v6.tcl ipv6_upnp_202 Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send SUBSCRIBE renewal for NOTIFY events
    step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
    step 7. Send UNSUBSCRIBE for eventSubURL
    step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events for ConnectionStatus (IPv6) upnp-v6.tcl ipv6_upnp_203 Verify router sends UPnP NOTIFY events for ConnectionStatus (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. Wait for NOTIFY event with new ConnectionStatus
    step 8. Verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. Wait for NOTIFY event with new ConnectionStatus
    step 11. Verify ConnectionStatus is 'Connected'
    step 12. Send UNSUBSCRIBE for eventSubURL
    step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: This test is not supported when the wanMode is static.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IPv6) upnp-v6.tcl ipv6_upnp_204 Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ExternalIPAddress matches current assigned WAN IP
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new external IP address
    step 8. Wait for NOTIFY event with new ExternalIPAddress
    step 9. Verify ExternalIPAddress is new IP address
    step 10. Bring down WAN link
    step 11. Bring up WAN link with new original IP address
    step 12. Wait for NOTIFY event with new ExternalIPAddress
    step 13. Verify ExternalIPAddress is original IP address
    step 14. Send UNSUBSCRIBE for eventSubURL
    step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router stops sending NOTIFY events when subscription expires (IPv6) upnp-v6.tcl ipv6_upnp_210 Verify router stops sending NOTIFY events when subscription expires (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Wait minimum subscriber timeout seconds for subscription to expire
    step 7. Bring down WAN link
    step 8. Wait for NOTIFY event
    step 9. Verify NOTIFY event is not received
    step 10. Bring up WAN link
    step 11. Wait for NOTIFY event
    step 12. Verify NOTIFY event is not received
    step 13. Do not UNSUBSCRIBE since subscription should be expired


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify the maximum number of UPnP event subscriptions that can be created (IPv6) upnp-v6.tcl ipv6_upnp_220 Verify the maximum number of UPnP event subscriptions that can be created (IPv6)


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. For each event client, send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. For each event client, wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 8. For each event client, verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 11. For each event client, verify ConnectionStatus is 'Connected'
    step 12. For each event client, send UNSUBSCRIBE for eventSubURL
    step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: The number of UPnP subscribers can be configured using the testvar
          upnpMaxSubClients. If not configured, the default is 10 subscribers.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware upnp-v6.tcl ipv6_upnp_400 Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for SetConnectionType with string format
    step 3. Verify Action does not return HTTP 200 status code
    step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit


    References:

    Broadcom UPnP Remote Preauth Code Execution Vulnerability

    https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/

    From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)

    https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt

Test Module Name Synopsis
Verify UPnP router supports discovery of required IGD devices and services (IGD2,IPv6) upnp-v6.tcl ipv6_ssdp_igd2_3 Verify UPnP router supports discovery of required IGD devices and services (IGD2,IPv6)


    step 1. Build a M-SEARCH request for search for each required device/service
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included

    Required device and service URNs:

      urn:schemas-upnp-org:device:InternetGatewayDevice:2
      urn:schemas-upnp-org:device:WANDevice:2
      urn:schemas-upnp-org:device:WANConnectionDevice:2
      urn:schemas-upnp-org:device:LANDevice:1

      urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
      urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
      urn:schemas-upnp-org:service:WANIPConnection:2  (not required for PPP)

    NOTE: Support for UPnP LANDevice:1 template is now configurable. If
    the router under test does not support the LANDevice:1
    template, the 'upnpLANDevice' testvar should be configured to
    no. If LANDevice is supported, the testvar should be configured
    to yes.


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML description of IGD root device can be parsed (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_10 Verify XML description of IGD root device can be parsed (IGD2,IPv6)


    step 1. Find the description URL for the root device using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required root device:

      urn:schemas-upnp-org:device:InternetGatewayDevice:2


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_12 Verify XML descriptions cannot be loaded from the WAN side of router (IGD2,IPv6)


    step 1. Find the description URL for the root device using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required root device:

      urn:schemas-upnp-org:device:InternetGatewayDevice:1


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_20 Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2,IPv6)


    step 1. Find the description URL for the WANIPConnection:2 or
            WANPPPConnection:1 service using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required service name:

    urn:schemas-upnp-org:service:WANIPConnection:2
    urn:schemas-upnp-org:service:WANPPPConnection:1

    NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
    test case to use the WANPPPConnection service. Otherwise, the
    router uses the WANIPConnection service.


    References:

    WANIPConnection:2 Service Template Version 2.00

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

    WANIPConnection:2 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

Test Module Name Synopsis
Verify router responds to UPnP Query for ConnectionStatus (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_25 Verify router responds to UPnP Query for ConnectionStatus (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 service
    step 2. Send UPnP Query for ConnectionStatus via SOAP POST
    step 3. Verify ConnectionStatus variable is returned in SOAP response

    NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
    This test should be skipped if the device does not support the
    QueryStateVariable action.


    References:

    UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1

Test Module Name Synopsis
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_30 Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetExternalIPAddress
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify IP address returned in the NewExternalIPAddress
            attribute is the correct WAN IP address


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.20: GetExternalIPAddress

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.20

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_31 Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify returned ConnectionStatus is in the 'Connected' state


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_32 Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Save the current Uptime
    step 5. Wait 10 seconds
    step 6. Send UPnP Action for GetStatusInfo
    step 7. Verify Action succeeds with HTTP return code 200
    step 8. Verify Uptime has increased by at least 10 seconds


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_35 Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_36 Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection from specific IP address (A)
            to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd TCP connection is blocked
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
             from specific ip address (A)
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_40 Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd UDP connection is established
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_41 Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection from specific IP address (A)
            to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd UDP connection is blocked
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
             from specific ip address (A)
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Verify UPnP Router rejects new port mappings that conflict (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_45 Verify UPnP Router rejects new port mappings that conflict (IGD2,IPv6)


    step 1. Start second client on LAN interface
    step 2. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 3. Send UPnP Action for AddPortMapping from the first DHCP client
    step 4. Verify Action returns HTTP 200 status code
    step 5. Send 2nd UPnP Action for AddPortMapping from the second client
            using the same external port number and protocol
    step 6. Verify AddPortMapping Action fails
    step 7. Delete port mapping using DeletePortMapping Action


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

Test Module Name Synopsis
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_50 Verify dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 45 seconds for lease to be deleted
    step 8. Initiate inbound TCP connection to new port mapping
    step 9. Verify TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

Test Module Name Synopsis
Maximum number of UPnP TCP dynamic port mappings (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_100 Maximum number of UPnP TCP dynamic port mappings (IGD2,IPv6)


    step 1. Determine the maximum number of UPnP TCP port mappings

    NOTE: This is configured in your configuration file using  the
    the testvar 'upnpMaxTcpMappings'.

    step 2. Create a unique port mapping using the AddPortMapping Action
            up to the maximum number supported
    step 3. For each mapping, establish an inbound TCP connection
    step 4. Verify each TCP connection can be established
    step 5. Delete each port mapping using the DeletePortMapping Action


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_200 Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_201 Verify UPnP clients can subscribe to events with infinite subscription time (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_202 Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send SUBSCRIBE renewal for NOTIFY events
    step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
    step 7. Send UNSUBSCRIBE for eventSubURL
    step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_203 Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. Wait for NOTIFY event with new ConnectionStatus
    step 8. Verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. Wait for NOTIFY event with new ConnectionStatus
    step 11. Verify ConnectionStatus is 'Connected'
    step 12. Send UNSUBSCRIBE for eventSubURL
    step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: This test is not supported when the wanMode is static.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_204 Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ExternalIPAddress matches current assigned WAN IP
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new external IP address
    step 8. Wait for NOTIFY event with new ExternalIPAddress
    step 9. Verify ExternalIPAddress is new IP address
    step 10. Bring down WAN link
    step 11. Bring up WAN link with new original IP address
    step 12. Wait for NOTIFY event with new ExternalIPAddress
    step 13. Verify ExternalIPAddress is original IP address
    step 14. Send UNSUBSCRIBE for eventSubURL
    step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router stops sending NOTIFY events when subscription expires (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_210 Verify router stops sending NOTIFY events when subscription expires (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Wait minimum subscriber timeout seconds for subscription to expire
    step 7. Bring down WAN link
    step 8. Wait for NOTIFY event
    step 9. Verify NOTIFY event is not received
    step 10. Bring up WAN link
    step 11. Wait for NOTIFY event
    step 12. Verify NOTIFY event is not received
    step 13. Do not UNSUBSCRIBE since subscription should be expired


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify the maximum number of UPnP event subscriptions that can be created (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_220 Verify the maximum number of UPnP event subscriptions that can be created (IGD2,IPv6)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. For each event client, send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. For each event client, wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 8. For each event client, verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 11. For each event client, verify ConnectionStatus is 'Connected'
    step 12. For each event client, send UNSUBSCRIBE for eventSubURL
    step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: The number of UPnP subscribers can be configured using the testvar
          upnpMaxSubClients. If not configured, the default is 10 subscribers.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router responds to UPnP GetFirewallStatus action (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_230 Verify router responds to UPnP GetFirewallStatus action (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for GetFirewallStatus
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify FirewallEnabled and InboundPinholeAllowed attributes
            are returned


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.1: GetFirewallStatus

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.1

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for wildcard IPv6 source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_300 Add/delete dynamic UPnP TCP port mapping for wildcard IPv6 source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with wildcard
            for RemoteHost ("") and LeaseTime of 3600
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePinhole Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for specific IPv6 source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_301 Add/delete dynamic UPnP TCP port mapping for specific IPv6 source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with specific IP address (A)
            for RemoteHost and LeaseTime of 3600
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection from specific IP address (A)
            to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd TCP connection is blocked
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePinhole Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
             from specific ip address (A)
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Add/delete dynamic UPnP port mapping for wildcard IPv6 source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_302 Add/delete dynamic UPnP port mapping for wildcard IPv6 source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with wildcard
            for RemoteHost ("") and LeaseTime of 3600
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePinhole Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Add/delete dynamic UPnP port mapping for specific IPv6 source address (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_303 Add/delete dynamic UPnP port mapping for specific IPv6 source address (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with specific IP address (A)
            for RemoteHost, Protocol UDP and LeaseTime of 3600
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound UDP connection from specific IP address (A)
            to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd UDP connection is blocked
    step 8. Delete port mapping using DeletePinhole Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
             from specific ip address (A)
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Verify IPv6 dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_304 Verify IPv6 dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with lease of 30 seconds
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 45 seconds for lease to be deleted
    step 8. Initiate inbound TCP connection to new port mapping
    step 9. Verify TCP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

Test Module Name Synopsis
Maximum number of UPnP IPv6 TCP dynamic port mappings (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_305 Maximum number of UPnP IPv6 TCP dynamic port mappings (IGD2,IPv6)


    step 1. Determine the maximum number of UPnP TCP port mappings

    NOTE: This is configured in your configuration file using  the
    the testvar 'upnpMaxTcpMappings'.

    step 2. Create a unique port mapping using the AddPinhole Action
            up to the maximum number supported
    step 3. For each mapping, establish an inbound TCP connection
    step 4. Verify each TCP connection can be established
    step 5. Delete each port mapping using the DeletePinhole Action


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Update lease time for UPnP TCP port mapping (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_306 Update lease time for UPnP TCP port mapping (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with wildcard for
            RemoteHost ("") and LeaseTime of 30
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection to new port mapping from WAN side
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 20 seconds
    step 8. Send UPnP Action for UpdatePinhole with UniqueID from step
            3 and NewLeaseTime of 120
    step 9. Verify Action returns HTTP 200 status code
    step 10. Wait 20 seconds
    step 11. Initiate inbound TCP connection to port mapping from WAN side
    step 12. Verify TCP connection is established
    step 13. Close TCP connection
    step 14. Delete port mapping using DeletePinhole Action
    step 15. Wait 5 seconds for port mapping to be deleted
    step 16. Initiate inbound TCP connection for port mapping from WAN side
    step 17. Verify inbound TCP connection is blocked


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5

Test Module Name Synopsis
Verify GetPinholePackets action returns increasing packet count (IGD2,IPv6) upnp-v6.tcl ipv6_upnp_igd2_307 Verify GetPinholePackets action returns increasing packet count (IGD2,IPv6)


    step 1. Find Control URL for WANIPv6FirewallControl service
    step 2. Send UPnP Action for AddPinhole with wildcard for
            RemoteHost ("") and LeaseTime of 3600
    step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
    step 4. Initiate inbound TCP connection to new port mapping from WAN side
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Send UPnP Action for GetPinholePackets with UniqueID from step 3
    step 8. Verify Action returns HTTP 200 status code with non-zero PinholePackets parameter
    step 9. Initiate inbound TCP connection to port mapping from WAN side
    step 10. Verify TCP connection is established
    step 11. Close TCP connection
    step 12. Send UPnP Action for GetPinholePackets with UniqueID from step 3
    step 13. Verify Action returns HTTP 200 status code with a
             PinholePackets parameter greater than that from step 9
    step 14. Delete port mapping using DeletePinhole Action


    References:

    WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.6: GetPinholePackets

    http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.6

Test Module Name Synopsis
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware upnp-v6.tcl ipv6_upnp_igd2_400 Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for SetConnectionType with string format
    step 3. Verify Action does not return HTTP 200 status code
    step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit


    References:

    Broadcom UPnP Remote Preauth Code Execution Vulnerability

    https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/

    From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)

    https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt


ipv6-mss.tcl

IPv6 MSS tests for routers that support IPv6 TCP MSS clamping

Test Module Name Synopsis
Verify basic MSS Clamping for TCP sessions ipv6-mss.tcl ipv6_mss_100 Verify basic MSS Clamping for TCP sessions


    step 1. Set the TCP MSS size to 1440
    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 'ipv6MssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar ipv6MssClampingInValue.

    Example:

       testvar ipv6MssClampingValue 1452

    Example with different values per direction:

       testvar ipv6MssClampingValue 1452
       testvar ipv6MssClampingInValue 1440

    NOTE: The TCP port used for the MSS clamping test can be changed
    using the testvar ipv6MssClampingTestPort.

    Example:

       testvar ipv6MssClampingTestPort 8096


Test Module Name Synopsis
Verify MSS Clamping with TCP options from different clients ipv6-mss.tcl ipv6_mss_110 Verify MSS Clamping with TCP options from different clients


    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 'ipv6MssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar ipv6MssClampingInValue.

    Example:

       testvar ipv6MssClampingValue 1452

    Example with different values per direction:

       testvar ipv6MssClampingValue 1452
       testvar ipv6MssClampingInValue 1440

    NOTE: The TCP port used for the MSS clamping test can be changed
    using the testvar ipv6MssClampingTestPort.

    Example:

       testvar ipv6MssClampingTestPort 8096

Test Module Name Synopsis
Verify MSS Clamping does not modify smaller MSS values ipv6-mss.tcl ipv6_mss_120 Verify MSS Clamping does not modify smaller MSS values


    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 'ipv6MssClampingValue'.

    Example:

       testvar ipv6MssClampingValue 1452

    NOTE: The TCP port used for the MSS clamping test can be changed
    using the testvar ipv6MssClampingTestPort.

    Example:

       testvar ipv6MssClampingTestPort 8096


mape.tcl

MAP-E / LW4o6 tests for mapping IPv4 to IPv6

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates outbound packets to destinations outside the MAP domain mape.tcl mape_1 Verify MAP-E / LW4o6 CE translates outbound packets to destinations outside the MAP domain


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 destination address is the BR address


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 5.4: Destinations outside of the MAP Domain

    https://tools.ietf.org/html/rfc7597#section-5.4

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates inbound packets from destinations outside the MAP domain mape.tcl mape_2 Verify MAP-E / LW4o6 CE translates inbound packets from destinations outside the MAP domain


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 destination address is the BR address
    step 4. Send a return UDP packet back to the CE's WAN side source port
    step 5. Verify that the return UDP packet is received on the LAN


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 5.4: Destinations outside of the MAP Domain

    https://tools.ietf.org/html/rfc7597#section-5.4

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port inside the PSID set mape.tcl mape_10 Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port inside the PSID set


    step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
            the WAN using a source port inside the PSID set
    step 2. Verify that the connection is established
    step 3. Send an HTTP GET request to server
    step 4. Verify that an HTTP response is received
    step 5. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 6. Verify that the TCP source port has been translated to a port
            contained inside the PSID set
    step 7. Close the TCP connection from LAN side


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture

    For packets outbound from the private IPv4 network, the CE NAPT
    MUST translate transport identifiers (e.g., TCP and UDP port
    numbers) so that they fall within the CE's assigned port range.

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port outside the PSID set mape.tcl mape_11 Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port outside the PSID set


    step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
            the WAN using a source port outside the PSID set
    step 2. Verify that the connection is established
    step 3. Send an HTTP GET request to server
    step 4. Verify that an HTTP response is received
    step 5. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 6. Verify that the TCP source port has been translated to a port
            contained inside the PSID set
    step 7. Close the TCP connection from LAN side


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture

    For packets outbound from the private IPv4 network, the CE NAPT
    MUST translate transport identifiers (e.g., TCP and UDP port
    numbers) so that they fall within the CE's assigned port range.

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port inside the PSID set mape.tcl mape_12 Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port inside the PSID set


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source port inside the PSID set
    step 2. Verify that the UDP packet is received on the WAN
    step 3. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 4. Verify that the UDP source port has been translated to a port
            contained inside the PSID set


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture

    For packets outbound from the private IPv4 network, the CE NAPT
    MUST translate transport identifiers (e.g., TCP and UDP port
    numbers) so that they fall within the CE's assigned port range.

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port outside the PSID set mape.tcl mape_13 Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port outside the PSID set


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source port outside the PSID set
    step 2. Verify that the UDP packet is received on the WAN
    step 3. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 4. Verify that the UDP source port has been translated to a port
            contained inside the PSID set


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture

    For packets outbound from the private IPv4 network, the CE NAPT
    MUST translate transport identifiers (e.g., TCP and UDP port
    numbers) so that they fall within the CE's assigned port range.

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE does not translate packets with bad source address mape.tcl mape_14 Verify MAP-E / LW4o6 CE does not translate packets with bad source address


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source address of 0.0.0.0
    step 2. Verify that the UDP packet is not received on the WAN
    step 3. Repeat steps 1 and 2 using source addresses of 127.0.0.1 and
            224.0.0.1


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8: Forwarding Considerations

    For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the
    LAN performs NAT44 functions first and creates appropriate NAT44
    bindings.  The resulting IPv4 packets MUST contain the source IPv4
    address and source transport identifiers specified by the MAP
    provisioning parameters.  The IPv4 packet is forwarded using the CE's
    MAP forwarding function.  The IPv6 source and destination addresses
    MUST then be derived as per Section 5 of this document.

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE sets IPv6 Hop Limit to correct value when translating packets mape.tcl mape_20 Verify MAP-E / LW4o6 CE sets IPv6 Hop Limit to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify the IPv6 Hop Limit is set to mapTunnelHopLimit


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.3: IPv6 Tunnel Hop Limit

    The tunnel hop limit is copied into the hop limit field of the tunnel
    IPv6 header of each packet encapsulated by the tunnel entry-point
    node.

    https://tools.ietf.org/html/rfc2473#section-6.3

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE sets IPv6 Traffic Class to correct value when translating packets mape.tcl mape_21 Verify MAP-E / LW4o6 CE sets IPv6 Traffic Class to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Traffic Class is either set to mapTunnelTrafficClass

    NOTE: If the Traffic Class field is expected to be copied from the
    original header, the testvar mapTunnelTrafficClass should be set
    to the value "auto".


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.4: IPv6 Tunnel Hop Limit

    The IPv6 Tunnel Packet Traffic Class indicates the value that a
    tunnel entry-point node sets in the Traffic Class field of a tunnel
    header. The default value is zero.  The configured Packet Traffic
    Class can also indicate whether the value of the Traffic Class field
    in the tunnel header is copied from the original header, or it is set
    to the pre-configured value.

    https://tools.ietf.org/html/rfc2473#section-6.4

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE sets IPv6 Flow Label to correct value when translating packets mape.tcl mape_22 Verify MAP-E / LW4o6 CE sets IPv6 Flow Label to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Flow Label is set to mapTunnelFlowLabel


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.5: IPv6 Tunnel Flow Label

    The IPv6 Tunnel Flow Label indicates the value that a tunnel entry-
    point node sets in the flow label of a tunnel header. The default
    value is zero.

    https://tools.ietf.org/html/rfc2473#section-6.5

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE sets IPv6 Next Header to correct value when translating packets mape.tcl mape_23 Verify MAP-E / LW4o6 CE sets IPv6 Next Header to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Next Header is set to 4 (IP-IP).


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 5: Tunnel IPv6 Header

    Next Header:

      The next header value according to [IPv6-Spec] from the
      Assigned Numbers RFC [RFC-1700 or its successors].

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

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE fragments large outbound packets with either IPv4 or IPv6 mape.tcl mape_30 Verify MAP-E / LW4o6 CE fragments large outbound packets with either IPv4 or IPv6


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Reassemble either IPv4 or IPv6 and verify original packet


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation

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

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain

    https://tools.ietf.org/html/rfc7597#section-8.3.1

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 mape.tcl mape_31 Verify MAP-E / LW4o6 CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation with DF=1
    step 2. Verify that the MAP-E CE sends an ICMPv4 Destination Unreachable
    step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'


    References:

    IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation

    (a)  if in the original IPv4 packet header the Don't Fragment  -
         DF - bit flag is SET, the entry-point node discards the
         packet and returns an ICMP message.  The ICMP message has
         the type = "unreachable", the code = "packet too big", and
         the recommended MTU size field set to the size of the
         tunnel MTU - see sections 6.7 and 8.3.

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

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: Fragmentation and Path MTU Discovery

    https://tools.ietf.org/html/rfc7597#section-8.3

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments originating from LAN mape.tcl mape_32 Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments originating from LAN


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            does not need IPv6 fragmentation
    step 2. Send the IPv4 packet on the LAN as two IPv4 fragments
    step 3. Verify that the packet is received as an IPv6 packet on the WAN

    NOTE: A MAP CE may choose to assemble outgoing IPv4 fragments before applying
    NAT44.


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: Fragmentation and Path MTU Discovery

    https://tools.ietf.org/html/rfc7597#section-8.3

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments which require IPv6 fragmentation mape.tcl mape_33 Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments which require IPv6 fragmentation


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Reassemble either IPv4 or IPv6 and verify original packet
    step 4. Repeat for total LAN IPv4 packet sizes from 1490 to 1500


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain

    Encapsulating an IPv4 packet to carry it across the MAP domain will
    increase its size (typically by 40 bytes).  It is strongly
    recommended that the MTU in the MAP domain be well managed and that
    the IPv6 MTU on the CE WAN-side interface be set so that no
    fragmentation occurs within the boundary of the MAP domain.

    For an IPv4 packet entering a MAP domain, fragmentation is performed
    as described in Section 7.2 of [RFC2473].

    https://tools.ietf.org/html/rfc7597#section-8.3.1

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly handles incoming IPv6 fragments from BR mape.tcl mape_34 Verify MAP-E / LW4o6 CE properly handles incoming IPv6 fragments from BR


    step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
            connection
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Send multiple IPv6 fragmented packets from BR to WAN side of CPE
            with total UDP length of 2490
    step 4. Verify CPE is able to reassemble IPv6 and forward original IPv4
            packets to LAN
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            2491 to 2500


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain

    https://tools.ietf.org/html/rfc7597#section-8.3.1

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly handles incoming IPv4 fragments from BR mape.tcl mape_35 Verify MAP-E / LW4o6 CE properly handles incoming IPv4 fragments from BR


    step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
            connection
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Send multiple IPv4 fragmented packets from BR to WAN side of CPE
            with total UDP length of 2490
    step 4. Verify CPE is able to receive IPv6 and forward original IPv4
            packets to LAN
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            2491 to 2500


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain

    https://tools.ietf.org/html/rfc7597#section-8.3.1

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly rewrites ICMPv4 Identifier field mape.tcl mape_40 Verify MAP-E / LW4o6 CE properly rewrites ICMPv4 Identifier field


    step 1. Send an ICMPv4 packet from the LAN to a destination outside the MAP
            domain on the WAN
    step 2. Verify that an ICMPv4 packet is received as an IPv6 packet on the WAN
    step 3. Verify that the ICMPv4 Identifier field has been rewritten
            to a value contained with the PSID set


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.2: ICMP

    If a MAP CE receives an ICMP message having the ICMP Identifier field
    in the ICMP header, the NAT44 in the MAP CE MUST rewrite this field
    to a specific value assigned from the port set.  BRs and other CEs
    must handle this field in a way similar to the handling of a port
    number in the TCP/UDP header upon receiving the ICMP message with the
    ICMP Identifier field.

    https://tools.ietf.org/html/rfc7597#section-8.2

Test Module Name Synopsis
Verify MAP-E / LW4o6 CE properly handles ICMPv4 error messages mape.tcl mape_41 Verify MAP-E / LW4o6 CE properly handles ICMPv4 error messages



    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Send ICMPv6 Destination Unreachable packet with original IPv4 packet as data
    step 4. Verify that the LAN client receives an ICMPv4 Port
            Unreachable packet with code 3 (Port unreachable)


    References:

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.1: Tunnel ICMP Messages

    https://tools.ietf.org/html/rfc7597#section-8.1

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.2: ICMP

    If a MAP node receives an ICMP error message without the ICMP
    Identifier field for errors that are detected inside an IPv6 tunnel,
    a node should relay the ICMP error message to the original source.
    This behavior SHOULD be implemented in accordance with Section 8 of
    [RFC2473].

    https://tools.ietf.org/html/rfc7597#section-8.2

    IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: ICMP Messages for IPv4 Original Packets

    https://tools.ietf.org/html/rfc7597#section-8.3


mapt.tcl

MAP-T tests for mapping IPv4 to IPv6

Test Module Name Synopsis
Verify MAP-T CE translates outbound packets to destinations outside the MAP domain mapt.tcl mapt_1 Verify MAP-T CE translates outbound packets to destinations outside the MAP domain


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 destination address is translated using the DMR
            prefix


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 5.1: Destinations outside of the MAP Domain

    https://tools.ietf.org/html/rfc7599#section-5.1

Test Module Name Synopsis
Verify MAP-T CE translates inbound packets from destinations outside the MAP domain mapt.tcl mapt_2 Verify MAP-T CE translates inbound packets from destinations outside the MAP domain


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 destination address is translated using the DMR
            prefix
    step 4. Send a return UDP packet back to the CE's WAN side source port
    step 5. Verify that the return UDP packet is received on the LAN


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 5.1: Destinations outside of the MAP Domain

    https://tools.ietf.org/html/rfc7599#section-5.1

Test Module Name Synopsis
Verify MAP-T CE translates outbound TCP connections with source port inside the PSID set mapt.tcl mapt_10 Verify MAP-T CE translates outbound TCP connections with source port inside the PSID set


    step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
            the WAN using a source port inside the PSID set
    step 2. Verify that the connection is established
    step 3. Send an HTTP GET request to server
    step 4. Verify that an HTTP response is received
    step 5. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 6. Verify that the TCP source port has been translated to a port
            contained inside the PSID set
    step 7. Close the TCP connection from LAN side


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE

    A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
    and create any necessary NAPT44 bindings.  The source address and
    source port range of packets resulting from the NAPT44 processing
    MUST correspond to the source IPv4 address and source transport port
    range assigned to the CE by means of the MAP Basic Mapping Rule
    (BMR).

    https://tools.ietf.org/html/rfc7599#section-8.1

Test Module Name Synopsis
Verify MAP-T CE translates outbound TCP connections with source port outside the PSID set mapt.tcl mapt_11 Verify MAP-T CE translates outbound TCP connections with source port outside the PSID set


    step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
            the WAN using a source port outside the PSID set
    step 2. Verify that the connection is established
    step 3. Send an HTTP GET request to server
    step 4. Verify that an HTTP response is received
    step 5. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 6. Verify that the TCP source port has been translated to a port
            contained inside the PSID set
    step 7. Close the TCP connection from LAN side


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE

    A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
    and create any necessary NAPT44 bindings.  The source address and
    source port range of packets resulting from the NAPT44 processing
    MUST correspond to the source IPv4 address and source transport port
    range assigned to the CE by means of the MAP Basic Mapping Rule
    (BMR).

    https://tools.ietf.org/html/rfc7599#section-8.1

Test Module Name Synopsis
Verify MAP-T CE translates outbound UDP connections with source port inside the PSID set mapt.tcl mapt_12 Verify MAP-T CE translates outbound UDP connections with source port inside the PSID set


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source port inside the PSID set
    step 2. Verify that the UDP packet is received on the WAN
    step 3. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 4. Verify that the UDP source port has been translated to a port
            contained inside the PSID set


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE

    A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
    and create any necessary NAPT44 bindings.  The source address and
    source port range of packets resulting from the NAPT44 processing
    MUST correspond to the source IPv4 address and source transport port
    range assigned to the CE by means of the MAP Basic Mapping Rule
    (BMR).

    https://tools.ietf.org/html/rfc7599#section-8.1

Test Module Name Synopsis
Verify MAP-T CE translates outbound UDP connections with source port outside the PSID set mapt.tcl mapt_13 Verify MAP-T CE translates outbound UDP connections with source port outside the PSID set


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source port outside the PSID set
    step 2. Verify that the UDP packet is received on the WAN
    step 3. Verify that the IPv4 source address on the WAN side is the expected
            NAT address
    step 4. Verify that the UDP source port has been translated to a port
            contained inside the PSID set


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE

    A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
    and create any necessary NAPT44 bindings.  The source address and
    source port range of packets resulting from the NAPT44 processing
    MUST correspond to the source IPv4 address and source transport port
    range assigned to the CE by means of the MAP Basic Mapping Rule
    (BMR).

    https://tools.ietf.org/html/rfc7599#section-8.1

Test Module Name Synopsis
Verify MAP-T CE does not translate packets with bad source address mapt.tcl mapt_14 Verify MAP-T CE does not translate packets with bad source address


    step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
            using a source address of 0.0.0.0
    step 2. Verify that the UDP packet is not received on the WAN
    step 3. Repeat steps 1 and 2 using source addresses of 127.0.0.1 and
            224.0.0.1


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    If the translator gets an illegal source address (e.g., 0.0.0.0,
    127.0.0.1, etc.), the translator SHOULD silently drop the packet
    (as discussed in Section 5.3.7 of [RFC1812]).

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

Test Module Name Synopsis
Verify MAP-T CE sets IPv6 Hop Limit to correct value when translating packets mapt.tcl mapt_20 Verify MAP-T CE sets IPv6 Hop Limit to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Hop Limit is based on the IPv4 TTL
    step 4. Verify the IPv6 Hop Limit is decremented by at least the
            number specified by the testvar IPv4HopCount


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    Hop Limit:  The hop limit is derived from the TTL value in the IPv4
      header.  Since the translator is a router, as part of forwarding
      the packet it needs to decrement either the IPv4 TTL (before the
      translation) or the IPv6 Hop Limit (after the translation).  As
      part of decrementing the TTL or Hop Limit, the translator (as any
      router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or
      ICMPv6 "Hop Limit Exceeded" error.

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

Test Module Name Synopsis
Verify MAP-T CE sets IPv6 Traffic Class to correct value when translating packets mapt.tcl mapt_21 Verify MAP-T CE sets IPv6 Traffic Class to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Traffic Class is either set to all zeros if the
            testvar mapTosTranslate is set to **no**, or copied from the IPv4
            TOS if the testvar mapTosTranslate is set to **yes**


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    Traffic Class:  By default, copied from the IP Type Of Service (TOS)
      octet.  According to [RFC2474], the semantics of the bits are
      identical in IPv4 and IPv6.  However, in some IPv4 environments
      these fields might be used with the old semantics of "Type Of
      Service and Precedence".  An implementation of a translator SHOULD
      support an administratively configurable option to ignore the IPv4
      TOS and always set the IPv6 traffic class (TC) to zero.  In
      addition, if the translator is at an administrative boundary, the
      filtering and update considerations of [RFC2475] may be
      applicable.

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

Test Module Name Synopsis
Verify MAP-T CE sets IPv6 Flow Label to correct value when translating packets mapt.tcl mapt_22 Verify MAP-T CE sets IPv6 Flow Label to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Flow Label is set to 0 (all zero bits)


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

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

Test Module Name Synopsis
Verify MAP-T CE sets IPv6 Next Header to correct value when translating packets mapt.tcl mapt_23 Verify MAP-T CE sets IPv6 Next Header to correct value when translating packets


    step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
            MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 Next Header is set to 17 (UDP) or
            that the packet contains a Fragmentation Header with a
            Next Header value of 17 (UDP).


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4: Translating from IPv4 to IPv6

    When the IPv4 sender does not set the DF bit, the translator SHOULD always
    include an IPv6 Fragment Header to indicate that the sender allows
    fragmentation. The translator MAY provide a configuration function that
    allows the translator not to include the Fragment Header for the
    non-fragmented IPv6 packets.

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

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    Next Header:  For ICMPv4 (1), it is changed to ICMPv6 (58);
      otherwise, the protocol field MUST be copied from the IPv4 header.

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

Test Module Name Synopsis
Verify MAP-T CE ignores IPv4 options when translating packets mapt.tcl mapt_24 Verify MAP-T CE ignores IPv4 options when translating packets


    step 1. Send an IPv4 UDP packet with the router alert option from the LAN to
            a destination outside the MAP domain on the WAN
    step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
    step 3. Verify that the IPv6 destination address is translated using the DMR
            prefix


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    If any IPv4 options are present in the IPv4 packet, they MUST be
    ignored and the packet translated normally; there is no attempt to
    translate the options.

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

Test Module Name Synopsis
Verify MAP-T CE fragments large outbound packets with either IPv4 or IPv6 mapt.tcl mapt_30 Verify MAP-T CE fragments large outbound packets with either IPv4 or IPv6


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Reassemble either IPv4 or IPv6 and verify original packet


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10: Fragmentation and Path MTU Discovery

    https://tools.ietf.org/html/rfc7599#section-10

Test Module Name Synopsis
Verify MAP-T CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 mapt.tcl mapt_31 Verify MAP-T CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation with DF=1
    step 2. Verify that the MAP-T CE 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

    (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 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10: Fragmentation and Path MTU Discovery

    https://tools.ietf.org/html/rfc7599#section-10

Test Module Name Synopsis
Verify MAP-T CE properly handles outbound IPv4 fragments originating from LAN mapt.tcl mapt_32 Verify MAP-T CE properly handles outbound IPv4 fragments originating from LAN


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            does not need IPv6 fragmentation
    step 2. Send the IPv4 packet on the LAN as two IPv4 fragments
    step 3. Verify that the packet is received as an IPv6 packet on the WAN

    NOTE: A MAP CE may choose to assemble outgoing IPv4 fragments before applying
    NAT44.


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.3: Sending IPv4 Fragments to the Outside

    https://tools.ietf.org/html/rfc7599#section-10.3

Test Module Name Synopsis
Verify MAP-T CE properly handles outbound IPv4 fragments which require IPv6 fragmentation mapt.tcl mapt_33 Verify MAP-T CE properly handles outbound IPv4 fragments which require IPv6 fragmentation


    step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
            requires IPv4 or IPv6 fragmentation
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Reassemble either IPv4 or IPv6 and verify original packet
    step 4. Repeat for total LAN IPv4 packet sizes from 1490 to 1500


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.1: Fragmentation in the MAP Domain

    Translating an IPv4 packet to carry it across the MAP domain will
    increase its size (typically by 20 bytes).  The MTU in the MAP domain
    should be well managed, and the IPv6 MTU on the CE WAN-side interface
    SHOULD be configured so that no fragmentation occurs within the
    boundary of the MAP domain.

    Fragmentation in MAP-T domains SHOULD be handled as described in
    Sections 4 and 5 of [RFC6145].

    https://tools.ietf.org/html/rfc7599#section-10.1

Test Module Name Synopsis
Verify MAP-T CE properly handles incoming IPv6 fragments from BR mapt.tcl mapt_34 Verify MAP-T CE properly handles incoming IPv6 fragments from BR


    step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
            connection
    step 2. Verify that the packet is received as an IPv6 packet on the WAN
    step 3. Send multiple IPv6 fragmented packets from BR to WAN side of CPE
            with total UDP length of 2490
    step 4. Verify CPE is able to reassemble IPv6 and forward original IPv4
            packets to LAN
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            2491 to 2500


    References:

    IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.1: Fragmentation in the MAP Domain

    https://tools.ietf.org/html/rfc7599#section-10.1

Test Module Name Synopsis
Verify MAP-T CE properly translates ICMPv4 packets mapt.tcl mapt_40 Verify MAP-T CE properly translates ICMPv4 packets


    step 1. Send an ICMPv4 packet from the LAN to a destination outside the MAP
            domain on the WAN
    step 2. Verify that an ICMPv6 packet is received on the WAN
    step 3. Verify the IPv6 source and destination addresses of the translated
            packet
    step 4. Verify that the IPv6 Next Header field is set to 58 (ICMPv6) in the
            translated packet or that the packet contains a Fragmentation Header
            with a Next Header value of 58 (ICMPv6).

    References:

    RFC 6145 Section 4: "Translating from IPv4 to IPv6"

    When the IPv4 sender does not set the DF bit, the translator SHOULD always
    include an IPv6 Fragment Header to indicate that the sender allows
    fragmentation. The translator MAY provide a configuration function that
    allows the translator not to include the Fragment Header for the
    non-fragmented IPv6 packets.


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers

    Next Header:  For ICMPv4 (1), it is changed to ICMPv6 (58);
      otherwise, the protocol field MUST be copied from the IPv4 header.

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

Test Module Name Synopsis
Verify MAP-T CE drops unsupported ICMPv4 message types mapt.tcl mapt_41 Verify MAP-T CE drops unsupported ICMPv4 message types


    step 1. Send an ICMPv4 packet of type 9 from the LAN to a destination
            outside the MAP domain on the WAN
    step 2. Verify that no ICMPv6 packets are received on the WAN
    step 3. Repeat steps 1 and 2 for ICMPv4 packets of type 10, 13, 14, 15, 16,
            17, 18, and 255


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.2: Translating ICMPv4 Headers into ICMPv6 Headers

    Section 4.2 lists several ICMPv4 message types that should be silently
    dropped by the MAP-T CE.

    https://tools.ietf.org/html/rfc6145#section-4.2

Test Module Name Synopsis
Verify MAP-T CE translates ICMPv4 Destination Unreachable codes into ICMPv6 mapt.tcl mapt_42 Verify MAP-T CE translates ICMPv4 Destination Unreachable codes into ICMPv6


    step 1. Send an IPv4 UDP packet from LAN to WAN
    step 2. Verify IPv4 UDP packet is received on WAN side
    step 3. Send an IPv4 UDP packet from WAN to LAN
    step 4. Verify IPv4 UDP packet is received on LAN side
    step 5. Send an ICMPv4 Destination Unreachable packet with a Code of 0 from
            the LAN to a destination outside the MAP domain on the WAN
    step 6. Verify that an ICMPv6 packet is received on the WAN
    step 7. Verify that the ICMPv6 code is translated according to the rules
            defined in Section 4.2 of RFC 6145
    step 8. Repeat steps 1 through 7 for ICMPv4 unreachable packets with codes
            of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, and 16


    References:

    IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.2: Translating ICMPv4 Headers into ICMPv6 Headers

    https://tools.ietf.org/html/rfc6145#section-4.2


ipsec-esp-v6.tcl

IPv6 IPSEC ESP tests for IPSEC based VPNs

Test Module Name Synopsis
Verify the ESP header sequence number increases with each new IPv6 IPSEC ESP packet ipsec-esp-v6.tcl ipv6_esp_1 Verify the ESP header sequence number increases with each new IPv6 IPSEC ESP packet


    step 1. Initiate 100 outbound ICMP Echo Requests to the remote VPN host
    step 2. Outbound traffic should be sent through IPSEC tunnel
    step 3. Verify the sequence number in the IPSEC ESP header increments by 1


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 2.2: Sequence Number

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

Test Module Name Synopsis
Verify manual IPv6 IPSEC keys continue to work after ESP sequence number wraps ipsec-esp-v6.tcl ipv6_esp_3 Verify manual IPv6 IPSEC keys continue to work after ESP sequence number wraps


    step 1. Set the current sequence number for the outbound SA to 0xfffffffe
    step 2. Initiate 10 outbound ICMP Echo Requests to the remote VPN host
    step 3. Outbound traffic should be sent through IPSEC tunnel
    step 4. Verify all packets are received as IPSEC ESP sequence number wraps


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements

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

Test Module Name Synopsis
Verify no anti-relay techniques are used with manual IPv6 IPSEC keys ipsec-esp-v6.tcl ipv6_esp_5 Verify no anti-relay techniques are used with manual IPv6 IPSEC keys


    step 1. Initiate 10 outbound ICMP Echo Requests to the remote host
    step 2. Before each packet is sent, reset the ESP sequence number
            to 11221122 so that all outbound packets have the same
            sequence number.
    step 3. Outbound traffic should be sent through IPSEC tunnel
    step 4. Verify all packets are sent and received with no errors


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements

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

Test Module Name Synopsis
Verify inner IPv6 Hop Limit is decremented for IPSEC tunneled packet ipsec-esp-v6.tcl ipv6_esp_8 Verify inner IPv6 Hop Limit is decremented for IPSEC tunneled packet


    step 1. Forward an IPv6 packet from a LAN client to the WAN
    step 2. Verify the Hop Limit of the tunneled packet is decremented by 1


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.1.2: Header Construction for Tunnel Mode

    https://tools.ietf.org/html/rfc2401#section-5.1.2

Test Module Name Synopsis
Verify IPv6 packets with wrong ESP authentication are dropped ipsec-esp-v6.tcl ipv6_esp_10 Verify IPv6 packets with wrong ESP authentication are dropped


    step 1. Initiate an outbound ICMP Echo Request to a WAN destination
    step 2. Verify ICMP Echo Reply is received
    step 3. Configure outbound SA with invalid authentication key
    step 4. Repeat outbound ICMP Echo Request
    step 5. Verify return ICMP Echo Reply is dropped
    step 6. Reconfigure original ESP authentication key
    step 7. Verify outbound ICMP Echo Request now succeeds

    NOTE: This test is only run when the configured IPSEC tunnel has
    authentication enabled.


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.4.5: Packet Decryption

    https://tools.ietf.org/html/rfc2406#section-3.4.5

Test Module Name Synopsis
Verify Incoming IPv6 fragments for ESP tunnel are reassembled ipsec-esp-v6.tcl ipv6_esp_20 Verify Incoming IPv6 fragments for ESP tunnel are reassembled


    step 1. Send a 5000 byte UDP packet from the LAN to the WAN
    step 2. Send a return 5000 byte UDP packet from the WAN to the LAN
            over the IPSEC tunnel. The IPSEC packet will be fragmented
            based on the MTU size.
    step 3. Verify router reassembled all IP fragments and forwards UDP
            packet to the LAN host


    References:

    IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly

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

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.2: Processing Inbound IP Traffic

    https://tools.ietf.org/html/rfc2401#section-5.2

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location

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

Test Module Name Synopsis
Verify out-of-order IPv6 fragments for ESP tunnel are reassembled ipsec-esp-v6.tcl ipv6_esp_21 Verify out-of-order IPv6 fragments for ESP tunnel are reassembled


    step 1. Send a 5000 byte UDP packet from the LAN to the WAN
    step 2. Send a return 5000 byte UDP packet from the WAN to the LAN
            over the IPSEC tunnel using out of order IPv6 fragments
    step 3. Verify router reassembled all out-of-order IPv6 fragments
            and forwards UDP packet to the LAN host


    References:

    IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly

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

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location

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

Test Module Name Synopsis
Verify router supports PMTU discovery for packets sent over IPSEC tunnel ipsec-esp-v6.tcl ipv6_esp_100 Verify router supports PMTU discovery for packets sent over IPSEC tunnel


    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
            remoteVpn host over the IPSEC tunnel
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process two more times until 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
            IPSEC 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 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing

    https://tools.ietf.org/html/rfc2401#section-6.1

    IETF RFC 1191 "Path MTU Discovery"

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

Test Module Name Synopsis
Verify return IPv6 traffic that does not use IPSEC/ESP is dropped ipsec-esp-v6.tcl ipv6_esp_200 Verify return IPv6 traffic that does not use IPSEC/ESP is dropped


    step 1. Forward UDP packet from LAN to remote VPN host
    step 2. Verify packet is forwarded over IPSEC tunnel to remote VPN host
    step 3. Send a return UDP packet from the remote VPN host without
            encapsulating the packet with an ESP header
    step 4. Verify the packet is not forwarded back to the LAN


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 4.4.1: The Security Policy Database (SPD)

    https://tools.ietf.org/html/rfc2401#section-4.4.1

Test Module Name Synopsis
Verify all configured IPv6 IPSEC tunnels are operational ipsec-esp-v6.tcl ipv6_esp_400 Verify all configured IPv6 IPSEC tunnels are operational


    step 1. Configure SAs for all IPSEC tunnels defined in the configuration file
    step 2. For each tunnel, verify a TCP connection can be established
            from the LAN host to a remote host over the IPSEC tunnel
    step 3. Close all TCP connections


ipsecpt-v6.tcl

IPv6 IPSEC based VPN pass through from the LAN to the WAN

Test Module Name Synopsis
Verify IPv6 IKE packets pass through router on UDP port 500 ipsecpt-v6.tcl ipv6_ipsecpt_1 Verify IPv6 IKE packets pass through router on UDP port 500


    step 1. Send an IPSEC packet from LAN to WAN
    step 2. Verify the packet is received on the WAN
    step 3. Send an IPSEC packet from WAN to LAN
    step 4. Verify the packet is received on the LAN


Test Module Name Synopsis
Verify tunnel mode IPv6 IPSEC packets pass through router ipsecpt-v6.tcl ipv6_ipsecpt_2 Verify tunnel mode IPv6 IPSEC packets pass through router


    step 1. Send a tunnel mode IPSEC packet from LAN to WAN
    step 2. Verify the packet is received on the WAN
    step 3. Send a tunnel mode IPSEC packet from WAN to LAN
    step 4. Verify the packet is received on the LAN

    Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
          prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Fragmented tunnel mode IPv6 IPSEC packets are forwarded between LAN and WAN ipsecpt-v6.tcl ipv6_ipsecpt_3 Fragmented tunnel mode IPv6 IPSEC packets are forwarded between LAN and WAN


    step 1. Send a large, fragmented tunnel mode IPSEC packet from LAN to WAN
    step 2. Verify the packet is received on the WAN
    step 3. Send a large, fragmented tunnel mode IPSEC packet from WAN to LAN
    step 4. Verify the packet is received on the LAN

    Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
          prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Verify the maximum number of IPv6 IPSEC connections for a single LAN host ipsecpt-v6.tcl ipv6_ipsecpt_100 Verify the maximum number of IPv6 IPSEC connections for a single LAN host


    step 1. Send a tunnel mode IPSEC packet from LAN to unique WAN IP address
    step 2. Verify the packet is received on the WAN
    step 3. Send a tunnel mode IPSEC packet from WAN to LAN
    step 4. Verify the packet is received on the LAN
    step 5. Repeat steps 1 through 4 N times, where N is specified by the
            ipsecMaxTunnels testvar

    Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
          prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Verify IPv6 IPSEC connections with multiple LAN clients using same VPN server ipsecpt-v6.tcl ipv6_ipsecpt_110 Verify IPv6 IPSEC connections with multiple LAN clients using same VPN server


    step 1. Start new IPv6 client on the LAN (named vpn2)
    step 2. Send an IPSEC packet from the primary LAN stack to the VPN server on
            WAN
    step 3. Send an IPSEC packet LAN client vpn2 to the VPN server on WAN
    step 4. Verify both packets are received by the VPN server
    step 5. Send a return IPSEC packet to each LAN client using unique SPI
    step 6. Verify each LAN client receives IPSEC packet with correct SPI

    Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
          prior to sending tunnel mode IPSEC packets.

    Note: Each LAN client sends a IPSEC packet to the same VPN server using
          unique SPI values in the ESP header. IPSEC packets sent back from the
          WAN use the SPI value.


Test Module Name Synopsis
Verify IPv6 IKE with multiple LAN clients using same VPN server ipsecpt-v6.tcl ipv6_ipsecpt_120 Verify IPv6 IKE with multiple LAN clients using same VPN server


    step 1. Start new IPv6 client on the LAN (named vpn2)
    step 2. Send an IPSEC IKE packet from the primary LAN stack to the VPN
            server on WAN
    step 3. Send an IPSEC IKE packet LAN client vpn2 to the VPN server on WAN
    step 4. Verify both packets are received by the VPN server
    step 5. Send return IKE packet to each LAN client
    step 6. Verify each LAN client receives correct IKE packet

    Note: Each LAN client uses a unique ISAKMP cookie for the initiator and
          responder cookies. There are two common techniques used to multiplex
          multiple IKE connections all originating from port 500. Some routers
          will change the IKE source port to another UDP port. This solution
          does not work for all VPN servers which may not accept IKE traffic if
          the UDP source port is not 500. Other routers will track the initiator
          and responder cookies in the ISAKMP messages in order to demultiplex
          incoming IKE packets. This test will succeed if either technique is
          used.


Contents

×

About CDRouter

QA Cafe CDRouter is a comprehensive and powerful test automation solution focused on feature, security, and performance testing for broadband and enterprise edge gateways, Wi-Fi and mesh systems, and other CPE.

Get in touch via our Contact page or by following us on your favorite service: