CDRouter IPv6 Test Summaries (Full)

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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. Verify that the prefix discovered in Step 2 has the autonomous
            address-configuration flag (A bit) set to either 0 or 1
    step 6. Verify that the prefix discovered in Step 2 has the on-link flag
            (L bit) set


    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

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


    References:

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

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

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

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


    References:

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

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

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


    References:

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

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

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

    step 1. Send invalid DHCPv6 packet with message type 0 to 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

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


    References:

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

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

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


    References:

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

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

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

    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

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


    References:

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

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

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

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

    -  otherwise accepts the information in the IA

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

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


    References:

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

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

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

    step 1. 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

    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

    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

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


    References:

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

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

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

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


    References:

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

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

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

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

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

    step 1. 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

    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

    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

    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

    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

    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 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 16.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/rfc8415#section-16.1

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Creation and Transmission of Solicit Messages

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

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

    step 1.  Wait for DHCPv6 client's current non-temporary address binding
             to expire
    step 2.  Do not respond to Renew or Rebind messages from client
    step 3.  Verify client sends Solicit message
    step 4.  Verify Solicit contains IA_NA option (3)
    step 5.  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 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15: Reliability of Client Initiated Message Exchanges

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

    IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 16.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/rfc8415#section-16.1

    step 1. Reboot the client and wait for it to send a DHCPv6 Solicit
    step 2. Do not respond to Solicit messages from client
    step 3. Verify that the client retransmits the Solicit message following the
            retransmission algorithm

    Note: This test takes over 2 hours to run.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

    step 1. Wait for DHCPv6 client's current non-temporary address binding to
            expire
    step 2. Do not respond to Request messages from client
    step 3. Verify that the client retransmits the Request message following the
            retransmission algorithm
    step 4. Verify that the client does not retransmit Request messages after
            MRC (Maximum Retransmission Count) has been reached.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

     step 1. Wait for DHCPv6 client to renew its current non-temporary address
             binding
     step 2. Reply to the DHCPv6 Renew message with updated IA_NA lifetimes. If
             IA_PD is enabled, the lifetimes match the IA_NA lifetimes
     step 3. Do not respond to subsequent Renew messages from client
     step 4. Verify that the client retransmits the DHCPv6 Renew message
             following the retransmission algorithm
     step 5. Verify that the client does not retransmit Renew messages after
             Max Retransmission Duration (MRD) has been reached

     Note: This test takes over 1 hour to run.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

     step 1. Wait for DHCPv6 client to renew its current non-temporary address
             binding
     step 2. Reply to the DHCPv6 Renew message with updated IA_NA lifetimes. If
             IA_PD is enabled, the lifetimes match the IA_NA lifetimes
     step 3. Do not respond to subsequent Renew or Rebind messages from client
     step 4. Verify that the client retransmits Rebind messages following the
             retransmission algorithm
     step 5. Verify that the client does not retransmit Rebind messages after
             Max Retransmission Duration (MRD) has been reached

     Note: This test takes over 2 hours to run.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

    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

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


    References:

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

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

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


    References:

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

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

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


    References:

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

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

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

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


    References:

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

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

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

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


    References:

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

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

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


    References:

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

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

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit 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

    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

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


    References:

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

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

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

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

    step 1. 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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    step 1. Wait for DHCPv6 client's current prefix binding to
            expire
    step 2. Do not respond to Solicit messages from client
    step 3. Verify that the client retransmits the Solicit message following the
            retransmission algorithm

    Note: This test takes over 2 hours to run.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

    step 1. Wait for DHCPv6 client's current prefix binding to
            expire
    step 2. Do not respond to Request messages from client
    step 3. Verify that the client retransmits the Request message following the
            retransmission algorithm
    step 4. Verify that the client does not retransmit Request messages after
            MRC (Maximum Retransmission Count) has been reached.


    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

     step 1. Wait for DHCPv6 client to renew its current prefix binding
     step 2. Reply to the DHCPv6 Renew message with updated IA_PD lifetimes. If
             IA_NA is enabled, the lifetimes match the IA_PD lifetimes
     step 3. Do not respond to subsequent Renew messages from client
     step 4. Verify that the client retransmits the DHCPv6 Renew message
             following the retransmission algorithm
     step 5. Verify that the client does not retransmit Renew messages after
             Max Retransmission Duration (MRD) has been reached

     Note: This test takes over 1 hour to run.

 
    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

     step 1. Wait for DHCPv6 client to renew its current prefix binding
     step 2. Reply to the DHCPv6 Renew message with updated IA_PD lifetimes. If
             IA_NA is enabled, the lifetimes match the IA_PD lifetimes
     step 3. Do not respond to subsequent Renew or Rebind messages from client
     step 4. Verify that the client retransmits Rebind messages following the
             retransmission algorithm
     step 5. Verify that the client does not retransmit Rebind messages after
             Max Retransmission Duration (MRD) has been reached

     Note: This test takes over 2 hours to run.

 
    References:

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

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in Section 18.  If a
    DHCP client fails to receive an expected response from a server, the
    client must retransmit its message according to the retransmission
    strategy described in this section.

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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

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

    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