Test Case Descriptions
- Modules: 42
- Test Cases: 655
Below is a full description of the testcases in each module
basic-v6.tcl
Basic IPv6 extension header processing tests
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards packets with multiple extension headers |
basic-v6.tcl |
ipv6_basic_1 |
Verify DUT forwards packets with multiple extension headers |
step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
Options and Destination Options extension headers using the PadN and Pad1
options, respectively
Hop-by-Hop Options Header:
Next Header = 0x3c (Destination Options)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Destination Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
step 2. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
using the extension headers generated in Step 1
step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers
https://tools.ietf.org/html/rfc2460#section-4
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
https://tools.ietf.org/html/rfc2460#section-4.2
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.3: Hop-by-Hop Options Header
https://tools.ietf.org/html/rfc2460#section-4.3
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.6: Destination Options Header
https://tools.ietf.org/html/rfc2460#section-4.6
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to packets with multiple extension headers |
basic-v6.tcl |
ipv6_basic_2 |
Verify DUT responds to packets with multiple extension headers |
step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
Options and Destination Options extension headers using the PadN and
Pad1 options, respectively
Hop-by-Hop Options Header:
Next Header = 0x3c (Destination Options)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Destination Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
step 2. Initiate an ICMPv6 Echo Request to the DUT's LAN-side IPv6
link-local address using the extension headers generated in Step 1
step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers
https://tools.ietf.org/html/rfc2460#section-4
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
https://tools.ietf.org/html/rfc2460#section-4.2
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.3: Hop-by-Hop Options Header
https://tools.ietf.org/html/rfc2460#section-4.3
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.6: Destination Options Header
https://tools.ietf.org/html/rfc2460#section-4.6
| Test |
Module |
Name |
Synopsis |
Verify DUT discards packets with unknown extension headers |
basic-v6.tcl |
ipv6_basic_3 |
Verify DUT discards packets with unknown extension headers |
step 1. Generate an ICMPv6 Echo Request packet containing a IPv6 Hop-by-Hop
Options extension header with a Next Header value of 200 (IP
protocol type 200 is currently unassigned)
Hop-by-Hop Options Header:
Next Header = 0xc8 (IP protocol type 200, unknown)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Unrecognized Next Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
link-local address using the extension headers generated in Step 1
step 3. Verify that the packet transmitted in Step 2 is discarded by
ensuring that no ICMPv6 Echo Reply packets are received within 3
seconds
step 4. Optional - if an ICMPv6 Parameter Problem packet is received, verify
that the ICMPv6 Parameter Problem message contains a value of 1 in
the Code field
step 5. Optional - if an ICMPv6 Parameter Problem packet is received, verify
that the ICMPv6 Parameter Problem message contains a value of 40 in
the Pointer field
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers
If, as a result of processing a header, a node is required to proceed
to the next header but the Next Header value in the current header is
unrecognized by the node, it should discard the packet and send an
ICMP Parameter Problem message to the source of the packet, with an
ICMP Code value of 1 ("unrecognized Next Header type encountered")
and the ICMP Pointer field containing the offset of the unrecognized
value within the original packet. The same action should be taken if
a node encounters a Next Header value of zero in any header other
than an IPv6 header.
https://tools.ietf.org/html/rfc2460#section-4
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.4: Parameter Problem Message
If an IPv6 node processing a packet finds a problem with a field in
the IPv6 header or extension headers such that it cannot complete
processing the packet, it MUST discard the packet and SHOULD send an
ICMPv6 Parameter Problem message to the packet's source, indicating
the type and location of the problem.
Codes 1 and 2 are more informative subsets of Code 0.
The pointer identifies the octet of the original packet's header
where the error was detected. For example, an ICMPv6 message with
Type field = 4, Code field = 1, and Pointer field = 40 would indicate
that the IPv6 extension header following the IPv6 header of the
original packet holds an unrecognized Next Header field value.
https://tools.ietf.org/html/rfc4443#section-3.4
| Test |
Module |
Name |
Synopsis |
Verify DUT discards packets with Next Header value of zero in extension header |
basic-v6.tcl |
ipv6_basic_4 |
Verify DUT discards packets with Next Header value of zero in extension header |
step 1. Generate an ICMPv6 Echo Request packet containing the IPv6
Hop-by-Hop Options extension header with a Next Header value of 0
Hop-by-Hop Options Header:
Next Header = 0x00 (HOPOPT)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Next Extension Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
Option Type = 0x00 (Pad1)
step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
link-local address using the extension headers generated in Step 1
step 3. Verify that the packet transmitted in Step 2 is discarded by
ensuring that no ICMPv6 Echo Reply packets are received within 3
seconds
step 4. Optional - if an ICMPv6 Parameter Problem packet is received, verify
that the ICMPv6 Parameter Problem message contains a value of 1 in
the Code field
step 5. Optional - if an ICMPv6 Parameter Problem packet is received, verify
that the ICMPv6 Parameter Problem message contains a value of 40 in
the Pointer field
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers
If, as a result of processing a header, a node is required to proceed
to the next header but the Next Header value in the current header is
unrecognized by the node, it should discard the packet and send an
ICMP Parameter Problem message to the source of the packet, with an
ICMP Code value of 1 ("unrecognized Next Header type encountered")
and the ICMP Pointer field containing the offset of the unrecognized
value within the original packet. The same action should be taken if
a node encounters a Next Header value of zero in any header other
than an IPv6 header.
https://tools.ietf.org/html/rfc2460#section-4
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.4: Parameter Problem Message
If an IPv6 node processing a packet finds a problem with a field in
the IPv6 header or extension headers such that it cannot complete
processing the packet, it MUST discard the packet and SHOULD send an
ICMPv6 Parameter Problem message to the packet's source, indicating
the type and location of the problem.
Codes 1 and 2 are more informative subsets of Code 0.
The pointer identifies the octet of the original packet's header
where the error was detected. For example, an ICMPv6 message with
Type field = 4, Code field = 1, and Pointer field = 40 would indicate
that the IPv6 extension header following the IPv6 header of the
original packet holds an unrecognized Next Header field value.
https://tools.ietf.org/html/rfc4443#section-3.4
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores packets with extension header containing 'No Next Header' |
basic-v6.tcl |
ipv6_basic_5 |
Verify DUT ignores packets with extension header containing ‘No Next Header’ |
step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
Options and Destination Options extension headers. The Hop-by-Hop
Options extension header will have a Next Header value of 59 (no
Next Header).
Hop-by-Hop Options Header:
Next Header = 0x3b (no Next Header)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Destination Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6
link-local address using the extension header generated in Step 1
step 3. Verify that the DUT ignores the ICMPv6 Echo Request packet by
ensuring that no ICMPv6 Echo Reply packets are received within 3
seconds
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.7: No Next Header
The value 59 in the Next Header field of an IPv6 header or any
extension header indicates that there is nothing following that
header. If the Payload Length field of the IPv6 header indicates the
presence of octets past the end of a header whose Next Header field
contains 59, those octets must be ignored, and passed on unchanged if
the packet is forwarded.
https://tools.ietf.org/html/rfc2460#section-4.7
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards packets with extension headers containing 'No Next Header' |
basic-v6.tcl |
ipv6_basic_6 |
Verify DUT forwards packets with extension headers containing ‘No Next Header’ |
step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
Options and Destination Options extension headers. The Hop-by-Hop
Options extension header will have a Next Header value of 59 (no
Next Header).
Hop-by-Hop Options Header:
Next Header = 0x3b (no Next Header)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
Destination Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x01 (PadN)
Option Data Length = 0x04 (6 bytes)
Option Data = 0x00000000
step 2. Initiate an ICMPv6 Echo Request (ping) to a WAN IPv6 destination
address using the extension header generated in Step 1
step 3. Verify that the WAN host receives the packet transmitted in Step 2
step 4. Verify that the ICMPv6 Echo Request packet received by the WAN host
is identical to the packet that was transmitted. Note that the
ICMPv6 Echo Request packet may be displayed as as an IPv6 protocol
type 0 packet (Hop-by-Hop Options) due to the inclusion of the no
Next Header field in the Hop-by-Hop Options extension header. The
data portion of the received IPv6 packet on the WAN should be
analayzed for the original ICMPv6 Echo Request.
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.7: No Next Header
The value 59 in the Next Header field of an IPv6 header or any
extension header indicates that there is nothing following that
header. If the Payload Length field of the IPv6 header indicates the
presence of octets past the end of a header whose Next Header field
contains 59, those octets must be ignored, and passed on unchanged if
the packet is forwarded.
https://tools.ietf.org/html/rfc2460#section-4.7
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 00 high order bits |
basic-v6.tcl |
ipv6_basic_10 |
Verify DUT properly processes unknown Option Type identifiers with 00 high order bits |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 17 (0x11). Option Type 17 contains high order bits of
00.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x11 (type 17 unknown, 00 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
a WAN IPv6 destination using the extension header generated in
Step 1
step 3. Verify that the DUT ignores the unknown Option Type by ensuring that
an ICMPv6 Echo Reply (ping response) packet is received
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 01 high order bits |
basic-v6.tcl |
ipv6_basic_11 |
Verify DUT properly processes unknown Option Type identifiers with 01 high order bits |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 71 (0x47). Option Type 71 contains high order bits of
01.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x47 (type 71 unknown, 01 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
a WAN IPv6 destination using the extension header generated in
Step 1
step 3. Verify that the DUT silently discards the packet transmitted in Step
2 be ensuring that it does not forward an ICMPv6 Echo Request packet
to the WAN IPv6 destination within 3 seconds
step 4. Repeat Step 2
step 5. Verify that the DUT silently discards the packet transmitted in Step
4 by ensuring that it does not send an ICMPv6 Parameter Problem
packet to the LAN source within 3 seconds
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - unicast destination |
basic-v6.tcl |
ipv6_basic_12 |
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - unicast destination |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 135 (0x87). Option Type 135 contains high order bits
of 10.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x87 (type 135 unknown, 10 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
a WAN IPv6 destination using the extension header generated in
Step 1
step 3. Verify that the DUT discards the packet transmitted in Step 2 by
ensuring that it does not forward an ICMPv6 Echo Request packet to
the WAN IPv6 destination within 3 seconds
step 4. Repeat Step 2
step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
source in response to the packet transmitted in Step 4 within 3
seconds
step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
2 in the Code field
step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
42 in the Pointer field
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - multicast destination |
basic-v6.tcl |
ipv6_basic_13 |
Verify DUT properly processes unknown Option Type identifiers with 10 high order bits - multicast destination |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 135 (0x87). Option Type 135 contains high order bits
of 10.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x87 (type 135 unknown, 10 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
the all routers multicast destination using the extension header
generated in Step 1
step 3. Verify that the DUT discards the packet transmitted in Step 2 be
ensuring that it does not forward an ICMPv6 Echo Request packet to
the LAN host within 3 seconds
step 4. Repeat Step 2
step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
source in response to the packet transmitted in Step 4 within 3
seconds
step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
2 in the Code field
step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
42 in the Pointer field
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - unicast destination |
basic-v6.tcl |
ipv6_basic_14 |
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - unicast destination |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 199 (0xc7). Option Type 199 contains high order bits
of 11.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0xc7 (type 199 unknown, 11 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
a WAN IPv6 destination using the extension header generated in
Step 1
step 3. Verify that the DUT discards the packet transmitted in Step 2 be
ensuring that it does not forward an ICMPv6 Echo Request packet to
the WAN IPv6 destination within 3 seconds
step 4. Repeat Step 2
step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to the
source in response to the packet transmitted in Step 4 within 3
seconds
step 6. Verify that the ICMPv6 Parameter Problem message contains a value of
2 in the Code field
step 7. Verify that the ICMPv6 Parameter Problem message contains a value of
42 in the Pointer field
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - multicast destination |
basic-v6.tcl |
ipv6_basic_15 |
Verify DUT properly processes unknown Option Type identifiers with 11 high order bits - multicast destination |
step 1. Generate a Hop-by-Hop Options extension header with an unknown
Option Type of 199 (0xc7). Option Type 199 contains high order bits
of 11.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0xc7 (type 199 unknown, 11 high order bits)
Option Data Length = 0x04 (4 bytes)
Option Data = 0x00000000
step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client to
the all routers multicast destination using the extension header
generated in Step 1
step 3. Verify that the DUT discards the packet transmitted in Step 2 and
does not send an ICMPv6 Parameter Problem packet to the source
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
https://tools.ietf.org/html/rfc2460#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DUT discards packets with Type 0 Routing Extension Header as an Intermediary Node |
basic-v6.tcl |
ipv6_basic_20 |
Verify DUT discards packets with Type 0 Routing Extension Header as an Intermediary Node |
step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
extension header. The destination address is the gateway's global
address, which forces header processing. The segment is set to the
RemoteHost's IPv6 address.
Routing Extension Header:
Next Header = 0x3a (ICMPv6)
Length = 0x06 (56 bytes)
Routing Type = 0x00 (Source Routing)
Segments Left: = 0x01
step 2. The RemoteHost is inspected to verify the gateway did not resend the
packet
step 3. The packet is resent
step 4. ICMPv6 Parameter Problem packet is verified as delivered to the LAN
client
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 5095 "Deprecation of Type 0 Routing Headers in IPv6" Section 3: Deprecation of RH0
An IPv6 node that receives a packet with a destination address
assigned to it and that contains an RH0 extension header MUST NOT
execute the algorithm specified in the latter part of Section 4.4 of
[RFC2460] for RH0. Instead, such packets MUST be processed according
to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
that includes an unrecognised Routing Type value, namely:
If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
https://tools.ietf.org/html/rfc5095#section-3
| Test |
Module |
Name |
Synopsis |
Verify DUT processes packets with Type 0 Routing Extension Header as an End Node |
basic-v6.tcl |
ipv6_basic_21 |
Verify DUT processes packets with Type 0 Routing Extension Header as an End Node |
step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
extension header. The destination address is the gateway's global
address, which forces header processing. The segment is set to the
RemoteHost's IPv6 address.
Routing Extension Header:
Next Header = 0x3a (ICMPv6)
Length = 0x06 (56 bytes)
Routing Type = 0x00 (Source Routing)
Segments Left: = 0x00
step 2. The RemoteHost is inspected to verify the gateway did not resend the
packet
step 3. The packet is resent
step 4. The LAN client is inspected to verify the ICMPv6 Echo Reply was
received from the gateway
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 5095 "Deprecation of Type 0 Routing Headers in IPv6" Section 3: Deprecation of RH0
An IPv6 node that receives a packet with a destination address
assigned to it and that contains an RH0 extension header MUST NOT
execute the algorithm specified in the latter part of Section 4.4 of
[RFC2460] for RH0. Instead, such packets MUST be processed according
to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
that includes an unrecognised Routing Type value, namely:
If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
https://tools.ietf.org/html/rfc5095#section-3
| Test |
Module |
Name |
Synopsis |
Verify DUT discards packets with Unknown Routing Extension Header as an Intermediary Node |
basic-v6.tcl |
ipv6_basic_22 |
Verify DUT discards packets with Unknown Routing Extension Header as an Intermediary Node |
step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
extension header. The destination address is the gateway's global
address, which forces header processing. The segment is set to the
RemoteHost's IPv6 address.
Routing Extension Header:
Next Header = 0x3a (ICMPv6)
Length = 0x06 (56 bytes)
Routing Type = 0x33 (Unknown Type)
Segments Left: = 0x01
step 2. The RemoteHost is inspected to verify the gateway did not resend the
packet
step 3. The packet is resent
step 4. ICMPv6 Parameter Problem packet is verified as delivered to the LAN
client
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.4: Routing Header
If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required behavior
of the node depends on the value of the Segments Left field, as
follows:
If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
https://tools.ietf.org/html/rfc2460#section-4.4
| Test |
Module |
Name |
Synopsis |
Verify DUT processes packets with Unknown Routing Extension Header as an End Node |
basic-v6.tcl |
ipv6_basic_23 |
Verify DUT processes packets with Unknown Routing Extension Header as an End Node |
step 1. Generate an ICMP Echo Request packet containing an IPv6 Routing
extension header. The destination address is the gateway's global
address, which forces header processing. The segment is set to the
RemoteHost's IPv6 address.
Routing Extension Header:
Next Header = 0x3a (ICMPv6)
Length = 0x06 (56 bytes)
Routing Type = 0x33 (Unknown Type)
Segments Left: = 0x00
step 2. The RemoteHost is inspected to verify the gateway did not resend the
packet
step 3. The packet is resent
step 4. The LAN client is inspected to verify the ICMPv6 Echo Reply was
received from the gateway
References:
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IPv6 Ready Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.4: Routing Header
If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required behavior
of the node depends on the value of the Segments Left field, as
follows:
If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing header.
If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
https://tools.ietf.org/html/rfc2460#section-4.4
frag-v6.tcl
IPv6 fragmentation tests
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to fragmented ICMPv6 Echo Requests |
frag-v6.tcl |
ipv6_frag_1 |
Verify DUT responds to fragmented ICMPv6 Echo Requests |
step 1. Generate a valid 3000 byte ICMPv6 Echo Request packet
step 2. Set IPv6 MTU of the LAN to 1280 bytes
step 3. Initiate an outbound ICMPv6 Echo Request (ping) to the DUT's
LAN-side IPv6 link-local address using the packet generated in
Step 1
step 4. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header
https://tools.ietf.org/html/rfc2460#section-4.5
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards fragmented ICMPv6 packets |
frag-v6.tcl |
ipv6_frag_2 |
Verify DUT forwards fragmented ICMPv6 packets |
step 1. Generate a valid 3000 byte ICMPv6 Echo Request packet
step 2. Set IPv6 MTU of the LAN client to 1280 bytes
step 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytes
step 4. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
using the packet generated in Step 1
step 5. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header
https://tools.ietf.org/html/rfc2460#section-4.5
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards fragmented UDP packets |
frag-v6.tcl |
ipv6_frag_3 |
Verify DUT forwards fragmented UDP packets |
step 1. Generate a valid 3000 byte UDP Echo packet
step 2. Set IPv6 MTU of the LAN client to 1280 bytes
step 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytes
step 4. Initiate an outbound UDP Echo to a WAN IPv6 destination using the
packet generated in Step 1
step 5. Verify that a UDP Echo response is received on the LAN
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.5: Fragment Header
https://tools.ietf.org/html/rfc2460#section-4.5
ndp.tcl
Neighbor Discovery Protocol and Router Advertisement tests for IPv6 devices
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Router Solicitations on the LAN |
ndp.tcl |
ipv6_ndp_1 |
Verify DUT responds to Router Solicitations on the LAN |
step 1. Send a Router Solicitation from the LAN
step 2. Wait for a Router Advertisement from the DUT
step 3. Verify the fields in the Router Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT periodically sends unsolicited Router Advertisements |
ndp.tcl |
ipv6_ndp_2 |
Verify DUT periodically sends unsolicited Router Advertisements |
step 1. Listen for a Router Advertisement on the LAN
step 2. Wait for a second Router Advertisement on the LAN
step 3. Verify that the DUT is periodically sending Advertisments
NOTE: The testvar ipv6RAInterval will control how long this test waits for a
Router Advertisement.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations for its link-local address |
ndp.tcl |
ipv6_ndp_10 |
Verify DUT responds to Neighbor Solicitations for its link-local address |
step 1. Send a Neighbor Solicitation on the LAN for the DUT's link-local address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify fields of the Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations for its global IPv6 address |
ndp.tcl |
ipv6_ndp_11 |
Verify DUT responds to Neighbor Solicitations for its global IPv6 address |
step 1. Send a Neighbor Solicitation on the LAN for the DUT's global IPv6 address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify fields of Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores Neighbor Solicitations with an invalid hop-count |
ndp.tcl |
ipv6_ndp_12 |
Verify DUT ignores Neighbor Solicitations with an invalid hop-count |
step 1. Send an Neighbor Solicitation for the DUT's link-local address with a hop-count of 64
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to DAD-style Neighbor Solicitations for link-local address on LAN |
ndp.tcl |
ipv6_ndp_13 |
Verify DUT responds to DAD-style Neighbor Solicitations for link-local address on LAN |
step 1. Send a Duplicate-Address-Detection (DAD) style Neighbor Solicition
for the DUT's link-local address on the LAN
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify source, destination, and contents of Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection
https://tools.ietf.org/html/rfc4862#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores Neighbor Solicitations with a different target than itself |
ndp.tcl |
ipv6_ndp_14 |
Verify DUT ignores Neighbor Solicitations with a different target than itself |
step 1. Send an Neighbor Solicitation for the lanStack's link-local address to the DUT's link-local address
and its global address
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address |
ndp.tcl |
ipv6_ndp_15 |
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address |
step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrong
Solicited-Node Multicast Address
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to DAD-style Neighbor Solicitations for global address on LAN |
ndp.tcl |
ipv6_ndp_16 |
Verify DUT responds to DAD-style Neighbor Solicitations for global address on LAN |
step 1. Send a Duplicate-Address-Detection (DAD) style Neighbor Solicition
for the DUT's global address on the LAN
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify source, destination, and contents of Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection
https://tools.ietf.org/html/rfc4862#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify DUT sends ICMPv6 Redirect messages for neighbor traffic forwarded to it |
ndp.tcl |
ipv6_ndp_20 |
Verify DUT sends ICMPv6 Redirect messages for neighbor traffic forwarded to it |
step 1: Create a new client on the LAN
step 2: Send a ping to the Global-Unicast-Address of the new client
step 3: Verify the DUT sends an ICMPv6 Redirect messsage
step 4. Verify the ICMPv6 Redirect message
step 5: Verify the new client responds to the ping
NOTE: This test is similar to ipv6_forward_3, except it verifies that the
DUT is sending valid ICMPv6 Redirect messages back to the sender. Test
ipv6_forward_3 verifies that the packet is forwarded to the correct
destination.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 8: Redirect Function
https://tools.ietf.org/html/rfc4861#section-8
| Test |
Module |
Name |
Synopsis |
Verify Router Advertisements contain M bit and O bit based on LAN mode |
ndp.tcl |
ipv6_ndp_30 |
Verify Router Advertisements contain M bit and O bit based on LAN mode |
step 1. Listen for a Router Advertisement on the LAN
step 2. Check the "managed address configuration" flag (M bit) in the Router
Advertisement received in Step 1
step 3. If the DUT is configured to provide global addresses via DHCPv6 on
the LAN, the M bit should be set; if autoconfiguration is used
instead, the M bit should not be set
step 4. If the DUT is configured to provide global addresses via
autoconfiguration on the LAN, and the "other stateful configuration"
flag (O bit) is set, send a DHCPv6 Information-request including an
Option Request for DHCPv6 Options 23 'DNS Recursive Name Server'
and 24 'Domain Search List' to the DUT. Skip to Step 6.
step 5. If the DUT is configured to provide global addresses via
DHCPv6 and the "managed address configuration" flag
(M bit) is set, send a DHCPv6 Information-request including an
Option Request for DHCPv6 Options 23 'DNS Recursive Name Server'
and 24 'Domain Search List' to the DUT
step 6. Verify that the DUT sends a DHCPv6 Reply in response to the DHCPv6
Information-request message sent by the client in Steps 4 or 5
step 7. Verify that the DUT's DHCPv6 Reply includes DHCPv6 Options 23 and 24
Step 8. Verify the DNS server information provided by the DUT. If the testvar
ipv6DNStoLAN is set to "yes", the DNS server addresses provided should
match the addresses of the DNS servers configured on the WAN. If the
ipv6DNStoLAN testvar is set to "no", the LAN side IPv6 address of the
DUT should be provided as the DNS server.
step 9. Verify the domain search list information provided by the DUT
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.2: Router Advertisement Message Format
https://tools.ietf.org/html/rfc4861#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify Router Advertisements contain valid prefix, A bit, and L bit based on LAN settings |
ndp.tcl |
ipv6_ndp_31 |
Verify Router Advertisements contain valid prefix, A bit, and L bit based on LAN settings |
step 1. Listen for Router Advertisements on the LAN for one Router
Advertisement interval
step 2. Verify at least one Router Advertisement contains a valid prefix
based on the DUT's LAN IPv6 address
step 3. Verify that the prefix length associated with the prefix discovered
in Step 2 is the same as the DUT's configured LAN prefix length
(skip this step if the IPv6 WAN mode is 6to4)
step 4. Verify that the prefix discovered in Step 2 contains a valid
lifetime
step 5. Check the autonomous address-configuration flag (A bit) in the
Router Advertisement received in Step 1
step 6. If the DUT is configured to provide global addresses via DHCPv6 on
the LAN, the A bit should not be set; if autoconfiguration is used
instead, the A bit should be set
step 7. Verify that the prefix discovered in Step 2 has the on-link flag
(L bit) set
NOTE: This test is designed to work with DUT's that support only a single
LAN mode for address autoconfiguration, either DHCPv6 or autoconfiguration.
DUT configurations in which both modes are enabled simultaneously (where
the 'A' and 'M' bits are both set) are not currently supported by this test.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information
https://tools.ietf.org/html/rfc4861#section-4.6.2
| Test |
Module |
Name |
Synopsis |
Verify Router Advertisements contain RDNSS option |
ndp.tcl |
ipv6_ndp_32 |
Verify Router Advertisements contain RDNSS option |
step 1. Listen for a Router Advertisement on the LAN
step 2. Verify that one or more RDNSS options (25) are present in RA
step 3. Verify the addresses provided in RDNSS options. If the testvar
ipv6DNStoLAN is set to "yes", the DNS server addresses listed
in the RDNSS option should match the addresses of the DNS
servers configured on the WAN. If the ipv6DNStoLAN testvar is
set to "no", the RDNSS option should list only the LAN side
IPv6 address of the DUT (global or link-local address).
step 4. Verify the RDNSS option lifetime
NOTE: This test is skipped if the testvar ipv6RdnssSupport is set to no
indicating that the device does not support the RDNSS option.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 6106 "IPv6 Router Advertisement Options for DNS Configuration"
https://tools.ietf.org/html/rfc6106
| Test |
Module |
Name |
Synopsis |
Verify Router Advertisements contain DNSSL option |
ndp.tcl |
ipv6_ndp_33 |
Verify Router Advertisements contain DNSSL option |
step 1. Listen for a Router Advertisement on the LAN
step 2. Verify that one or more DNSSL options (31) are present in RA
step 3. Verify the domain search list provided in the DNSSL option. The
domain search list should contain the domain name specified by the
testvar wanDomainName.
step 4. Verify the DNSSL option lifetime
NOTE: This test is skipped if the testvar ipv6DnsslSupport is set to no
indicating that the device does not support the DNSSL option.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 6106 "IPv6 Router Advertisement Options for DNS Configuration"
https://tools.ietf.org/html/rfc6106
| Test |
Module |
Name |
Synopsis |
Verify DUT does not advertise itself as a default router when WAN RA lifetime is 0 |
ndp.tcl |
ipv6_ndp_34 |
Verify DUT does not advertise itself as a default router when WAN RA lifetime is 0 |
step 1. Send Router Advertisements on the WAN with a Router Lifetime of 0
step 2. Listen for RAs from the DUT on the LAN for up to the [dhcpv6PDLatency
+ 1 LAN RA interval]
step 3. Verify that the DUT eventually stops advertising itself as a default
router by setting the Router Lifetime in LAN RAs to a value of 0
step 3. Restore original Router Lifetime on WAN and start sending Router
Advertisements on the WAN with a non-zero Router Lifetime
step 4. Verify that the DUT starts advertising itself as a default router by
setting the Router Lifetime in LAN RAs to a value greater than 0
step 5. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-4: By default, an IPv6 CE router that has no default
router(s) on its WAN interface MUST NOT advertise
itself as an IPv6 default router on its LAN interfaces.
That is, the "Router Lifetime" is set to zero in all
Router Advertisement messages it originates [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify Neighbor Unreachability Detection |
ndp.tcl |
ipv6_ndp_40 |
Verify Neighbor Unreachability Detection |
step 1. Disable LAN client to prevent the DUT from receiving
reachability confirmations
step 2. Wait (ReachableTime + DELAY_FIRST_PROBE_TIME +
(MAX_UNICAST_SOLICIT * RetransTimer)) seconds to ensure DUT's
neighbor cache entry (NCE) for LAN client is deleted
step 3. Enable LAN client
step 4. Send a Neighbor Solicitation on the LAN for the DUT's
link-local address to create a NCE on the DUT for the LAN
client's link-local address in the STALE state
step 5. Verify a Neighbor Advertisement is received from the DUT
step 6. Send an ICMPv6 Echo Request from the LAN to the DUT's
link-local address to transition the NCE on the DUT from
STALE to DELAY state.
step 7. Verify an ICMPv6 Echo Reply is received from the DUT
step 8. Disable neighbor discovery (ND) on LAN client to prevent
the sending of Neighbor Advertisements
step 9. Wait DELAY_FIRST_PROBE_TIME-1 seconds to allow the NCE on
the DUT to transition from DELAY to PROBE state
step 10. Wait RetransTimer+1 seconds for the DUT to send a unicast
Neighbor Solicitation for the LAN client's link local address
step 11. Verify LAN client receives a unicast Neighbor Solicitation
step 12. Repeat steps 10 and 11 to ensure that MAX_UNICAST_SOLICIT
Neighbor Solications are sent. On the
MAX_UNICAST_SOLICIT'th Neighbor Solication, reenable
neighbor discovery on LAN client and respond to the
Neighbor Solicitation with a Neighbor Advertisement to
allow the DUT's NCE to transition from PROBE to REACHABLE
state
step 13. Disable LAN client to prevent the DUT from receiving
reachability confirmations
step 14. Wait ReachableTime+1 seconds to allow DUT's NCE to
transition from REACHABLE to STALE state
step 15. Enable LAN client
step 16. Send an ICMPv6 Echo Request from the LAN to the DUT's
link-local address to transition the NCE on the DUT from
STALE to DELAY state.
step 17. Verify an ICMPv6 Echo Reply is received from the DUT
step 18. Disable neighbor discovery (ND) on LAN client to prevent
the sending of Neighbor Advertisements
step 19. Wait DELAY_FIRST_PROBE_TIME-1 seconds to allow the NCE on
the DUT to transition from DELAY to PROBE state
step 20. Wait RetransTimer+1 seconds for the DUT to send a unicast
Neighbor Solicitation for the LAN client's link local address
step 21. Verify LAN client receives a unicast Neighbor Solicitation
step 22. Repeat steps 20 and 21 to ensure that MAX_UNICAST_SOLICIT
Neighbor Solications are sent. The DUT's NCE should now
be deleted
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 7.3: Neighbor Unreachability Detection
https://tools.ietf.org/html/rfc4861#section-7.3
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Destination Unreachable sent on address resolution failure |
ndp.tcl |
ipv6_ndp_41 |
Verify ICMPv6 Destination Unreachable sent on address resolution failure |
step 1. Wait 60 seconds to ensure DUT has no neighbor cache entry
(NCE) for ipv6WanIspNextIp
step 2. Send an ICMPv6 Echo Request from the LAN to ipv6WanIspNextIp
step 3. Wait 2 seconds for DUT to send a Neighbor Solicitation on
the WAN.
step 4. Verify that the Neighbor Solicitation is sent to the
solicited-node multicast corresponding to ipv6WanIspNextIp
with target ipv6WanIspNextIp and includes a Source
Link-Layer Address option
step 5. Repeat steps 3 & 4 MAX_MULTICAST_SOLICIT (3) times
step 6. Verify DUT sends an ICMPv6 Destination Unreachable message
to the LAN client with code 3 (Address Unreachable)
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 7.2.2: Sending Neighbor Solicitations
https://tools.ietf.org/html/rfc4861#section-7.2.2
ndp-wan.tcl
Neighbor Discovery Protocol and Router Advertisement tests for the WAN side of IPv6 devices
| Test |
Module |
Name |
Synopsis |
Verify if DUT responds to Router Solicitations on the WAN |
ndp-wan.tcl |
ipv6_ndp_wan_1 |
Verify if DUT responds to Router Solicitations on the WAN |
step 1. Send a Router Solicitation from the WAN
step 2. Wait to see if DUT sends a Router Advertisement on the WAN
step 3. Verify the expected behavior
Note: The testvar ipv6ExpectRAonWan determines if this test should
expect to see Router Advertisements from the DUT on the WAN
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify if DUT periodically sends unsolicited Router Advertisements |
ndp-wan.tcl |
ipv6_ndp_wan_2 |
Verify if DUT periodically sends unsolicited Router Advertisements |
step 1. Wait for a Router Advertisement on the WAN
step 2. Wait for a second Router Advertisement on the WAN
step 3. Verify if the DUT is periodically sending Advertisments as expected
Notes: The testvar ipv6ExpectRAonWan determines if this test should
expect to see Router Advertisements from the DUT on the WAN
The testvar ipv6RAInterval will control how long
this test waits for a Router Advertisement.
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations on the WAN for its link-local address |
ndp-wan.tcl |
ipv6_ndp_wan_10 |
Verify DUT responds to Neighbor Solicitations on the WAN for its link-local address |
step 1. Send a Neighbor Solicitation on the WAN for the DUT's link-local address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify fields of the Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations on the WAN for its global IPv6 address |
ndp-wan.tcl |
ipv6_ndp_wan_11 |
Verify DUT responds to Neighbor Solicitations on the WAN for its global IPv6 address |
step 1. Send a Neighbor Solicitation on the WAN for the DUT's global IPv6 address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify fields of Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores invalid Neighbor Solicitations sent on the WAN |
ndp-wan.tcl |
ipv6_ndp_wan_12 |
Verify DUT ignores invalid Neighbor Solicitations sent on the WAN |
step 1. Send an invalid Neighbor Solicitation for the DUT's WAN-side global address
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its link local address |
ndp-wan.tcl |
ipv6_ndp_wan_13 |
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its link local address |
step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's
link-local address on the WAN
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify source, destination, and contents of Neighbor Advertisement
Reference: RFC 4862 Section 5.4
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection
https://tools.ietf.org/html/rfc4862#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores Neighbor Solicitations with a different target than itself |
ndp-wan.tcl |
ipv6_ndp_wan_14 |
Verify DUT ignores Neighbor Solicitations with a different target than itself |
step 1. Send an Neighbor Solicitation for the wanStack's link-local address to the DUT's
link-local address and its global address
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address |
ndp-wan.tcl |
ipv6_ndp_wan_15 |
Verify DUT ignores Neighbor Solicitations sent to the wrong Solicited-Node Multicast Address |
step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrong
Solicited-Node Multicast Address
step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisement
step 3. Send a valid Neighbor Solicitation to make sure DUT is properly responding
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its global IPv6 address |
ndp-wan.tcl |
ipv6_ndp_wan_16 |
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN for its global IPv6 address |
step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's
global address on the WAN
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify source, destination, and contents of Neighbor Advertisement
References:
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection
https://tools.ietf.org/html/rfc4862#section-5.4
dhcpv6-c.tcl
DHCPv6 client tests for the WAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify client requests the assignment of a non-temporary address |
dhcpv6-c.tcl |
dhcpv6_1 |
Verify client requests the assignment of a non-temporary address |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify Valid and Preferred lifetimes for binding
step 4. Verify that the binding has not expired
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17: DHCP Server Solicitation
https://tools.ietf.org/html/rfc3315#section-17
| Test |
Module |
Name |
Synopsis |
Verify client renews non-temporary address when current binding expires |
dhcpv6-c.tcl |
dhcpv6_2 |
Verify client renews non-temporary address when current binding expires |
step 1. Wait for DHCPv6 client's current non-temporary address binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains Server Identifier option (2) with correct
server DUID
step 4. Verify Renew contains IA_NA option (3) for same non-temporary
address
step 5. Send valid Reply to update binding
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.3: Creation and Transmission of Renew Messages
To extend the valid and preferred lifetimes for the addresses
associated with an IA, the client sends a Renew message to the server
from which the client obtained the addresses in the IA containing an
IA option for the IA. The client includes IA Address options in the
IA option for the addresses associated with the IA. The server
determines new lifetimes for the addresses in the IA according to the
administrative configuration of the server.
https://tools.ietf.org/html/rfc3315#section-18.1.3
| Test |
Module |
Name |
Synopsis |
Verify client obtains address from server using various undefined server DUID values |
dhcpv6-c.tcl |
dhcpv6_4 |
Verify client obtains address from server using various undefined server DUID values |
step 1. Configure the server to use an undefined server DUID format
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message and obtains an IPv6 address
step 5. Repeat steps 1 - 4 for various undefined DUID server formats
step 6. Reestablish the DHCPv6 binding using the original DUID format
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)
https://tools.ietf.org/html/rfc3315#section-9
| Test |
Module |
Name |
Synopsis |
Verify client ignores replies with mismatched client DUID |
dhcpv6-c.tcl |
dhcpv6_10 |
Verify client ignores replies with mismatched client DUID |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Respond to first Solicit message with incorrect Client
Identifier option(1) DUID
step 6. Verify client restransmits Solicit message
step 7. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Messages
If the client does not receive any Advertise messages before the
first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and the client
acts on the received Advertise message without waiting for any
additional Advertise messages.
https://tools.ietf.org/html/rfc3315#section-17.1.2
| Test |
Module |
Name |
Synopsis |
Verify client ignores unknown or invalid DHCPv6 packets |
dhcpv6-c.tcl |
dhcpv6_11 |
Verify client ignores unknown or invalid DHCPv6 packets |
step 1. Send invalid DHCPv6 packet with message type 0 to client
on the WAN
step 2. Verify that client does not respond to packet transmitted
in Step 1
step 3. Repeat steps 1 and 2 for message types 1 through 255
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify client handles fragmented IPv6 packets |
dhcpv6-c.tcl |
dhcpv6_14 |
Verify client handles fragmented IPv6 packets |
step 1. Configure DHCPv6 server to use a large User Class option (15)
to force IPv6 fragmentation
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message
step 5. Respond to first Solicit message with Advertise containing
large User Class Option (15) causing fragmentation
step 6. Verify client sends valid Request in response to Advertise
step 7. Disable server User Class option (15) created in Step 1
step 8. If client fails Step 6, cleanup and wait for client to
retransmit Solicit message
step 9. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1: Client Behavior
https://tools.ietf.org/html/rfc3315#section-18.1
| Test |
Module |
Name |
Synopsis |
Verify client ignores server messages with invalid UDP checksum |
dhcpv6-c.tcl |
dhcpv6_15 |
Verify client ignores server messages with invalid UDP checksum |
step 1. Configure DHCPv6 server to use bad UDP checksums
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message
step 5. Respond to first Solicit message with Advertise containing
invalid UDP checksum
step 6. Verify client does not send valid Request in response to
Advertise
step 7. Configure DHCPv6 server to use valid UDP checksums
step 8. Wait for client to retransmit Solicit message
step 9. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify client composes DUID correctly |
dhcpv6-c.tcl |
dhcpv6_16 |
Verify client composes DUID correctly |
step 1. Wait for DHCPv6 client's current non-temporary address binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Inspect the composition of the DUID to ensure correctness
Reference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)
https://tools.ietf.org/html/rfc3315#section-9
| Test |
Module |
Name |
Synopsis |
Verify client restarts when NoBinding failure occurs during Renew |
dhcpv6-c.tcl |
dhcpv6_20 |
Verify client restarts when NoBinding failure occurs during Renew |
step 1. Wait for DHCPv6 client's current non-temporary address binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains IA_NA option (3) for same non-temporary
address
step 4. Send valid DHCPv6 Reply with NoBinding status code (3)
step 5. Verify DHCPv6 client sends Request message
step 6. Verify Request contains IA_NA option (3) for same non-temporary
address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.8: Receipt of Reply Messages
When the client receives a Reply message in response to a Renew or
Rebind message, the client examines each IA independently. For each
IA in the original Renew or Rebind message, the client:
- sends a Request message if the IA contained a Status Code option
with the NoBinding status (and does not send any additional
Renew/Rebind messages)
- sends a Renew/Rebind if the IA is not in the Reply message
- otherwise accepts the information in the IA
https://tools.ietf.org/html/rfc3315#section-18.1.8
| Test |
Module |
Name |
Synopsis |
Verify client restarts when UnspecFail failure occurs during Renew |
dhcpv6-c.tcl |
dhcpv6_21 |
Verify client restarts when UnspecFail failure occurs during Renew |
step 1. Wait for DHCPv6 client's current non-temporary address binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains IA_NA option (3) for same non-temporary
address
step 4. Send valid DHCPv6 Reply with UnspecFail status code (1)
step 5. Verify DHCPv6 client recovers by retransmitting Renew or
sending Request
step 6. Verify Renew or Request contains IA_NA option (3) for same
non-temporary address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.8: Receipt of Reply Messages
If the client receives a Reply message with a Status Code containing
UnspecFail, the server is indicating that it was unable to process
the message due to an unspecified failure condition. If the client
retransmits the original message to the same server to retry the
desired operation, the client MUST limit the rate at which it
retransmits the message and limit the duration of the time during
which it retransmits the message.
https://tools.ietf.org/html/rfc3315#section-18.1.8
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 |
dhcpv6-c.tcl |
dhcpv6_22 |
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 |
step 1. Allow the DHCPv6 client to restart DHCPv6 by waiting for the IA_NA
lifetime to expire without replying to any DHCPv6 messages
step 2. Send a valid Advertise message in response to the DHCPv6 client's
Solicit message
step 3. Verify the DHCPv6 client sends a Request message
step 4. Send a valid Reply message with all IA lifetimes set to 0
step 5. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 6. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 7. Verify DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 |
dhcpv6-c.tcl |
dhcpv6_23 |
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 |
step 1. Wait for DHCPv6 client's current IA_NA binding T1 timer to expire
step 2. Verify the DHCPv6 client sends a DHCPv6 Renew
step 3. Send a valid Reply message with all IA lifetimes set to 0
step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 |
dhcpv6-c.tcl |
dhcpv6_24 |
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 |
step 1. Wait for DHCPv6 client's current IA_NA binding T2 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Rebind
step 3. Send a valid Reply message with all IA lifetimes set to 0
step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client sends Rebind message if Renew for non-temporary address fails |
dhcpv6-c.tcl |
dhcpv6_30 |
Verify client sends Rebind message if Renew for non-temporary address fails |
step 1. Wait for DHCPv6 client's current non-temporary address binding
T1 to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Do not respond to Renew message
step 4. Verify DHCPv6 client sends Rebind message
step 5. Verify Rebind contains IA_NA option (3) for same non-temporary
address
step 6. Send valid Reply to update binding
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
https://tools.ietf.org/html/rfc3315#section-18.1.4
| Test |
Module |
Name |
Synopsis |
Verify client sends Solicit message if Renew and Rebind for non-temporary address fails |
dhcpv6-c.tcl |
dhcpv6_31 |
Verify client sends Solicit message if Renew and Rebind for non-temporary address fails |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages
The message exchange is terminated when the valid lifetimes of all
the addresses assigned to the IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:
- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server.
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs.
https://tools.ietf.org/html/rfc3315#section-18.1.4
| Test |
Module |
Name |
Synopsis |
Verify client supports DHCPv6 Reconfigure Key Authentication |
dhcpv6-c.tcl |
dhcpv6_32 |
Verify client supports DHCPv6 Reconfigure Key Authentication |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding
exists
step 3. Verify DHCPv6 Reconfigure Key exists for binding
step 4. Send Reconfigure message requesting Renew
step 5. Verify DHCPv6 client sends DHCPv6 Renew
Reference:
IETF RFC 3315 Section 21.5 "Reconfigure Key Authentication Protocol"
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 21.5: Reconfigure Key Authentication Protocol
https://tools.ietf.org/html/rfc3315#section-21.5
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPv6 Reconfigure without Authentication option |
dhcpv6-c.tcl |
dhcpv6_33 |
Verify client ignores DHCPv6 Reconfigure without Authentication option |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding
exists
step 3. Verify DHCPv6 Reconfigure Key exists for binding
step 4. Send Reconfigure message requesting Renew without
Authentication option
step 5. Verify DHCPv6 client does not send DHCPv6 Renew, Rebind or
Information-Request
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.11: Reconfigure Message
https://tools.ietf.org/html/rfc3315#section-15.11
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPv6 Reconfigure with incorrect Reconfigure Key |
dhcpv6-c.tcl |
dhcpv6_34 |
Verify client ignores DHCPv6 Reconfigure with incorrect Reconfigure Key |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding
exists
step 3. Verify DHCPv6 Reconfigure Key exists for binding
step 4. Send Reconfigure message requesting Renew using
incorrect DHCPv6 Reconfigure Key
step 5. Verify DHCPv6 client does not send DHCPv6 Renew, Rebind or
Information-Request
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.11: Reconfigure Message
https://tools.ietf.org/html/rfc3315#section-15.11
| Test |
Module |
Name |
Synopsis |
Verify client supports DHCPv6 Reconfigure with Rebind request |
dhcpv6-c.tcl |
dhcpv6_35 |
Verify client supports DHCPv6 Reconfigure with Rebind request |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding
exists
step 3. Verify DHCPv6 Reconfigure Key exists for binding
step 4. Send Reconfigure message requesting Rebind
step 5. Verify DHCPv6 client sends DHCPv6 Rebind
References:
IETF RFC 6644 "Rebind Capability in DHCPv6 Reconfigure Messages" Section 5: Client Behavior
https://tools.ietf.org/html/rfc6644#section-5
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPv6 Reconfigure requesting a Solicit |
dhcpv6-c.tcl |
dhcpv6_36 |
Verify client ignores DHCPv6 Reconfigure requesting a Solicit |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not a non-temporary address binding
exists
step 3. Verify DHCPv6 Reconfigure Key exists for binding
step 4. Send Reconfigure message requesting Solicit
step 5. Verify DHCPv6 client does not send DHCPv6 Solicit, Renew,
Rebind or Information-Request
References:
IETF RFC 6644 "Rebind Capability in DHCPv6 Reconfigure Messages" Section 5: Client Behavior
https://tools.ietf.org/html/rfc6644#section-5
| Test |
Module |
Name |
Synopsis |
Verify client retransmits DHCPv6 Solicit messages for non-temporary address |
dhcpv6-c.tcl |
dhcpv6_50 |
Verify client retransmits DHCPv6 Solicit messages for non-temporary address |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Do not respond to first Solicit message
step 6. Verify client restransmits Solicit message
step 7. Verify retransmitted Solicit message contains same transaction
ID as first Solicit message
step 8. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.1: Use of Transaction IDs
The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
https://tools.ietf.org/html/rfc3315#section-15.1
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Messages
If the client does not receive any Advertise messages before the
first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and the client
acts on the received Advertise message without waiting for any
additional Advertise messages.
https://tools.ietf.org/html/rfc3315#section-17.1.2
| Test |
Module |
Name |
Synopsis |
Verify client retransmits DHCPv6 Request messages for non-temporary address |
dhcpv6-c.tcl |
dhcpv6_51 |
Verify client retransmits DHCPv6 Request messages for non-temporary address |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Send valid Advertise message
step 6. Verify client sends Request message containing IA_NA option (3)
step 7. Do not respond to Request message
step 8. Verify client retransmists Request message
step 9. Verify retransmitted Request message contains same transaction
ID as first Request message
step 10. Send valid Advertise message and wait for transaction to
finish
Reference: IETF RFC 3315 Section 14 "Reliability of Client Initiated
Message Exchanges"
DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 17 and 18.
If a DHCP client fails to receive an expected response from a server,
the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated
message exchanges.
NOTE: This test will not work if Rapid-Commit is used!
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 14: Reliability of Client Initiated Message Exchanges
The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
https://tools.ietf.org/html/rfc3315#section-14
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.1: Use of Transaction IDs
The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
https://tools.ietf.org/html/rfc3315#section-15.1
| Test |
Module |
Name |
Synopsis |
Verify client learns new non-temporary address when WAN DHCPv6 server renumbers |
dhcpv6-c.tcl |
dhcpv6_60 |
Verify client learns new non-temporary address when WAN DHCPv6 server renumbers |
step 1. Change the client's DHCPv6 binding to use the new
non-temporary IPv6 address address specified by the testvar
"ipv6WanIspNextIp"
step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
step 3. Verify Renew or Request contains IA_NA option (3) for same
non-temporary address
step 4. Send valid DHCPv6 Reply with new non-temporary address
step 5. Verify client updates with new non-temporary address
step 6. Ping client's new non-temporary address
step 7. Restore client's original non-temporary address by repeating
Steps 1 through 5 using original non-temporary address
step 8. Ping client's original non-temporary address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.8: Receipt of Reply Messages
If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client updates
the information it has recorded about IAs from the IA options
contained in the Reply message:
- Record T1 and T2 times.
- Add any new addresses in the IA option to the IA as recorded by
the client.
- Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA.
- Discard any addresses from the IA, as recorded by the client, that
have a valid lifetime of 0 in the IA Address option.
- Leave unchanged any information about addresses the client has
recorded in the IA but that were not included in the IA from the
server.
https://tools.ietf.org/html/rfc3315#section-18.1.8
| Test |
Module |
Name |
Synopsis |
Verify client obtains IPv6 address when server uses unknown DHCPv6 options |
dhcpv6-c.tcl |
dhcpv6_100 |
Verify client obtains IPv6 address when server uses unknown DHCPv6 options |
step 1. Configure DHCPv6 server to use unknown DHCPv6 option type
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message
step 5. Respond to first Solicit message with Advertise containing
unknown DHCPv6 option type
step 6. Verify client sends valid Request in response to Advertise
step 7. Disable unknown DHCPv6 server option
step 8. If client fails Step 6, cleanup and wait for client to
retransmit Solicit message
step 9. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1: Client Behavior
https://tools.ietf.org/html/rfc3315#section-18.1
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPv6 messages with unknown options and invalid option length |
dhcpv6-c.tcl |
dhcpv6_101 |
Verify client ignores DHCPv6 messages with unknown options and invalid option length |
step 1. Configure DHCPv6 server to use unknown DHCPv6 option type
with invalid length
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message
step 5. Respond to first Solicit message with Advertise containing
unknown DHCPv6 option type
step 6. Verify client does not send valid Request in response to
Advertise
step 7. Disable unknown DHCPv6 server option
step 8. Wait for client to retransmit Solicit message
step 9. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify client includes the Elapsed Time option with value 0 in first message |
dhcpv6-c.tcl |
dhcpv6_102 |
Verify client includes the Elapsed Time option with value 0 in first message |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Verify Solicit contains Elapsed Time option (8) with value of 0
step 6. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.9: Elapsed Time Option
A client MUST include an Elapsed Time option in messages to indicate
how long the client has been trying to complete a DHCP message
exchange. The elapsed time is measured from the time at which the
client sent the first message in the message exchange, and the
elapsed-time field is set to 0 in the first message in the message
exchange.
https://tools.ietf.org/html/rfc3315#section-22.9
| Test |
Module |
Name |
Synopsis |
Verify client increases value of Elapsed Time option when Solicit is retransmitted |
dhcpv6-c.tcl |
dhcpv6_103 |
Verify client increases value of Elapsed Time option when Solicit is retransmitted |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_NA option (3)
step 5. Verify Solicit contains Elapsed Time option (8) with value of 0
step 6. Do not respond to Solicit
step 7. Verify client retransmists Solicit message
step 8. Verify retransmitted Solicit message contains Elapsed Time option
(8) with a value greater than 0
step 9. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.9: Elapsed Time Option
A client MUST include an Elapsed Time option in messages to indicate
how long the client has been trying to complete a DHCP message
exchange. The elapsed time is measured from the time at which the
client sent the first message in the message exchange, and the
elapsed-time field is set to 0 in the first message in the message
exchange.
https://tools.ietf.org/html/rfc3315#section-22.9
| Test |
Module |
Name |
Synopsis |
Verify client handles Server Unicast Option |
dhcpv6-c.tcl |
dhcpv6_130 |
Verify client handles Server Unicast Option |
step 1. Configure DHCPv6 server to use Server Unicast Option (12)
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew or Rebind messages from client
step 4. Verify client sends Solicit message
step 5. Respond to first Solicit message with Advertise containing
Server Unicast Option (12)
step 6. Verify client sends valid Renew message
step 7. Verify Renew message in Step 6 is sent to the address in
the Server Unicast Option (12)
step 8. Disable Server Unicast option (12) created in Step 1
step 9. If client fails Step 6, cleanup and wait for client to
retransmit Solicit message
step 10. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.12: Server Unicast Option
https://tools.ietf.org/html/rfc3315#section-22.12
| Test |
Module |
Name |
Synopsis |
Verify client handles SOL_MAX_RT Option |
dhcpv6-c.tcl |
dhcpv6_140 |
Verify client handles SOL_MAX_RT Option |
step 1. Configure DHCPv6 server to use Max Solicit Timeout Option (82)
step 2. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 3. Do not respond to Renew, Rebind or Solicit messages from
client
step 4. Verify client sends Solicit message
step 5. Verify client uses the value of the Max
Solicit Timeout option returned by the DHCPv6 server to
limit the maximum delay for retransmissions of its
Solicit message
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 14: Reliability of Client Initiated Message Exchanges
https://tools.ietf.org/html/rfc3315#section-14
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 17.1.2: Transmission of Solicit Message
https://tools.ietf.org/html/rfc3315#section-17.1.2
IETF RFC 7083 "DHCPv6 SOL_MAX_RT Option" Section 6: Updates for SOL_MAX_RT and INF_MAX_RT Options to RFC 3315
https://tools.ietf.org/html/rfc7083#section-6
| Test |
Module |
Name |
Synopsis |
Verify DHCPv6 client includes vendor defined options |
dhcpv6-c.tcl |
dhcpv6_150 |
Verify DHCPv6 client includes vendor defined options |
step 1. Wait for DHCPv6 client to renew address
step 2. Search DHCPv6 Renew message from client for expected options
The testvars wanDhcpv6ClientOptionCode and wanDhcpv6ClientOptionData can be
used to configure a list of DHCP options that the client should include in
requests sent to the DHCP server.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify client supports DHCPv6 Rapid Commit option |
dhcpv6-c.tcl |
dhcpv6_160 |
Verify client supports DHCPv6 Rapid Commit option |
step 1. Wait for DHCPv6 client's current non-temporary address binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains the 'Rapid Commit' option
step 5. Send valid Reply message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.14: Rapid Commit Option
A client MAY include this option in a Solicit message if the client
is prepared to perform the Solicit-Reply message exchange described
in section 17.1.1.
A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit-Reply message
exchange.
https://tools.ietf.org/html/rfc3315#section-22.14
dhcpv6-pd.tcl
DHCPv6 prefix delegation tests for WAN to LAN IPv6 configuration
| Test |
Module |
Name |
Synopsis |
Verify client requests the assignment of an IPv6 prefix |
dhcpv6-pd.tcl |
dhcpv6_pd_1 |
Verify client requests the assignment of an IPv6 prefix |
step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
step 2. Verify whether or not prefix binding exists
step 3. Verify Valid and Preferred lifetimes for binding
step 4. Verify that the binding has not expired
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
The requesting router uses a Request message to populate IA_PDs with
prefixes. The requesting router includes one or more IA_PD options
in the Request message. The delegating router then returns the
prefixes for the IA_PDs to the requesting router in IA_PD options in
a Reply message.
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify client renews prefix when current binding expires |
dhcpv6-pd.tcl |
dhcpv6_pd_2 |
Verify client renews prefix when current binding expires |
step 1. Wait for DHCPv6 client's current prefix binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains Server Identifier option (2) with correct
server DUID
step 4. Verify Renew contains IA_NA option (3) for same address
prefix
step 5. Send valid Reply to update binding
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 7: Overview of DHCP with Prefix Delegation
Before the valid lifetime on each delegated prefix expires, the
requesting router includes the prefix in an IA_PD option sent in a
Renew message to the delegating router. The delegating router
responds by returning the prefix with updated lifetimes to the
requesting router.
https://tools.ietf.org/html/rfc3633#section-7
| Test |
Module |
Name |
Synopsis |
Verify client sends router advertisements on LAN with delegated prefix |
dhcpv6-pd.tcl |
dhcpv6_pd_10 |
Verify client sends router advertisements on LAN with delegated prefix |
step 1. Listen for IPv6 router advertisements from DUT on LAN
step 2. Verify that router advertisement contains Prefix Information
option (3) with valid prefix based on prefix assigned
by DHCPv6 server on WAN
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
https://tools.ietf.org/html/rfc3633#section-12.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify client sends router advertisements on LAN with prefix lifetimes based on IA_PD lifetimes |
dhcpv6-pd.tcl |
dhcpv6_pd_11 |
Verify client sends router advertisements on LAN with prefix lifetimes based on IA_PD lifetimes |
step 1. Listen for IPv6 router advertisements from DUT on LAN
step 2. Verify that router advertisement contains Prefix Information
option (3) with valid prefix based on prefix assigned
by DHCPv6 server on WAN
step 3. Verify Prefix Information option (3) contains a Valid lifetime
not greater than the valid lifetime provided by the DHCPv6
server in the IA_PD Prefix option
step 4. Verify Prefix Information option (3) contains a Preferred
lifetime not greater than the preferred lifetime provided by
the DHCPv6 server in the IA_PD Prefix option
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
If the requesting router assigns a delegated prefix to a link to
which the router is attached, and begins to send router
advertisements for the prefix on the link, the requesting router MUST
set the valid lifetime in those advertisements to be no later than
the valid lifetime specified in the IA_PD Prefix option. A
requesting router MAY use the preferred lifetime specified in the
IA_PD Prefix option.
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address is based on WAN side delegated prefix |
dhcpv6-pd.tcl |
dhcpv6_pd_12 |
Verify LAN side DHCPv6 client address is based on WAN side delegated prefix |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address prefix on the LAN
matches the prefix delegated on the WAN
NOTE: This test only applies to configurations where LAN clients
obtain IPv6 addresses via DHCPv6
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client lifetime is based on WAN side IA_PD prefix lifetimes |
dhcpv6-pd.tcl |
dhcpv6_pd_13 |
Verify LAN side DHCPv6 client lifetime is based on WAN side IA_PD prefix lifetimes |
step 1. Listen for IPv6 router advertisements from DUT on LAN
step 2. Verify that router advertisement contains Prefix Information
option (3) with valid prefix based on prefix assigned
by DHCPv6 server on WAN
step 3. Verify Prefix Information option (3) contains a Valid lifetime
not greater than the valid lifetime provided by the DHCPv6
server in the IA_PD Prefix option
step 4. Verify Prefix Information option (3) contains a Preferred
lifetime not greater than the preferred lifetime provided by
the DHCPv6 server in the IA_PD Prefix option
| Test |
Module |
Name |
Synopsis |
Verify client router advertisements on LAN include expected subnet ID |
dhcpv6-pd.tcl |
dhcpv6_pd_14 |
Verify client router advertisements on LAN include expected subnet ID |
step 1. Listen for IPv6 RA from DUT
step 2. Verify RA contains prefix based on public IPv4 WAN
step 3. Verify advertised prefix includes the expected subnet ID
Note: The expected subnet ID bits can be configured using the testvar
ipv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length string
of hex characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
| Test |
Module |
Name |
Synopsis |
Verify DUT does not advertise itself as a default router when WAN link is down |
dhcpv6-pd.tcl |
dhcpv6_pd_15 |
Verify DUT does not advertise itself as a default router when WAN link is down |
step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
server and wait for the current IA_NA and/or IA_PD bindings to
expire
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT eventually stops advertising itself as a default
router by setting the Router Lifetime in LAN RAs to a value of 0
step 4. Restore all services on the WAN and wait for the WAN link to be
re-established by the DUT
step 5. Verify that the DUT starts advertising itself as a default router by
setting the Router Lifetime in LAN RAs to a value greater than 0
step 7. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-4: By default, an IPv6 CE router that has no default
router(s) on its WAN interface MUST NOT advertise
itself as an IPv6 default router on its LAN interfaces.
That is, the "Router Lifetime" is set to zero in all
Router Advertisement messages it originates [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts when NoBinding failure occurs during IA_PD Renew |
dhcpv6-pd.tcl |
dhcpv6_pd_20 |
Verify client restarts when NoBinding failure occurs during IA_PD Renew |
step 1. Wait for DHCPv6 client's current prefix binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains IA_PD option (26) for same address
prefix
step 4. Send valid DHCPv6 Reply with NoBinding status code (3)
step 5. Verify DHCPv6 client sends Request message
step 6. Verify Request contains IA_PD option (26) for same address
prefix
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts when UnspecFail failure occurs during IA_PD Renew |
dhcpv6-pd.tcl |
dhcpv6_pd_21 |
Verify client restarts when UnspecFail failure occurs during IA_PD Renew |
step 1. Wait for DHCPv6 client's current prefix binding
T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Verify Renew contains IA_PD option (26) for same address
prefix
step 4. Send valid DHCPv6 Reply with UnspecFail status code (1)
step 5. Verify DHCPv6 client recovers by retransmitting Renew or
sending Request
step 6. Verify Renew or Request contains IA_PD option (26) for same
prefix
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 |
dhcpv6-pd.tcl |
dhcpv6_pd_22 |
Verify client restarts DHCPv6 when Reply to Request contains IA lifetimes set to 0 |
step 1. Allow the DHCPv6 client to restart DHCPv6 by waiting for the IA_PD
lifetime to expire without replying to any DHCPv6 messages
step 2. Send a valid Advertise message in response to the DHCPv6 client's
Solicit message
step 3. Verify the DHCPv6 client sends a Request message
step 4. Send a valid Reply message with all IA lifetimes set to 0
step 5. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 6. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 7. Verify the DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 |
dhcpv6-pd.tcl |
dhcpv6_pd_23 |
Verify client restarts DHCPv6 when Reply to Renew contains IA lifetimes set to 0 |
step 1. Wait for DHCPv6 client's current IA_PD binding T1 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Send a valid Reply message with all IA lifetimes set to 0
step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 |
dhcpv6-pd.tcl |
dhcpv6_pd_24 |
Verify client restarts DHCPv6 when Reply to Rebind contains IA lifetimes set to 0 |
step 1. Wait for DHCPv6 client's current IA_PD binding T2 timer to expire
step 2. Verify DHCPv6 client sends DHCPv6 Rebind
step 3. Send a valid Reply message with all IA lifetimes set to 0
step 4. Verify the DHCPv6 client sends a DHCPv6 Solicit message
step 5. Verify the DHCPv6 client and server complete the DHCPv6 2 or 4 message
exchange
step 6. Verify the DHCPv6 client recovered by waiting for the client to transmit
a Renew at T1
References:
IETF RFC 8415 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.10.1: Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
https://tools.ietf.org/html/rfc8415#section-18.2.10.1
| Test |
Module |
Name |
Synopsis |
Verify client sends Rebind message if Renew for prefix fails |
dhcpv6-pd.tcl |
dhcpv6_pd_30 |
Verify client sends Rebind message if Renew for prefix fails |
step 1. Wait for DHCPv6 client's current prefix binding
T1 to expire
step 2. Verify DHCPv6 client sends DHCPv6 Renew
step 3. Do not respond to Renew message
step 4. Verify DHCPv6 client sends Rebind message
step 5. Verify Rebind contains IA_PD option (26) for same address
prefix
step 6. Send valid Reply to update binding
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
https://tools.ietf.org/html/rfc3315#section-18.1.4
| Test |
Module |
Name |
Synopsis |
Verify client sends Solicit message if Renew and Rebind for prefix fails |
dhcpv6-pd.tcl |
dhcpv6_pd_31 |
Verify client sends Solicit message if Renew and Rebind for prefix fails |
step 1. Wait for DHCPv6 client's current prefix binding
to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains IA_PD option (26)
step 5. Send valid Advertise message and wait for transaction to
finish
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.1.4: Creation and Transmission of Rebind Messages
The message exchange is terminated when the valid lifetimes of all
the addresses assigned to the IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:
- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server.
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs.
https://tools.ietf.org/html/rfc3315#section-18.1.4
| Test |
Module |
Name |
Synopsis |
Verify client learns new IPv6 prefix when WAN DHCPv6 server renumbers |
dhcpv6-pd.tcl |
dhcpv6_pd_60 |
Verify client learns new IPv6 prefix when WAN DHCPv6 server renumbers |
step 1. Change the client's DHCPv6 binding to use the new IPv6
prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
step 3. Verify Renew or Request contains IA_PD option (26) for
same prefix
step 4. Send valid DHCPv6 Reply with new prefix
step 5. Verify client updates router advertisements on LAN with new
prefix information
step 6. Send pings from LAN client to an IPv6 remote host on the
WAN to verify connectivity with new prefix
step 7. Restore client's original prefix by repeating Steps 1
through 5 using original IPv6 prefix
step 8. Send pings from LAN client to an IPv6 remote host on the
WAN to verify connectivity with original prefix
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 server switches to new IPv6 prefix when WAN DHCPv6 server renumbers |
dhcpv6-pd.tcl |
dhcpv6_pd_61 |
Verify LAN side DHCPv6 server switches to new IPv6 prefix when WAN DHCPv6 server renumbers |
step 1. Change the client's DHCPv6 binding to use the new IPv6
prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
step 3. Verify Renew or Request contains IA_PD option (26) for
same prefix
step 4. Send valid DHCPv6 Reply with new prefix
step 5. Verify DHCPv6 client updates router advertisements on LAN with new
prefix information
step 6. Verify DHCPv6 client updates DHCPv6 server on the LAN with new
prefix
step 7. Send pings from LAN DHCPv6 client to an IPv6 remote host
on the WAN to verify connectivity with new prefix
step 8. Restore client's original prefix by repeating Steps 1
through 6 using original IPv6 prefix
step 9. Send pings from LAN DHCPv6 client to an IPv6 remote host
on the WAN to verify connectivity with original prefix
NOTE: This test only applies to configurations where LAN clients
obtain IPv6 addresses via DHCPv6
References:
IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
https://tools.ietf.org/html/rfc3633#section-12.1
| Test |
Module |
Name |
Synopsis |
Verify DUT ages out prefix on LAN when WAN DHCPv6 server renumbers |
dhcpv6-pd.tcl |
dhcpv6_pd_62 |
Verify DUT ages out prefix on LAN when WAN DHCPv6 server renumbers |
step 1. Change the DUT's WAN DHCPv6 client binding to use the new
IPv6 prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
step 2. Listen for router advertisements on the LAN for
"dhcpv6IAValidLifetime" seconds and verify the following:
a. That the original prefix is consistently aged out according to
requirement L-13 of RFC 7084
b. That the valid lifetime of the aged out prefix decreases over
time (if not equal to 0)
c. That the new prefix is consistently advertised
step 3. Restart the LAN IPv6 client and verify that it obtains an
address within the new prefix
step 4. Send pings from the LAN client to an IPv6 remote host
on the WAN to verify connectivity with the new address
step 5. Repeat steps 1 through 4 with the original address and prefix
specified by the testvars "dhcpv6WanAssignIp" and
"dhcpv6WanAssignPrefix"
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Requirements
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero and a Valid
Lifetime of either a) zero or b) the lower of the current
Valid Lifetime and two hours (which must be decremented in
real time) in a Router Advertisement message as described in
Section 5.5.3, (e) of [RFC4862].
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify DUT performs Duplicate Address Detection on global LAN address |
dhcpv6-pd.tcl |
dhcpv6_pd_63 |
Verify DUT performs Duplicate Address Detection on global LAN address |
step 1. Change the DUT's WAN DHCPv6 client binding to use the new
IPv6 prefix specified by the testvar
dhcpv6WanAssignNextPrefix
step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
step 3. Wait up to dhcpv6PDLatency + 10 seconds for a DAD-style
Neighbor Solicitation from the DUT on the LAN
step 4. Verify the following about the received Neighbor
Soliciation
a. That the target address of the Neighbor Solicitation is
the DUT's global IPv6 LAN address in the
dhcpv6WanAssignNextPrefix prefix
b. That the IPv6 source address is the unspecified address
c. That the IPv6 destination address is the solicited-node
multicast address of the DUT's global IPv6 LAN address
in the dhcpv6WanAssignNextPrefix prefix
step 5. Respond to the DUT's DAD-style Neighbor Solicitation by
sending an unsolicited Neighbor Advertisement to the
all-nodes multicast address ff02::1 on the LAN-WAN
step 6. Wait for 2 seconds
step 7. Send an ICMPv6 Echo Request message to the DUT's global
IPv6 LAN address in the dhcpv6WanAssignNextPrefix prefix
step 8. Verify that the DUT does not send an ICMPv6 Echo Response
message
step 9. Change the DUT's WAN DHCPv6 client binding to use the old
IPv6 prefix specified by the testvar dhcpv6WanAssignPrefix
step 10. Verify DHCPv6 client sends DHCPv6 Renew or Request
step 11. Send pings from the LAN client to to the DUT's global IPv6
LAN address in the dhcpv6WanAssignPrefix prefix to
verify connectivity with the new address
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.4: Duplicate Address Detection
https://tools.ietf.org/html/rfc4862#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify client attempts to learn non-temporary address and prefix in a single DHCPv6 session |
dhcpv6-pd.tcl |
dhcpv6_pd_100 |
Verify client attempts to learn non-temporary address and prefix in a single DHCPv6 session |
step 1. Wait for DHCPv6 client's current prefix binding to expire
step 2. Do not respond to Renew or Rebind messages from client
step 3. Verify client sends Solicit message
step 4. Verify Solicit contains both IA_NA option (3) and
IA_PD option (26)
step 5. Send valid Advertise message and wait for transaction to
finish
NOTE: IETF RFC 7084, which updates IETF RFC 6204, removed the
above requirement.
References:
IETF RFC 6204 "Basic Requirements for IPv6 Customer Edge Routers" Section 4.2: WAN-Side Configuration
W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
(IA_PD) SHOULD be done as a single DHCPv6 session.
https://tools.ietf.org/html/rfc6204#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify packets to unreachable subnets in the delegated prefix are dropped |
dhcpv6-pd.tcl |
dhcpv6_pd_110 |
Verify packets to unreachable subnets in the delegated prefix are dropped |
step 1. Build a destination IPv6 address by setting all subnet bits
step 2. This test assumes that this address is not configured on an
interface
step 3. Send a UDP echo to this destination from the LAN client
step 4. Verify the packet is not forwarded to the WAN
Reference: IETF RFC 7084 - Basic Requirements for IPv6 Customer Edge Routers, Requirement WPD-5:
NOTE: This test is only applicable if the delegated prefix length
is less than 64.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
WPD-5: Any packet received by the CE router with a destination
address in the prefix(es) delegated to the CE router but not
in the set of prefixes assigned by the CE router to the LAN
must be dropped. In other words, the next hop for the
prefix(es) delegated to the CE router should be the null
destination. This is necessary to prevent forwarding loops
when some addresses covered by the aggregate are not
reachable [RFC4632].
(a) The IPv6 CE router SHOULD send an ICMPv6 Destination
Unreachable message in accordance with Section 3.1 of
[RFC4443] back to the source of the packet, if the
packet is to be dropped due to this rule.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address includes SLA ID |
dhcpv6-pd.tcl |
dhcpv6_pd_120 |
Verify LAN side DHCPv6 client address includes SLA ID |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address on the LAN includes
the expected SLA ID
RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
DUT's allow the SLA ID to be arbitrarily configured. This test
verifies that the DUT uses the expected SLA ID. The expected SLA
can be configured using the testvar "ipv6LanSubnetId" which must
be a hex string with four or less characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify Route Information option is advertised for delegated prefix |
dhcpv6-pd.tcl |
dhcpv6_pd_130 |
Verify Route Information option is advertised for delegated prefix |
step 1. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 2. Verify that the DUT includes a Route Information option for the
delegated prefix configured using the testvar
dhcpv6WanAssignPrefix
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
https://tools.ietf.org/html/rfc7084#section-4.3
dhcpv6-s.tcl
DHCPv6 server tests for the LAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify server assigns same address after client restart |
dhcpv6-s.tcl |
dhcpv6_server_1 |
Verify server assigns same address after client restart |
step 1. Restart DHCPv6 on LAN client without sending a Release to the server
step 2. Verify that the server assigns an address to the client
step 3. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server returns address within configured pool |
dhcpv6-s.tcl |
dhcpv6_server_2 |
Verify server returns address within configured pool |
step 1. Send DHCPv6 Release to release DHCPv6 client address on LAN
step 2. Restart DHCPv6 client on LAN
step 3. Verify DHCPv6 client receives an address from within the configured
DHCPv6 pool
Note: The DHCPv6 pool is configured using the testvars ipv6DhcpClientStart
and ipv6DhcpClientEnd. These testvars must match the DHCPv6 pool settings on
the DUT.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server returns IP address with expected valid lifetime |
dhcpv6-s.tcl |
dhcpv6_server_3 |
Verify server returns IP address with expected valid lifetime |
step 1. Send DHCPv6 Release to release DHCPv6 client address on LAN
step 2. Restart DHCPv6 client on LAN
step 3. Verify DHCPv6 client receives an address with the expected
valid lifetime
Note: The testvar ipv6DhcpClientValidLifetime can be used to configure the
expected valid lifetime, in seconds, that is used by the DUT's DHCPv6 server
on the LAN.
This testvar can be set to a numeric value if the valid lifetime is fixed,
or it can be set to a value of "dynamic" if the valid lifetime varies based
on the delegated prefix (IA_PD) received on the WAN. If set to "dynamic"
this test will verify that the valid lifetime received on the LAN is less
than or equal to the IA_PD valid lifetime assigned by CDRouter's DHCPv6
server on the WAN (which is configured using the testvar dhcpv6IAValidLifetime).
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server assigns address to client using undefined client DUID values |
dhcpv6-s.tcl |
dhcpv6_server_5 |
Verify server assigns address to client using undefined client DUID values |
step 1. Release client's current DHCPv6 binding
step 2. Configure the client to use a client DUID with unknown format
step 3. Restart DHCPv6 on client
step 4. Verify the client obtains an address
step 5. Repeat Steps 1 through 4 for different unknown client DUID formats
step 6. Release the DHCPv6 binding
step 7. Verify that the server assigns an address to the client using the
client's original DUID format
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)
https://tools.ietf.org/html/rfc3315#section-9
| Test |
Module |
Name |
Synopsis |
Verify server ignores Solicits sent to unicast address |
dhcpv6-s.tcl |
dhcpv6_server_8 |
Verify server ignores Solicits sent to unicast address |
step 1. Release client's current DHCPv6 binding
step 2. Verify the DHCPv6 server reply contains a status code of 0 'Success'
step 3. Configure LAN client to send DHCPv6 Solicit messages to server's
unicast address
step 4. Restart DHCPv6 on LAN client
step 5. Verify that server does not provide an IPv6 address to the client.
step 6. Restart DHCPv6 on LAN client using All_DHCP_Relay_Agents_and_Servers
multicast address
step 7. Verify that the server assigns an address to the client
Unless otherwise specified in this document, or in a document that
describes how IPv6 is carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP messages to
the All_DHCP_Relay_Agents_and_Servers.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 13: Transmission of Messages by a Client
https://tools.ietf.org/html/rfc3315#section-13
| Test |
Module |
Name |
Synopsis |
Verify server provides DNS and domain information to clients |
dhcpv6-s.tcl |
dhcpv6_server_9 |
Verify server provides DNS and domain information to clients |
step 1. Release client's current DHCPv6 binding
step 2. Restart DHCPv6 on client
step 3. Verify that LAN client receives DHCPv6 DNS Recursive Name Server
(23) option from server
step 4. Verify the DNS server addresses provided by the DHCPv6 server. If
the testvar ipv6DNStoLAN is set to "yes", the DNS server addresses
provided should match the addresses of the DNS servers configured on
the WAN. If the ipv6DNStoLAN testvar is set to "no", the LAN side
IPv6 address of the DUT should be provided as the DNS server.
step 5. Check if LAN client receives DHCPv6 Domain Search List (24) option
from server
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
IETF RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3646
| Test |
Module |
Name |
Synopsis |
Verify server ignores requests with mismatched server DUID |
dhcpv6-s.tcl |
dhcpv6_server_10 |
Verify server ignores requests with mismatched server DUID |
Description
step 1. Modify client to use an unknown server DUID
step 2. Restart DHCPv6 on client by sending Renew to the server
step 3. Verify that server does not reply to Renew with unknown server DUID
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 15.6: Renew Message
https://tools.ietf.org/html/rfc3315#section-15.6
| Test |
Module |
Name |
Synopsis |
Verify server ignores unknown or invalid DHCPv6 packets |
dhcpv6-s.tcl |
dhcpv6_server_11 |
Verify server ignores unknown or invalid DHCPv6 packets |
step 1. Build DHCPv6 packet with msg-type field set to 0
step 2. Send packet built in Step 1 to server
step 3. Verify that server ignores invalid DHCPv6 packet generated in Step 2
step 4. Repeat Steps 1 through 3 using msg-types 1 through 255
step 5. Verify server is still functioning by running test dhcpv6_server_1
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server assigns address when IA_NA request from client does not contain an IPv6 address |
dhcpv6-s.tcl |
dhcpv6_server_12 |
Verify server assigns address when IA_NA request from client does not contain an IPv6 address |
step 1. Release client's current DHCPv6 binding
step 2. Configure client to omit address hint in DHCPv6 Request messages
step 3. Restart DHCPv6 on client
step 4. Verify client obtains an address
step 5. Release client's current DHCPv6 binding
step 6. Configure client to include address hint in DHCPv6 Request message
step 7. Verify client obtains an address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server assigns multiple addresses to client using multiple IA_NA identifiers |
dhcpv6-s.tcl |
dhcpv6_server_13 |
Verify server assigns multiple addresses to client using multiple IA_NA identifiers |
step 1. Configure the client to use a new IA_NA IAID
step 2. Restart DHCPv6 on client without sending a Release to the server
step 3. Verify that the server assigns a new address to the client
step 4. Restore client's original IA_NA IAID
step 5. Restart DHCPv6 on client without sending a Release to the server
step 6. Verify that the server assigns an address to the client
step 7. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server handles fragmented IPv6 packets |
dhcpv6-s.tcl |
dhcpv6_server_14 |
Verify server handles fragmented IPv6 packets |
step 1. Configure client to use a large User Class (15) option to force
IPv6 fragmentation
step 2. Initiate Renew for client's current IPv6 address
step 3. Verify that server responds to Renew with valid Reply message
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2: Server Behavior
https://tools.ietf.org/html/rfc3315#section-18.2
| Test |
Module |
Name |
Synopsis |
Verify server ignores client request with invalid UDP checksum |
dhcpv6-s.tcl |
dhcpv6_server_15 |
Verify server ignores client request with invalid UDP checksum |
step 1. Configure the client to send invalid UDP checksums
step 2. Restart DHCPv6 on client without sending a Release to the server
step 3. Verify that the server does not respond to DHCPv6 requests with bad
UDP checksums
step 4. Configure the client to send valid UDP checksums
step 5. Restart DHCPv6 on the client without sending a Release to the server
step 6. Verify that the server assigns an address to the client
step 7. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server composes DUID correctly |
dhcpv6-s.tcl |
dhcpv6_server_16 |
Verify server composes DUID correctly |
step 1. Initiate a DHCPv6 Renew for the client's current IPv6 address
step 2. Verify that the server sends a Reply
step 3. Inspect the composition of the server DUID in Reply to ensure
correctness
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 9: DHCP Unique Identifier (DUID)
https://tools.ietf.org/html/rfc3315#section-9
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address after DHCPv6 Request from client |
dhcpv6-s.tcl |
dhcpv6_server_20 |
Verify server assigns same IPv6 address after DHCPv6 Request from client |
step 1. Initiate DHCPv6 Request from the client
step 2. Verify that the server assigns the same address to the client
When the server receives a valid Request message, the server creates
the bindings for that client according to the server's policy and
configuration information and records the IAs and other information
requested by the client.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server sends UseMulticast status code when client sends a unicast Request |
dhcpv6-s.tcl |
dhcpv6_server_21 |
Verify server sends UseMulticast status code when client sends a unicast Request |
step 1. Initiate a DHCPv6 Request from the client using the server's unicast
address
step 2. Verify the that the server sends a Reply message with a status code
of 5 'UseMulticast'
When the server receives a Request message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Request message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server sends NotOnLink status code when client sends Request with invalid link address |
dhcpv6-s.tcl |
dhcpv6_server_22 |
Verify server sends NotOnLink status code when client sends Request with invalid link address |
step 1. Initiate a DHCPv6 Request from the client with an unknown
IAID containing an unknown address, which is not
considered "on link"
step 2. Verify that the server sends a Reply message with a status code of
4 'NotOnLink'
If the server finds that the prefix on one or more IP addresses in
any IA in the message from the client is not appropriate for the link
to which the client is connected, the server MUST return the IA to
the client with a Status Code option with the value NotOnLink.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.1
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address after DHCPv6 Confirm from client |
dhcpv6-s.tcl |
dhcpv6_server_30 |
Verify server assigns same IPv6 address after DHCPv6 Confirm from client |
step 1. Initiate a DHCPv6 Confirm from the client
step 2. Verify that the server Reply contains a status code of 0 'success'
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.2: Receipt of Confirm Messages
https://tools.ietf.org/html/rfc3315#section-18.2.2
| Test |
Module |
Name |
Synopsis |
Verify server sends NotOnLink status code when client sends Confirm with invalid link address |
dhcpv6-s.tcl |
dhcpv6_server_31 |
Verify server sends NotOnLink status code when client sends Confirm with invalid link address |
step 1. Initiate a DHCPv6 Confirm from the client with an unknown
IAID containing an unknown address, which is not
considered "on link"
step 2. Verify that the server sends a Reply message with a status code of
4 'NotOnLink'
When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.2: Receipt of Confirm Messages
https://tools.ietf.org/html/rfc3315#section-18.2.2
| Test |
Module |
Name |
Synopsis |
Verify server silently discards client Confirm messages that do not contain any addresses |
dhcpv6-s.tcl |
dhcpv6_server_32 |
Verify server silently discards client Confirm messages that do not contain any addresses |
step 1. Initiate a DHCPv6 Confirm from the client with an unknown IAID
containing no addresses
step 2. Verify that the server does not send a Reply message
When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.2: Receipt of Confirm Messages
https://tools.ietf.org/html/rfc3315#section-18.2.2
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address after DHCPv6 Renew from client |
dhcpv6-s.tcl |
dhcpv6_server_40 |
Verify server assigns same IPv6 address after DHCPv6 Renew from client |
step 1. Initiate DHCPv6 Renew for the client's current IPv6 address
step 2. Verify that the server updates the client's current IPv6 address
binding
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.3: Receipt of Renew Messages
https://tools.ietf.org/html/rfc3315#section-18.2.3
| Test |
Module |
Name |
Synopsis |
Verify server sends UseMulticast status code when client sends unicast Renew |
dhcpv6-s.tcl |
dhcpv6_server_41 |
Verify server sends UseMulticast status code when client sends unicast Renew |
step 1. Initiate DHCPv6 Renew using the server's unicast address
step 2. Verify the that the server sends a Reply message with a status
code of 5 'UseMulticast'
When the server receives a Renew message via unicast from a client to
which the server has not sent a unicast option, the server discards
the Renew message and responds with a Reply message containing a
Status Code option with the value UseMulticast, a Server Identifier
option containing the server's DUID, the Client Identifier option
from the client message, and no other options.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.3: Receipt of Renew Messages
https://tools.ietf.org/html/rfc3315#section-18.2.3
| Test |
Module |
Name |
Synopsis |
Verify server sends NoBinding status code when client attempts to renew unknown IAID |
dhcpv6-s.tcl |
dhcpv6_server_42 |
Verify server sends NoBinding status code when client attempts to renew unknown IAID |
step 1. Initiate DHCPv6 Renew with an unknown IAID that should not have a
binding
step 2. Verify that the server sends a Reply message with a status code of
3 'NoBinding'
If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.3: Receipt of Renew Messages
https://tools.ietf.org/html/rfc3315#section-18.2.3
| Test |
Module |
Name |
Synopsis |
Verify server sends Reply with lifetimes of 0 when client attempts to renew unknown address |
dhcpv6-s.tcl |
dhcpv6_server_43 |
Verify server sends Reply with lifetimes of 0 when client attempts to renew unknown address |
step 1. Initiate a DHCPv6 Renew from client with a valid IAID containing
unknown address
step 2. Verify that the server sends Reply message with correct IAID
step 3. Verify Reply contains correct IA IPv6 address
step 4. Verify Reply contains IA Preferred lifetime of 0
step 5. Verify Reply contains IA Valid lifetime of 0
step 6. Restart DHPCv6 on client
step 7. Verify that the server assigns an address to the client
If the server finds that any of the addresses are not appropriate for
the link to which the client is attached, the server returns the
address to the client with lifetimes of 0.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.3: Receipt of Renew Messages
https://tools.ietf.org/html/rfc3315#section-18.2.3
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address after DHCPv6 Rebind from client |
dhcpv6-s.tcl |
dhcpv6_server_50 |
Verify server assigns same IPv6 address after DHCPv6 Rebind from client |
step 1. Initiate a DHCPv6 Rebind from the client
step 2. Verify that the server updates the client's current IPv6 address
binding
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.4: Receipt of Rebind Messages
https://tools.ietf.org/html/rfc3315#section-18.2.4
| Test |
Module |
Name |
Synopsis |
Verify server sends Reply with lifetimes of 0 when client attempts to rebind with unknown address |
dhcpv6-s.tcl |
dhcpv6_server_52 |
Verify server sends Reply with lifetimes of 0 when client attempts to rebind with unknown address |
step 1. Initiate a DHCPv6 Rebind with a valid IAID containing unknown
address
step 2. Verify that the server sends a Reply message with correct IAID
step 3. Verify Reply contains correct IA IPv6 address
step 4. Verify Reply contains IA Preferred lifetime of 0
step 5. Verify Reply contains IA Valid lifetime of 0
step 6. Restart DHPCv6 on client
step 7. Verify that the server assigns an address to the client
If the server finds that any of the addresses are not appropriate for
the link to which the client is attached, the server returns the
address to the client with lifetimes of 0.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.4: Receipt of Rebind Messages
https://tools.ietf.org/html/rfc3315#section-18.2.4
| Test |
Module |
Name |
Synopsis |
Verify server responds to an Information-request message from client |
dhcpv6-s.tcl |
dhcpv6_server_60 |
Verify server responds to an Information-request message from client |
step 1. Initiate a DHCPv6 Information-request from client
step 2. Verify response from server
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.5: Receipt of Information-request Messages
https://tools.ietf.org/html/rfc3315#section-18.2.5
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address after DHCPv6 Release from client |
dhcpv6-s.tcl |
dhcpv6_server_70 |
Verify server assigns same IPv6 address after DHCPv6 Release from client |
step 1. Initiate a DHCPv6 Release from the client
step 2. Verify that the server sends a Reply message with a status code of
0 'Success'
step 3. Restart DHCPv6 on client
step 4. Verify that the server assigns an address to the client
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.6: Receipt of Release Messages
https://tools.ietf.org/html/rfc3315#section-18.2.6
| Test |
Module |
Name |
Synopsis |
Verify server sends UseMulticast status code when clients sends unicast DHCPv6 Release |
dhcpv6-s.tcl |
dhcpv6_server_71 |
Verify server sends UseMulticast status code when clients sends unicast DHCPv6 Release |
step 1. Initiate a DHCPv6 Release from the client using the server's unicast
address
step 2. Verify the that the server sends a Reply message with a status code
of 5 'UseMulticast'
step 3. Restart DHCPv6 on client
step 4. Verify that the server assigns an address to the client
When the server receives a Release message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Release message and responds with a Reply message
containing a Status Code option with value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.6: Receipt of Release Messages
https://tools.ietf.org/html/rfc3315#section-18.2.6
| Test |
Module |
Name |
Synopsis |
Verify server sends NoBinding status code when client attempts to release unknown IAID |
dhcpv6-s.tcl |
dhcpv6_server_72 |
Verify server sends NoBinding status code when client attempts to release unknown IAID |
step 1. Initiate DHCPv6 Release with an unknown IAID that should not have a
binding
step 2. Verify that the server sends a Reply message with a status code of
3 'NoBinding'
For each IA in the Release message for which the server has no binding information,
the serve adds an IA option using the IAID from the Release message, an includes a
Status Code option with the value NoBinding in the IA option. No other options are
included in the IA option.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.6: Receipt of Release Messages
https://tools.ietf.org/html/rfc3315#section-18.2.6
| Test |
Module |
Name |
Synopsis |
Verify server assigns IPv6 address after DHCPv6 Decline from client |
dhcpv6-s.tcl |
dhcpv6_server_80 |
Verify server assigns IPv6 address after DHCPv6 Decline from client |
step 1. Initiate a DHCPv6 Decline for the client's current IPv6 address
step 2. Verify that the server sends a Reply message with status code of 0
'Success'
step 3. Restart DHCPv6 on client with a sending a Release to the server
step 4. Verify that the server assigns an address to client
step 5. Verify that the address assigned by the server is not the same as
the client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.7: Receipt of Decline Messages
https://tools.ietf.org/html/rfc3315#section-18.2.7
| Test |
Module |
Name |
Synopsis |
Verify server sends UseMulticast status code when client sends unicast DHCPv6 Decline |
dhcpv6-s.tcl |
dhcpv6_server_81 |
Verify server sends UseMulticast status code when client sends unicast DHCPv6 Decline |
step 1. Initiate a DHCPv6 Decline from the client using the server's unicast
address
step 2. Verify the that the server sends a Reply message with a status code
of 5 'UseMulticast'
step 3. Restart DHCPv6 on LAN interface without sending a Release to the
server
step 4. Verify that the server assigns an address to the client
step 5. Verify that the address assigned by the server is the same as the
client's original address
When the server receives a Decline message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Decline message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.7: Receipt of Decline Messages
https://tools.ietf.org/html/rfc3315#section-18.2.7
| Test |
Module |
Name |
Synopsis |
Verify server sends NoBinding status code when client attempts to decline unknown IAID |
dhcpv6-s.tcl |
dhcpv6_server_82 |
Verify server sends NoBinding status code when client attempts to decline unknown IAID |
step 1. Initiate DHCPv6 Decline with an unknown IAID that should not have a
binding
step 2. Verify that the server sends a Reply message with a status code of 3
'NoBinding'
For each IA in the Decline message for which the server has no binding information,
the server adds an IA option using the IAID from the Release message and includes a
Status Code option with the value NoBinding in the IA option. No other options are
included in the IA option.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.7: Receipt of Decline Messages
https://tools.ietf.org/html/rfc3315#section-18.2.7
| Test |
Module |
Name |
Synopsis |
Verify server assigns IPv6 address when client uses unknown DHCPv6 options |
dhcpv6-s.tcl |
dhcpv6_server_100 |
Verify server assigns IPv6 address when client uses unknown DHCPv6 options |
step 1. Configure client to use unknown DHCPv6 option
step 2. Restart DHCPv6 on LAN client without sending a Release to the server
step 3. Verify that the server assigns an address to the client
step 4. Verify that the address assigned by the server is the same as the
client's original address
Note: To ensure compatibility with future client implemenations that may
support yet to be defined DHCPv6 options, servers should ignore any options
that are unknown.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server ignores client requests with invalid option length |
dhcpv6-s.tcl |
dhcpv6_server_101 |
Verify server ignores client requests with invalid option length |
step 1. Configure client to use invalid DHCPv6 option length
step 2. Restart DHCPv6 on LAN client without sending a Release to the server
step 3. Verify that the server does not assign an address to the client
step 4. Configure client to use valid DHCPv6 option length
step 5. Restart DHCPv6 on LAN client without sending a Release to the server
step 6. Verify that the server assigns an address to the client
step 7. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server supports Rapid Commit option |
dhcpv6-s.tcl |
dhcpv6_server_102 |
Verify server supports Rapid Commit option |
step 1. Configure the client to request DHCPv6 option 14 'Rapid Commit'
step 2. Restart DHCPv6 on the client
step 3. Verify that DHCPv6 server responds with Reply message containing the
'Rapid Commit' option
step 4. Verify that the server assigns an address to the client
step 5. Verify that the address assigned by the server is the same as the
client's original address
A client MAY include this option in a Solicit message if the client
is prepared to perform the Solicit-Reply message exchange described
in section 17.1.1.
A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit-Reply message
exchange.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.14: Rapid Commit Option
https://tools.ietf.org/html/rfc3315#section-22.14
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address when client requests both IA_NA and IA_PD |
dhcpv6-s.tcl |
dhcpv6_server_110 |
Verify server assigns same IPv6 address when client requests both IA_NA and IA_PD |
step 1. Configure client to request both IA_NA and IA_PD options
step 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the server
step 3. Verify that the server assigns an address to the client
step 4. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server assigns same IPv6 address when client requests both IA_NA and IA_TA |
dhcpv6-s.tcl |
dhcpv6_server_111 |
Verify server assigns same IPv6 address when client requests both IA_NA and IA_TA |
step 1. Configure client to request both IA_NA and IA_TA options
step 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the server
step 3. Verify that the server assigns an address to the client
step 4. Verify that the address assigned by the server is the same as the
client's original address
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
| Test |
Module |
Name |
Synopsis |
Verify server responds to Relay-Forward requests sent to the All_DHCP_Servers multicast address |
dhcpv6-s.tcl |
dhcpv6_server_120 |
Verify server responds to Relay-Forward requests sent to the All_DHCP_Servers multicast address |
step 1. Configure a relay agent on the LAN to send to DHCPv6 messages to the
All_DHCP_Servers multicast address
step 2. Restart DHCPv6 on the client without sending a Release to the server
step 3. Verify that the server assigns an address to the client
The relay agent MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 20: Relay Agent Behavior
https://tools.ietf.org/html/rfc3315#section-20
| Test |
Module |
Name |
Synopsis |
Verify server responds to Relay-Forward requests sent to server unicast address |
dhcpv6-s.tcl |
dhcpv6_server_121 |
Verify server responds to Relay-Forward requests sent to server unicast address |
step 1. Configure a relay agent on the LAN to send DHCPv6 messages to the
server's global unicast address
step 2. Restart DHCPv6 on the client without sending a Release to the server
step 3. Verify that the server assigns an address to the client
The relay agent MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 20: Relay Agent Behavior
https://tools.ietf.org/html/rfc3315#section-20
| Test |
Module |
Name |
Synopsis |
Verify server includes Interface-Id option in Relay-Reply if included by relay agent |
dhcpv6-s.tcl |
dhcpv6_server_122 |
Verify server includes Interface-Id option in Relay-Reply if included by relay agent |
step 1. Configure a relay agent on the LAN to send DHCPv6 messages to the
server's global unicast address
step 2. Configure a relay agent to include the Interface-Id (18) option in
Relay-Forward messages
step 3. Restart DHCPv6 on the client without sending a Release to the server
step 4. Verify that the server sends a Relay-Reply message to the relay
agent
step 5. Verify that the Relay-Reply message includes the original
Interface-Id (18) option value included by the relay agent
step 6. Wait for DHCPv6 transaction to complete
Reference: IETF RFC 3315 Section 22.18 "Interface-Id Option"
The server MUST copy the Interface-Id option from the Relay-Forward
message into the Relay-Reply message the server sends to the relay
agent in response to the Relay-Forward message. This option MUST NOT
appear in any message except a Relay-Forward or Relay-Reply message.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 22.18: Interface-Id Option
https://tools.ietf.org/html/rfc3315#section-22.18
pppoe-c-v6.tcl
PPPoE client tests with IPv6 on the WAN side of the router
| Test |
Module |
Name |
Synopsis |
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail |
pppoe-c-v6.tcl |
ipv6_pppoe_client_1 |
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail |
step 1. Turn off PPP LCP Echo-Reply on PPPoE server
step 2. PPP client should send an LCP Echo-Request
step 3. PPP client will not receive an LCP Echo-Reply
step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
(wait upto 5 minutes for LCP to failover)
step 5. Verify PPPoE client brings new PPPoE session up
NOTE: Most PPPoE clients will terminate the existing PPPoE session after
several LCP Echo-Requests have failed. However, some routers will
simply initiate a new PPPoE session without sending a PADT. This
test case does not FAIL the test if the existing PPPoE session is not
terminated before starting a new PPPoE session. However, a warning
will be issued.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
NOTE: By default, CDRouter will still respond to ICMP Echo
Requests during this test. This allows the test to verify failure
occurs because of PPP and not the ICMP Echo Replies. However, you
can configure CDRouter to also ignore ICMP Echo Requests during
this test by setting the testvar pppFailUsesICMP to yes:
testvar pppFailUsesICMP yes
| Test |
Module |
Name |
Synopsis |
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link |
pppoe-c-v6.tcl |
ipv6_pppoe_client_10 |
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link |
step 1. Check the current PPPoE session is established
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. Verify PPPoE client brings new PPPoE session up
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE PPP client replies to LCP Echo-Requests |
pppoe-c-v6.tcl |
ipv6_pppoe_client_50 |
PPPoE PPP client replies to LCP Echo-Requests |
step 1. Send 5 LCP Echo-Requests
step 2. Verify LCP Echo-Replies are received
step 3. Verify LCP Echo-Request data is echoed back in response
| Test |
Module |
Name |
Synopsis |
PPPoE PPP client maintains LCP Magic Number during session |
pppoe-c-v6.tcl |
ipv6_pppoe_client_60 |
PPPoE PPP client maintains LCP Magic Number during session |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Check for Magic Number in LCP Configure Request
step 3. Wait for LCP Echo Request and verify Magic Number is the same
step 4. Send LCP Echo Request
step 5. Verify Magic Number in LCP Echo Response is the same
NOTE: CDRouter does not fail this test if the PPPoE PPP client
does not send an LCP Echo Request. Some clients do not
use LCP Echo Requests automtically.
References:
IETF RFC 1548 "The Point-to-Point Protocol (PPP)" Section 5.8: Echo-Request and Echo-Reply
https://tools.ietf.org/html/rfc1548#section-5.8
| Test |
Module |
Name |
Synopsis |
IPv6CP Configure-Requests include Interface Identifier option |
pppoe-c-v6.tcl |
ipv6_pppoe_client_70 |
IPv6CP Configure-Requests include Interface Identifier option |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Check for Interface Identifier in IPv6CP Configure Request
step 3. Verify PPPoE link is reestablished
References:
IETF RFC 5072 "IP Version 6 over PPP" Section 5: Stateless Autoconfiguration and Link-Local Addresses
The interface identifier of IPv6 unicast addresses [5] of a PPP
interface SHOULD be negotiated in the IPV6CP phase of the PPP
connection setup (see Section 4.1).
https://tools.ietf.org/html/rfc5072#section-5
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP restarts if PPP authentication fails |
pppoe-c-v6.tcl |
ipv6_pppoe_client_200 |
PPPoE/PPP restarts if PPP authentication fails |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 3. Verify PPPoE client brings new PPPoE session up
step 4. Reject any PAP or CHAP authentication attempts
step 5. Wait 60 seconds, continuing to reject PPP authentication
step 6. Accept PPP authentication after 60 seconds
step 7. Send pings from LAN side to WAN side to force link to reestablish
step 8. Verify PPP link is reestablished in 300 seconds (pppRestartTimeout)
NOTE: This test supports PAP, CHAP, and MSCHAP authentication.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP can recover if LCP renegotiation is attempted |
pppoe-c-v6.tcl |
ipv6_pppoe_client_210 |
PPPoE/PPP can recover if LCP renegotiation is attempted |
step 1. Send LCP Configure-Request to PPP peer
step 2. Verify peer resends LCP configuration
step 3. Verify the configuration is the same
step 4. If the PPPoE link is terminated, issue ping to reestablish link
step 5. Verify ping succeeds from LAN to WAN
NOTE: Renegotiating LCP can cause some PPP implementations to terminate
the PPP link or the PPPoE link. This test does not fail the DUT if this
happens, but it does issue a warning if the PPPoE session is restarted.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP can recover if LCP Echo-Request contains bad length |
pppoe-c-v6.tcl |
ipv6_pppoe_client_230 |
PPPoE/PPP can recover if LCP Echo-Request contains bad length |
step 1. Send out LCP Echo-Request with length 4096, but no data
step 2. Peer may respond or drop LCP Echo-Request
step 3. Verify PPP is still functioning using ICMP Echo
NOTE: This test checks that the device under test behaves gracefully
when it receives PPP options with a bad length. Some devices may
still respond to the LCP Echo-Request, but it is not considered a failure if
the device does not respond.
| Test |
Module |
Name |
Synopsis |
PPPoE client recovers if PPPoE server drops PADR from PPPoE client |
pppoe-c-v6.tcl |
ipv6_pppoe_client_300 |
PPPoE client recovers if PPPoE server drops PADR from PPPoE client |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 3. Do not respond to the PADR packet from client
step 4. Continue to ignore any PPPoE packets from the client until
the client sends a new PADI packet
step 5. Restore PPPoE server to normal operation
step 6. Verify PPPoE client session recovers
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section 8: Other Considerations
If the Host is waiting to receive a PADS packet, a similar timeout
mechanism SHOULD be used, with the Host re-sending the PADR. After
a specified number of retries, the Host SHOULD then resend a PADI
packet.
https://tools.ietf.org/html/rfc2516#section-8
| Test |
Module |
Name |
Synopsis |
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO |
pppoe-c-v6.tcl |
ipv6_pppoe_client_310 |
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO |
step 1. Configure PPPoE server to use AC-Cookie Tag in PADO responses
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. Send AC-Cookie Tag in PADO
step 5. Verify PADR from client contains AC-Cookie with the same cookie data
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: AC-Cookie
If a Host receives this TAG, it MUST return the TAG
unmodified in the following PADR.
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
PPPoE client maintains Relay-Session-Id during PPPoE session establishment |
pppoe-c-v6.tcl |
ipv6_pppoe_client_320 |
PPPoE client maintains Relay-Session-Id during PPPoE session establishment |
step 1. Configure PPPoE server to use Relay-Session-Id in PADO responses
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. If the PADI already contains a Relay-Session-Id from an actual
PPPoE Relay server, configure the PPPoE server to use the same
tag value
step 5. Send Relay-Session-Id Tag in PADO
step 6. Verify PADR from client contains Relay-Session-Id tag with the same cookie data
NOTE: Normally, CDRouter does not expect a PPPoE relay server to be present
between the PPPoE client and CDRouter. However, this test does check for
an existing Relay-Session-Id in the PADI and will use this tag value
for the test instead of generating a unique value. This allows the test
to work with an existing PPPoE relay server on the WAN.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: Relay-Session-Id
If either the Host or Access Concentrator receives this TAG they
MUST include it unmodified in any discovery packet they send as a response.
https://tools.ietf.org/html/rfc2516
slaac-wan.tcl
Autoconf / SLAAC client tests for the WAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify DUT configures a new address using SLAAC when a new prefix is advertised on the WAN |
slaac-wan.tcl |
ipv6_slaac_wan_1 |
Verify DUT configures a new address using SLAAC when a new prefix is advertised on the WAN |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix
step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
WAN
step 3. Verify that the target address in the Neighbor Solicitation is
based on the new prefix
step 4. Wait 10 seconds for the DUT to configure the new target address
step 5. Send 10 pings to verify that the DUT has configured the new target
address
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify DUT sends DAD-style Neighbor Solicitations when configuring an address |
slaac-wan.tcl |
ipv6_slaac_wan_10 |
Verify DUT sends DAD-style Neighbor Solicitations when configuring an address |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix
step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
WAN
step 3. Verify that the target address in the Neighbor Solicitation is
based on the new prefix
step 4. Verify that the source address of the Neighbor Solicitation is the
unspecified address
step 5. Verify that the destination address of the Neighbor Solicitation is
a solicited-node multicast address based on the target address in
step 3
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify DUT does not configure an address when a DAD collision occurs |
slaac-wan.tcl |
ipv6_slaac_wan_11 |
Verify DUT does not configure an address when a DAD collision occurs |
step 1. Send a Router Advertisement on the WAN that advertises a new prefix
step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
WAN
step 3. Force a DAD collision by sending a Neighbor Advertisement for the
target address used by the DUT in step 2
step 4. Wait 10 seconds
step 5. Verify that the DUT does not configure the target address by
sending a Neighbor Solicitation
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations for new configured address on WAN |
slaac-wan.tcl |
ipv6_slaac_wan_12 |
Verify DUT responds to Neighbor Solicitations for new configured address on WAN |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix
step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
WAN
step 3. Verify that the target address in the Neighbor Solicitation is
based on the new prefix
step 4. Wait 10 seconds
step 5. Run test ipv6_ndp_wan_11 to verify that the DUT has configured
and responds to Neighbor Solicitations for the newly configured
target address
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to DAD-style Neighbor Solicitations for new configured address on WAN |
slaac-wan.tcl |
ipv6_slaac_wan_13 |
Verify DUT responds to DAD-style Neighbor Solicitations for new configured address on WAN |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix
step 2. Verify that the DUT sends a DAD-style Neighbor Solicitation on the
WAN
step 3. Verify that the target address in the Neighbor Solicitation is
based on the new prefix
step 4. Wait 10 seconds
step 5. Run test ipv6_ndp_wan_16 to verify that the DUT has configured
and responds to DAD-style Neighbor Solicitations for the newly
configured target address
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify DUT does not configure an address when the A-bit is not set |
slaac-wan.tcl |
ipv6_slaac_wan_20 |
Verify DUT does not configure an address when the A-bit is not set |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix with the A-bit not set
step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
on the WAN for the prefix advertised in step 1
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement:
a) If the Autonomous flag is not set, silently ignore the Prefix
Information option.
https://tools.ietf.org/html/rfc4862#section-5.5.3
| Test |
Module |
Name |
Synopsis |
Verify DUT does not configure an address when the advertised prefix is a link-local prefix |
slaac-wan.tcl |
ipv6_slaac_wan_21 |
Verify DUT does not configure an address when the advertised prefix is a link-local prefix |
step 1. Send a Router Advertisement on the WAN that advertises a
link-local prefix
step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
on the WAN for the prefix advertised in step 1
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement:
b) If the prefix is the link-local prefix, silently ignore the
Prefix Information option.
https://tools.ietf.org/html/rfc4862#section-5.5.3
| Test |
Module |
Name |
Synopsis |
Verify DUT does not configure an address when the valid lifetime is 0 |
slaac-wan.tcl |
ipv6_slaac_wan_22 |
Verify DUT does not configure an address when the valid lifetime is 0 |
step 1. Send a Router Advertisement on the WAN that advertises a new
global prefix with a valid-lifetime of 0
step 2. Verify that the DUT does not send a DAD-style Neighbor Solicitation
on the WAN for the prefix advertised in step 1
References:
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration" Section 5.5.3: Router Advertisement Processing
For each Prefix-Information option in the Router Advertisement:
c) If the preferred lifetime is greater than the valid lifetime,
silently ignore the Prefix Information option. A node MAY wish to
log a system management error in this case.
https://tools.ietf.org/html/rfc4862#section-5.5.3
6to4.tcl
6to4 tunnel tests for connecting IPv6 hosts over IPv4 networks
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN |
6to4.tcl |
ipv6_6to4_1 |
Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN |
step 1. Listen for IPv6 RA from DUT
step 2. Verify RA contains 6to4 prefix based on public IPv4 WAN
step 3. Verify 6to4 prefix contains a valid lifetime
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify DUT assigns itself a global address on the LAN side 6to4 network |
6to4.tcl |
ipv6_6to4_2 |
Verify DUT assigns itself a global address on the LAN side 6to4 network |
step 1. Determine the DUT's LAN side IPv6 global address
step 2. Send ICMPv6 Echo Request to the DUT's global IPv6 address
step 3. Verify ICMPv6 Echo Response is received from the global IPv6 address
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements include SLA ID |
6to4.tcl |
ipv6_6to4_3 |
Verify IPv6 Router Advertisements include SLA ID |
step 1. Listen for IPv6 RA from DUT
step 2. Verify RA contains 6to4 prefix based on public IPv4 WAN
step 3. Verify advertised 6to4 prefix includes the expected SLA ID
RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most DUT's allow
the SLA ID to be arbitrarily configured. This test verifies that the DUT
advertises the expected SLA ID. The expected SLA can be configured using
the testvar "ipv6LanSubnetId" which must be a hex string with four or less
characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify packets to 6to4 addresses are tunneled directly to IPv4 address |
6to4.tcl |
ipv6_6to4_10 |
Verify packets to 6to4 addresses are tunneled directly to IPv4 address |
step 1. Forward IPv6 UDP to IPv6 address on 6to4 network that maps to
remoteHost IPv4
step 2. Verify remoteHost IPv4 on the WAN received tunneled IPv6 packet
step 3. Verify return IPv6 UDP traffic is forwarded back from remoteHost IPv4
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.1: Simple scenario - all sites work the same
https://tools.ietf.org/html/rfc3056#section-5.1
| Test |
Module |
Name |
Synopsis |
Verify packets to non 6to4 addresses are tunneled to 6to4 relay server |
6to4.tcl |
ipv6_6to4_11 |
Verify packets to non 6to4 addresses are tunneled to 6to4 relay server |
step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 network
step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
step 3. Verify return IPv6 UDP traffic is forwarded back from relay server
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.2: Mixed scenario with relay to native IPv6
https://tools.ietf.org/html/rfc3056#section-5.2
| Test |
Module |
Name |
Synopsis |
Verify IPv4 src address of tunneled 6to4 packets matches WAN IPv4 address |
6to4.tcl |
ipv6_6to4_12 |
Verify IPv4 src address of tunneled 6to4 packets matches WAN IPv4 address |
step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 network
step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
step 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
IPv4 address
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 5.2: Mixed scenario with relay to native IPv6
https://tools.ietf.org/html/rfc3056#section-5.2
| Test |
Module |
Name |
Synopsis |
Verify encapsulating IPv4 header for 6to4 has the DF flag set correctly |
6to4.tcl |
ipv6_6to4_13 |
Verify encapsulating IPv4 header for 6to4 has the DF flag set correctly |
step 1. Forward IPv6 UDP to remoteHostv6 address
step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
step 3. Verify 'do not fragment' flag is set correctly on IPv4
header based on the value of ipv6TunnelMtuType
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit
https://tools.ietf.org/html/rfc3056#section-4
IETF RFC 4213 "Basic Transition Mechanisms for IPv6 Hosts and Routers" Section 3.2: Tunnel MTU and Fragmentation
https://tools.ietf.org/html/rfc4213#section-3.2
| Test |
Module |
Name |
Synopsis |
Verify DUT handles incoming 6to4 fragmented packets |
6to4.tcl |
ipv6_6to4_14 |
Verify DUT handles incoming 6to4 fragmented packets |
step 1. Configure 6to4 Relay server to use an IPv4 MTU of 252
step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP data
step 3. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
step 4. Send same UDP data back through 6to4 relay server
step 5. 6to4 relay server will fragment the IPv4 packet
step 6. Verify UDP data is sent to original IPv6 LAN client
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit
https://tools.ietf.org/html/rfc3056#section-4
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements announce new 6to4 prefix when IPv4 WAN changes |
6to4.tcl |
ipv6_6to4_100 |
Verify IPv6 Router Advertisements announce new 6to4 prefix when IPv4 WAN changes |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IP address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6to4 prefix based on new public WAN IP
step 5. Verify 6to4 prefix contains a valid lifetime
step 6. Bring down WAN link
step 7. Bring up WAN link with new original IP address
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify DUT updates global IPv6 address after IPv4 WAN change |
6to4.tcl |
ipv6_6to4_101 |
Verify DUT updates global IPv6 address after IPv4 WAN change |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IPv4 address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6to4 prefix based on new public WAN IPv4
step 5. Verify 6to4 prefix contains a valid lifetime
step 6. Ping DUT's new IPv6 global address
step 7. Verify IPv6 ping response
step 8. Bring down WAN link
step 9. Bring up WAN link with new original IPv4 address
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change |
6to4.tcl |
ipv6_6to4_102 |
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IPv4 address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6to4 prefix based on new public WAN IPv4
step 5. Verify 6to4 prefix contains a valid lifetime
step 6. Forward IPv6 traffic from LAN to remoteHostv6
step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 address
step 8. Bring down WAN link
step 9. Bring up WAN link with new original IPv4 address
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify IPv6 router advertisements age out 6to4 prefix when IPv4 WAN link is down |
6to4.tcl |
ipv6_6to4_103 |
Verify IPv6 router advertisements age out 6to4 prefix when IPv4 WAN link is down |
step 1. Bring down WAN link
step 2. Listen for IPv6 RA from DUT
step 3. Verify either the RA does not contain previous 6to4 prefix
or the advertised 6to4 prefix preferred lifetime is now 0
step 4. Bring up WAN link
step 5. Listen for IPv6 RA from DUT
step 6. Verify the RA contains the expected 6to4 prefix
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds"
https://tools.ietf.org/html/rfc3056
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address contains a 6to4 prefix based on IPv4 WAN |
6to4.tcl |
ipv6_6to4_150 |
Verify LAN side DHCPv6 client address contains a 6to4 prefix based on IPv4 WAN |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address on the LAN contains
a 6to4 prefix based on public IPv4 WAN
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address contains a 6to4 prefix which includes SLA ID |
6to4.tcl |
ipv6_6to4_160 |
Verify LAN side DHCPv6 client address contains a 6to4 prefix which includes SLA ID |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address on the LAN contains
a 6to4 prefix which includes the expected SLA ID
RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
DUT's allow the SLA ID to be arbitrarily configured. This test
verifies that the DUT uses the expected SLA ID. The expected SLA
can be configured using the testvar "ipv6LanSubnetId" which must
be a hex string with four or less characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
References:
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
6rd.tcl
6rd tunnel tests for connecting IPv6 hosts over IPv4 networks
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN |
6rd.tcl |
ipv6_6rd_1 |
Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN |
step 1. Listen for IPv6 RA from DUT
step 2. Verify RA contains 6rd prefix based on public IPv4 WAN
step 3. Verify 6rd prefix contains a valid lifetime
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify DUT assigns itself a global address on the LAN side 6rd network |
6rd.tcl |
ipv6_6rd_2 |
Verify DUT assigns itself a global address on the LAN side 6rd network |
step 1. Determine the DUT's LAN side IPv6 global address based
step 2. Send ICMPv6 Echo Request to the DUT's global IPv6 address
step 3. Verify ICMPv6 Echo Response is received from the global IPv6 address
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements include subnet ID |
6rd.tcl |
ipv6_6rd_3 |
Verify IPv6 Router Advertisements include subnet ID |
step 1. Listen for IPv6 RA from DUT
step 2. Verify RA contains 6rd prefix based on public IPv4 WAN
step 3. Verify advertised 6rd prefix includes the expected subnet ID
Note: The expected subnet ID bits can be configured using the testvar
ipv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length string
of hex characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify packets to 6rd addresses are tunneled directly to IPv4 address |
6rd.tcl |
ipv6_6rd_10 |
Verify packets to 6rd addresses are tunneled directly to IPv4 address |
step 1. Forward IPv6 UDP to IPv6 address on 6rd network that maps to
new WAN side IPv4 gateway based on testvar wanIspNextIp
step 2. Verify new gateway on the WAN receives tunneled IPv6 packet
step 3. Verify return IPv6 UDP traffic is forwarded back from new IPv4 gateway
IPv6 communication between customer sites of a same ISP is direct
across the ISP IPv4 infrastructure: when a CPE sees that the IPv6
destination address of an outgoing packet starts with its own 6rd
relay ISPv6 prefix, it takes the 32 bits that follow this prefix as
IPv4 destination of the encapsulating packet.
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify packets to non 6rd addresses are tunneled to 6rd relay server |
6rd.tcl |
ipv6_6rd_11 |
Verify packets to non 6rd addresses are tunneled to 6rd relay server |
step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd network
step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
step 3. Verify return IPv6 UDP traffic is forwarded back from relay server
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify IPv4 src address of tunneled 6rd packets matches WAN IPv4 address |
6rd.tcl |
ipv6_6rd_12 |
Verify IPv4 src address of tunneled 6rd packets matches WAN IPv4 address |
step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd network
step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
step 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
IPv4 address
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify encapsulating IPv4 header for 6rd has the DF flag set correctly |
6rd.tcl |
ipv6_6rd_13 |
Verify encapsulating IPv4 header for 6rd has the DF flag set correctly |
step 1. Forward IPv6 UDP to remoteHostv6 address
step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
step 3. Verify 'do not fragment' flag is set correctly on IPv4
header based on the value of ipv6TunnelMtuType
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 4: Maximum Transmission Unit
https://tools.ietf.org/html/rfc3056#section-4
IETF RFC 4213 "Basic Transition Mechanisms for IPv6 Hosts and Routers" Section 3.2: Tunnel MTU and Fragmentation
https://tools.ietf.org/html/rfc4213#section-3.2
| Test |
Module |
Name |
Synopsis |
Verify DUT handles incoming 6rd fragmented packets |
6rd.tcl |
ipv6_6rd_14 |
Verify DUT handles incoming 6rd fragmented packets |
step 1. Configure 6rd Relay server to use an IPv4 MTU of 252
step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP data
step 3. Verify 6rd relay server on the WAN received tunneled IPv6 packet
step 4. Send same UDP data back through 6rd relay server
step 5. 6rd relay server will fragment the IPv4 packet
step 6. Verify UDP data is sent to original IPv6 LAN client
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Router Advertisements announce new 6rd prefix when IPv4 WAN changes |
6rd.tcl |
ipv6_6rd_100 |
Verify IPv6 Router Advertisements announce new 6rd prefix when IPv4 WAN changes |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IP address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6rd prefix based on new public WAN IP
step 5. Verify 6rd prefix contains a valid lifetime
step 6. Bring down WAN link
step 7. Bring up WAN link with new original IP address
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify DUT updates global IPv6 address after IPv4 WAN change |
6rd.tcl |
ipv6_6rd_101 |
Verify DUT updates global IPv6 address after IPv4 WAN change |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IPv4 address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6rd prefix based on new public WAN IPv4
step 5. Verify 6rd prefix contains a valid lifetime
step 6. Ping DUT's new IPv6 global address
step 7. Verify IPv6 ping response
step 8. Bring down WAN link
step 9. Bring up WAN link with new original IPv4 address
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change |
6rd.tcl |
ipv6_6rd_102 |
Verify DUT forwards tunneled IPv6 traffic after IPv4 WAN change |
step 1. Bring down WAN link
step 2. Bring up WAN link with new external IPv4 address
step 3. Listen for IPv6 RA from DUT
step 4. Verify RA contains 6rd prefix based on new public WAN IPv4
step 5. Verify 6rd prefix contains a valid lifetime
step 6. Forward IPv6 traffic from LAN to remoteHostv6
step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 address
step 8. Bring down WAN link
step 9. Bring up WAN link with new original IPv4 address
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify IPv6 router advertisements age out 6rd prefix when IPv4 WAN link is down |
6rd.tcl |
ipv6_6rd_103 |
Verify IPv6 router advertisements age out 6rd prefix when IPv4 WAN link is down |
step 1. Bring down WAN link
step 2. Listen for IPv6 RA from DUT
step 3. Verify either the RA does not contain previous 6rd prefix
or the advertised 6rd prefix preferred lifetime is now 0
step 4. Bring up WAN link
step 5. Listen for IPv6 RA from DUT
step 6. Verify the RA contains the expected 6rd prefix
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address contains a 6rd prefix based on IPv4 WAN |
6rd.tcl |
ipv6_6rd_150 |
Verify LAN side DHCPv6 client address contains a 6rd prefix based on IPv4 WAN |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address on the LAN contains
a 6rd prefix based on public IPv4 WAN
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
| Test |
Module |
Name |
Synopsis |
Verify LAN side DHCPv6 client address contains a 6rd prefix which includes SLA ID |
6rd.tcl |
ipv6_6rd_160 |
Verify LAN side DHCPv6 client address contains a 6rd prefix which includes SLA ID |
step 1. Check existing DHCPv6 bindings on the LAN side of the CPE
step 2. Verify whether or not a non-temporary address binding exists
step 3. Verify that the non-temporary address on the LAN contains
a 6rd prefix which includes the expected SLA ID
RFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most
DUT's allow the SLA ID to be arbitrarily configured. This test
verifies that the DUT uses the expected SLA ID. The expected SLA
can be configured using the testvar "ipv6LanSubnetId" which must
be a hex string with four or less characters. Examples:
testvar ipv6LanSubnetId ffff
testvar ipv6LanSubnetId 1
References:
IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"
https://tools.ietf.org/html/rfc5969
IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation
https://tools.ietf.org/html/rfc3056#section-2
icmp-v6.tcl
ICMPv6 tests for baseline ICMPv6 not including Neighbor Discovery
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Echo Requests work through DUT |
icmp-v6.tcl |
icmpv6_1 |
Verify ICMPv6 Echo Requests work through DUT |
step 1. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Echo Requests from multiple LAN clients work through DUT |
icmp-v6.tcl |
icmpv6_2 |
Verify ICMPv6 Echo Requests from multiple LAN clients work through DUT |
step 1. Configure additional lan host
step 2. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 1
step 3. Verify ICMPv6 Echo Reply is received
step 4. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 2
step 5. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to its global IPv6 address from LAN |
icmp-v6.tcl |
icmpv6_3 |
Verify DUT responds to ICMPv6 Echo Requests to its global IPv6 address from LAN |
step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's global IPv6 address
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to its link-local address |
icmp-v6.tcl |
icmpv6_4 |
Verify DUT responds to ICMPv6 Echo Requests to its link-local address |
step 1. Initiate an outbound ICMPv6 Echo Request to the router's LAN side link-local address
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Echo Requests to DUT's global IPv6 address behave as expected |
icmp-v6.tcl |
icmpv6_5 |
Verify ICMPv6 Echo Requests to DUT’s global IPv6 address behave as expected |
step 1. Determine expected DUT global address
step 2. Initiate an outbound ICMPv6 Echo Request to the DUT's global address from the LAN
step 3. Verify response is received
step 4. Initiate an inbound ICMPv6 Echo Request to the DUT's global address from the WAN
step 5. Verify the device behaves as expected.
NOTE: the testvar ipv6WanPingRespond is used to determine if pinging the
WAN-side of the DUT is expected to work or not. It defaults to "no"
which signifies that the device will not respond to IPv6 pings on its
WAN interface.
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Routers multicast group |
icmp-v6.tcl |
icmpv6_6 |
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Routers multicast group |
step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the link-local IPv6 address
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a global prefix |
icmp-v6.tcl |
icmpv6_7 |
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a global prefix |
step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the global-prefix
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Nodes group from a link-local address |
icmp-v6.tcl |
icmpv6_8 |
Verify DUT responds to ICMPv6 Echo Requests sent to the All-Nodes group from a link-local address |
step 1. Send an ICMPv6 Echo Request from the LAN to the All-Nodes Multicast group (ff02::1)
step 2. Wait for an ICMPv6 Echo Response
step 3. Verify the Echo Response is from the DUT
step 4. Continue waiting until the DUT responds, or timeout
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to the All-Nodes group from a global IPv6 address |
icmp-v6.tcl |
icmpv6_9 |
Verify DUT responds to ICMPv6 Echo Requests to the All-Nodes group from a global IPv6 address |
step 1. Send an ICMPv6 Echo Request from the LAN to the All-Nodes Multicast group (ff02::1)
step 2. Wait for an ICMPv6 Echo Response
step 3. Verify the Echo Response is from the DUT
step 4. Continue waiting until the DUT responds, or timeout
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on LAN |
icmp-v6.tcl |
icmpv6_10 |
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on LAN |
step 1. Set the IPv6 Hop Limit of outbound packets on the LAN to 0
step 2. Forward an IPv6 packet from a LAN client to the IPv6 WAN remote host
step 3. Verify that the DUT does not forward the IPv6 packet to the IPv6 WAN
remote host
step 4. Verify that the DUT sends an ICMPv6 Time Exceeded packet to the LAN
client
step 5. Verify the ICMPv6 Time Exceeded packet contains the IPv6 header of
the original packet
step 6. Repeat steps 1 through 4 using an IPv6 Hop Limit of 1
Note: This test is similar to icmpv6_32. The primary difference is that
icmpv6_32 verifies that the DUT sends an ICMPv6 Time Exceeded when it
receives a packet with a Hop Limit of 0 or 1 on the WAN side while this test
verifies that the DUT sends an ICMPv6 Time Exceeded when it receives a
packet with a Hop Limit of 0 or 1 on the LAN side.
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.3: Time Exceeded Message
If a router receives a packet with a Hop Limit of zero, or if a
router decrements a packet's Hop Limit to zero, it MUST discard the
packet and originate an ICMPv6 Time Exceeded message with Code 0 to
the source of the packet. This indicates either a routing loop or
too small an initial Hop Limit value.
https://tools.ietf.org/html/rfc4443#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards inbound ICMPv6 Time Exceeded |
icmp-v6.tcl |
icmpv6_11 |
Verify DUT forwards inbound ICMPv6 Time Exceeded |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMPv6 Time Exceeded packet with original UDP packet as data
step 4. Verify ICMPv6 Time Exceeded packet is received by LAN host
step 5. Verify the contents of the original IP packet included
in the ICMPv6 Time Exceeded packet
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards inbound ICMPv6 Destination Unreachable |
icmp-v6.tcl |
icmpv6_12 |
Verify DUT forwards inbound ICMPv6 Destination Unreachable |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMPv6 Destination Unreachable packet with original UDP packet as data
step 4. Verify ICMPv6 Destination Unreachable is received by LAN host
step 5. Verify the contents of the original IPv6 packet included
in the ICMPv6 Destination Unreachable packet
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards inbound ICMPv6 Packet Too Big messages |
icmp-v6.tcl |
icmpv6_13 |
Verify DUT forwards inbound ICMPv6 Packet Too Big messages |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMPv6 Packet Too Big packet with MTU size 1280
step 4. Verify ICMPv6 Packet Too Big is received by LAN host
step 5. Verify the received MTU in Packet Too Big message is unchanged
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards inbound ICMPv6 Parameter Problem |
icmp-v6.tcl |
icmpv6_14 |
Verify DUT forwards inbound ICMPv6 Parameter Problem |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMPv6 Parameter Problem packet with pointer value of 40
step 4. Verify ICMPv6 Parameter Problem is received by LAN host
step 5. Verify the pointer value is unchanged
step 6. Verify the contents of the include IPv6 packet in the ICMPv6 packet
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
https://tools.ietf.org/html/rfc4443
| Test |
Module |
Name |
Synopsis |
Verify DUT supports Path MTU Discovery over WAN interface |
icmp-v6.tcl |
icmpv6_20 |
Verify DUT supports Path MTU Discovery over WAN interface |
step 1. Send 1500 byte UDP packet
step 2. Check for an ICMPv6 Packet Too Big packet with code = 0
step 3. Repeat process 2 more times until an ICMPv6 Packet Too Big
is received, or all 3 packets are sent
step 4. If an ICMPv6 Packet Too Big packet was sent, verify that
the code value is 0 and verify the MTU value in the ICMP header
step 5. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMPv6 Packet Too Big packet is sent
step 6. When a packet size is found that does not generate an
ICMPv6 Packet Too Big message,verify packets can be
forwarded using this packet size
step 7. Verify the final MTU size is the same as the MTU size
reported in the ICMPv6 Packet Too Big packet
NOTE: This test starts with an initial MTU of 1500. If the WAN interface
already supports this MTU (DHCP), then this test will pass without
exercising the real part of Path MTU Discovery.
NOTE: Some devices rate limit the number of ICMP packets that may be
sent. This test will send 3 UDP packets over a 15 second window
in order to generate an ICMP Packet Too Big packet. If the
router under test uses rate limiting on ICMP packets, it must allow
at least one ICMP packet every 10 seconds.
References:
IETF RFC 1981 "Path MTU Discovery for IP version 6"
https://tools.ietf.org/html/rfc1981
| Test |
Module |
Name |
Synopsis |
Verify Path MTU value is consistent with Router Advertisement MTU value |
icmp-v6.tcl |
icmpv6_30 |
Verify Path MTU value is consistent with Router Advertisement MTU value |
step 1. Send a Router Solicitation from LAN side
step 2. Verify a Router Advertisement with an MTU option is
received on LAN side
step 3. Send 1500 byte UDP packet
step 4. Check for an ICMPv6 Packet Too Big packet
step 5. Repeat process 2 more times until an ICMPv6 Packet Too Big
is received, or all 3 packets are sent
step 6. If an ICMPv6 Packet Too Big packet was sent, verify that
the MTU value is less than or equal to the MTU option
contained in the Router Advertisement.
step 7. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMPv6 Packet Too Big packet is sent
step 8. Verify the final MTU size is less than or equal to the MTU
option contained in the Router Advertisement.
NOTE: This test starts with an initial MTU of 1500. If the WAN interface
already supports this MTU (DHCP), then this test will pass without
exercising the real part of Path MTU Discovery.
NOTE: Some devices rate limit the number of ICMP packets that may be
sent. This test will send 3 UDP packets over a 15 second window
in order to generate an ICMP Packet Too Big packet. If the
router under test uses rate limiting on ICMP packets, it must allow
at least one ICMP packet every 10 seconds.
References:
IETF RFC 1981 "Path MTU Discovery for IP version 6"
https://tools.ietf.org/html/rfc1981
| Test |
Module |
Name |
Synopsis |
Verify Packet Too Big messages as IPv6 WAN MTU changes |
icmp-v6.tcl |
icmpv6_31 |
Verify Packet Too Big messages as IPv6 WAN MTU changes |
step 1. Send an ICMPv6 Router Advertisement on the WAN containing the
current WAN IPv6 MTU.
step 2. Send a UDP packet equal to the current WAN IPv6 MTU from a LAN
client to a WAN server.
step 3. Verify an ICMPv6 Packet Too Big message is not sent.
step 4. Repeat steps 2-3 two more times.
step 5. Send a UDP packet greater than the current WAN IPv6 MTU from a LAN
client to a WAN server; if the LAN MTU is too small to permit this
packet to be sent, a warning will be generated.
step 6. Verify an ICMPv6 Packet Too Big message is sent and includes the
current WAN IPv6 MTU.
step 7. Repeat steps 5-6 two more times.
step 8. Repeat steps 1-7, decrementing the current WAN IPv6 MTU by 20 on
each iteration until the WAN IPv6 MTU falls below the minimum IPv6
link MTU of 1280.
NOTE: Some devices rate limit the number of ICMP packets that may be
sent. This test will send 3 UDP packets over a 15 second window
in order to generate an ICMP Packet Too Big packet. If the
router under test uses rate limiting on ICMP packets, it must allow
at least one ICMP packet every 10 seconds.
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.2: Packet Too Big Message
https://tools.ietf.org/html/rfc4443#section-3.2
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 6.3.4: Processing Received Router Advertisements
https://tools.ietf.org/html/rfc4861#section-6.3.4
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on WAN |
icmp-v6.tcl |
icmpv6_32 |
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 0 or 1 on WAN |
step 1. Set the IPv6 Hop Limit on the IPv6 WAN remote host to 0
step 2. Forward an IPv6 packet from a LAN client to the IPv6 WAN remote host
step 3. Send response from the IPv6 WAN remote host to the LAN client with
an IPv6 Hop Limit of 0
step 4. Verify that the DUT sends an ICMPv6 Time Exceeded packet to the IPv6
WAN remote host
step 5. Verify the ICMPv6 Time Exceeded packet contains the IPv6 header of
the original packet
step 6. Repeat steps 1 through 5 using an IPv6 Hop Limit of 1
Note: This test is similar to icmpv6_10. The primary difference is that
icmpv6_10 verifies that the DUT sends an ICMPv6 Time Exceeded when it
receives a packet with a Hop Limit of 0 or 1 on the LAN side while this test
verifies that the DUT sends an ICMPv6 Time Exceeded when it receives a
packet with a Hop Limit of 0 or 1 on the WAN side.
References:
IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Section 3.3: Time Exceeded Message
If a router receives a packet with a Hop Limit of zero, or if a
router decrements a packet's Hop Limit to zero, it MUST discard the
packet and originate an ICMPv6 Time Exceeded message with Code 0 to
the source of the packet. This indicates either a routing loop or
too small an initial Hop Limit value.
https://tools.ietf.org/html/rfc4443#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the LAN |
icmp-v6.tcl |
icmpv6_33 |
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the LAN |
step 1. Determine expected DUT global address
step 2. Initiate an inbound ICMPv6 Echo Request to the DUT's global address
from the LAN with Hop Limit of 0
step 3. Verify the device responds to the ICMPv6 Echo Request
References:
IETF RFC 8200 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format
When forwarding, the packet is discarded if Hop Limit was zero
when received or is decremented to zero. A node that is the
destination of a packet should not discard a packet with Hop Limit
equal to zero; it should process the packet normally.
https://tools.ietf.org/html/rfc8200#section-3
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the WAN |
icmp-v6.tcl |
icmpv6_34 |
Verify DUT responds to ICMPv6 Echo Request with Hop Limit of 0 on the WAN |
step 1. Determine expected DUT global address
step 2. Initiate an inbound ICMPv6 Echo Request to the DUT's global address
from the WAN with Hop Limit of 0
step 3. Verify the device behaves as expected
Note: the testvar ipv6WanPingRespond is used to determine if pinging the WAN
side of the DUT is expected to work or not. It defaults to "no" which
signifies that the device will not respond to IPv6 pings on its WAN
interface.
References:
IETF RFC 8200 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format
When forwarding, the packet is discarded if Hop Limit was zero
when received or is decremented to zero. A node that is the
destination of a packet should not discard a packet with Hop Limit
equal to zero; it should process the packet normally.
https://tools.ietf.org/html/rfc8200#section-3
firewall-v6.tcl
IPv6 Firewall tests including port scans
| Test |
Module |
Name |
Synopsis |
Inbound TCP connections to public side HTTP port are blocked |
firewall-v6.tcl |
ipv6_firewall_1 |
Inbound TCP connections to public side HTTP port are blocked |
step 1. Initiate a WAN TCP connection to the DUT's global IPv6 address management port
step 2. Verify the connection is not established
NOTE: The value of the DUT's IPv6 address management port is taken
from the default insecure management port defined as the
first port in the value of testvar dutMgmtPort. Please read
the documentation for dutMgmtPort for more information about
the default insecure management port concept and its usage.
| Test |
Module |
Name |
Synopsis |
Inbound TCP connections to LAN hosts are blocked |
firewall-v6.tcl |
ipv6_firewall_2 |
Inbound TCP connections to LAN hosts are blocked |
step 1. Initiate a WAN TCP connection to a LAN client address
step 2. Verify the connection is not established
| Test |
Module |
Name |
Synopsis |
TCP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets |
firewall-v6.tcl |
ipv6_firewall_100 |
TCP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets |
step 1. Send TCP SYN packets from WAN to each port of the LAN Client in the port scan range
step 2. Verify that each packet is not forwarded to the LAN IPv6 Client,
unless the port is configured as open.
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'ipv6FirewallTcpClosedPorts' and 'ipv6FirewallTcpOpenPorts' testvars:
testvar ipv6FirewallTcpClosedPorts "2323"
testvar ipv6FirewallTcpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
UDP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets |
firewall-v6.tcl |
ipv6_firewall_101 |
UDP port scan the LAN Client from WAN to verify the DUT does not forward unsolicited packets |
step 1. Send UDP packets from WAN to each port of the LAN Client in the port scan range
step 2. Verify that each packet is not forwarded to the LAN IPv6 Client,
unless the port is configured as open.
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'ipv6FirewallTcpClosedPorts' and 'ipv6FirewallTcpOpenPorts' testvars:
testvar ipv6FirewallUdpClosedPorts "2323"
testvar ipv6FirewallUdpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
TCP fragmentation port scan test to verify the DUT does not forward unsolicited packets |
firewall-v6.tcl |
ipv6_firewall_110 |
TCP fragmentation port scan test to verify the DUT does not forward unsolicited packets |
step 1. Set the IPv6 fragmentation size to 56 bytes
step 2. Send TCP SYN packets from WAN to each port in the port scan range
of the LAN Client
step 3. Verify packets are not forwarded to LAN Client
step 4. Verify the router does not accept the TCP connection or
send a RST for the TCP connection unless the port has
been configured as an open or closed port
step 5. Do not flag ports that have port forwarding configured
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'firewallTcpClosedPorts' and 'firewallTclOpenPorts' testvars:
testvar ipv6FirewallTcpClosedPorts "2323"
testvar ipv6FirewallTcpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN |
firewall-v6.tcl |
ipv6_firewall_301 |
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN |
step 1. Send a TCP SYN from LAN host to IP address on WAN
step 2. Send a TCP SYN from the WAN host to the original LAN host
using the same TCP source port
step 3. If the router blocks simultaneous TCP SYNs
(testvar 'natSimultaneousTcp' is set to no), verify the TCP
SYN from the WAN is dropped
OR
If the router supports simultaneous TCP SYNs
(testvar 'natSimultaneousTcp' is set to yes), verify the TCP
SYN from the WAN is forwarded to the LAN
step 4. Repeat step 1 using new TCP port numbers
step 5. Send a TCP SYN from the WAN host to the original LAN host
using a new TCP source port
step 6. Verify the TCP SYN from the WAN is dropped
NOTE: This test verifies that the firewall only allows TCP packets
for established TCP sessions. If simultaneous TCP open is supported through
the firewall, this test will verify that TCP SYN packets from the WAN are
forwarded to the LAN. If simultaneous TCP open through the firewall is
not supported, the test will verify that no TCP SYN packets are allowed
from the WAN to the LAN for sessions that have been initiated from the LAN.
NOTE: The testvar natSimultaneousTcp originates from IPv4 concepts. However,
this testvar is used to indicate if this same behavior exists for IPv6.
| Test |
Module |
Name |
Synopsis |
Verify outbound packets with forbidden source addresses are not forwarded onto the WAN |
firewall-v6.tcl |
ipv6_firewall_505 |
Verify outbound packets with forbidden source addresses are not forwarded onto the WAN |
step 1. Configure a variety of invalid source addresses for traffic
step 2. Send traffic with these addresses to the WAN
step 3. Verify packets are not forwarded
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-1: Packets bearing multicast source addresses in their outer IPv6
headers MUST NOT be forwarded or transmitted on any interface.
REC-2: Packets bearing multicast destination addresses in their outer
IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
Architecture" [RFC4007]) than the configured scope boundary level of
the gateway MUST NOT be forwarded in any direction. The DEFAULT
scope boundary level SHOULD be organization-local scope, and it
SHOULD be configurable by the network administrator.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound packets with forbidden source addresses are not forwarded onto the LAN |
firewall-v6.tcl |
ipv6_firewall_506 |
Verify inbound packets with forbidden source addresses are not forwarded onto the LAN |
Step 1. Create a new vnode on the RemoteHostv6
Step 2. Send UDP traffic to the LAN with forbidden sources from vnode
Step 3. Verify traffic is not forwarded onto the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-1: Packets bearing multicast source addresses in their outer IPv6
headers MUST NOT be forwarded or transmitted on any interface.
REC-2: Packets bearing multicast destination addresses in their outer
IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
Architecture" [RFC4007]) than the configured scope boundary level of
the gateway MUST NOT be forwarded in any direction. The DEFAULT
scope boundary level SHOULD be organization-local scope, and it
SHOULD be configurable by the network administrator.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network |
firewall-v6.tcl |
ipv6_firewall_508 |
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network |
step 1. Create a new LAN client
step 2. Assign a different global prefix to the LAN
step 3. Send traffic to the WAN from the martian source address
step 4. Verify traffic is not forwarded
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-5: Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix configured
for use by globally reachable nodes on the interior network.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound packets are not forwarded if the source address is assigned for use on the interior network |
firewall-v6.tcl |
ipv6_firewall_509 |
Verify inbound packets are not forwarded if the source address is assigned for use on the interior network |
step 1. Create a new stack on the remoteHost
step 2. Assign the stack the same global prefix as is used on the LAN
step 3. Send traffic to the LAN from the remote stack
step 4. Verify traffic is NOT forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-6: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use
by globally reachable nodes on the interior network.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound packets with link local source addresses are not forwarded to the WAN |
firewall-v6.tcl |
ipv6_firewall_510 |
Verify outbound packets with link local source addresses are not forwarded to the WAN |
step 1. Send traffic from the LAN to the WAN with a link-local source address
step 2. Verify traffic is not forwarded to the WAN
| Test |
Module |
Name |
Synopsis |
Verify inbound packets with link local source addresses are not forwarded to the LAN |
firewall-v6.tcl |
ipv6_firewall_511 |
Verify inbound packets with link local source addresses are not forwarded to the LAN |
step 1. Initiate a new UDP session with the device to allow inbound traffic
step 2. Configure a new stack on the WAN with a link-local prefix as the source
step 3. Send traffic from this new stack to the LAN
step 4. Verify traffic is not forwarded to the LAN
| Test |
Module |
Name |
Synopsis |
Verify inbound IPv6 DNS queries on the WAN are not processed by DNS proxy |
firewall-v6.tcl |
ipv6_firewall_512 |
Verify inbound IPv6 DNS queries on the WAN are not processed by DNS proxy |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT's
global IPv6 address
step 2. Verify that the query is received by either the primary or backup
DNS server on the WAN
step 3. Verify that the DNS response is received by the LAN client
step 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to the
DUT's global IPv6 address
step 5. Verify that a DNS response is not received by the remote host on the
WAN that initiated the original request
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-8: By DEFAULT, inbound DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS resolving
server.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound DHCPv6 discovery packets on the WAN are not processed by DHCPv6 server |
firewall-v6.tcl |
ipv6_firewall_513 |
Verify inbound DHCPv6 discovery packets on the WAN are not processed by DHCPv6 server |
step 1. Start new DHCPv6 client on WAN interface
step 2. Verify new client does not obtain an IPv6 address via DHCPv6 from
the DUT
step 3. Send three pings from LAN to WAN to verify that the DUT is still
operating properly
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
exterior interfaces MUST NOT be processed by any integrated DHCPv6
server or relay agent.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Destination Unreachable message from WAN does not destroy UDP firewall state |
firewall-v6.tcl |
ipv6_firewall_540 |
Verify ICMPv6 Destination Unreachable message from WAN does not destroy UDP firewall state |
step 1. Send IPv6 UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
UDP headers that match the flow state record.
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Destination Unreachable message from WAN does not destroy TCP firewall state |
firewall-v6.tcl |
ipv6_firewall_541 |
Verify ICMPv6 Destination Unreachable message from WAN does not destroy TCP firewall state |
step 1. Establish TCP connection from LAN to WAN
step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
step 4. Send TCP data segment from WAN to LAN for the session
step 5. Verify TCP data segment is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
TCP headers that match the flow state record.
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Packet Too Big message from WAN does not destroy UDP firewall state |
firewall-v6.tcl |
ipv6_firewall_542 |
Verify ICMPv6 Packet Too Big message from WAN does not destroy UDP firewall state |
step 1. Send IPv6 UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
step 3. Verify ICMPv6 Too Big message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
UDP headers that match the flow state record.
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Verify ICMPv6 Packet Too Big message from WAN does not destroy TCP firewall state |
firewall-v6.tcl |
ipv6_firewall_543 |
Verify ICMPv6 Packet Too Big message from WAN does not destroy TCP firewall state |
step 1. Establish TCP connection from LAN to WAN
step 2. Send an ICMPv6 Packet Too Big message from the WAN for the connection
step 3. Verify ICMPv6 Packet Too Big message is received on the LAN
step 4. Send TCP data segment from WAN to LAN for the session
step 5. Verify TCP data segment is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
TCP headers that match the flow state record.
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow.
https://tools.ietf.org/html/rfc6092#section-3.3.1
firewall-out-v6.tcl
IPv6 Firewall tests for limiting outbound access to services
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked |
firewall-out-v6.tcl |
ipv6_firewall_outbound_1 |
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific
TCP ports
step 2. Send a TCP SYN packet from the LAN to each blocked port
step 3. Verify the DUT does not forward TCP packets to any of the blocked
ports
The ipv6FirewallOutBlockedTcpPorts testvar is used to determine the list of
TCP ports that the DUT has been configured to block access to.
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked |
firewall-out-v6.tcl |
ipv6_firewall_outbound_2 |
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific
UDP ports
step 2. Send a UDP packet from the LAN to each blocked port
step 3. Verify the DUT does not forward UDP packets to any of the blocked
ports
The ipv6FirewallOutBlockedUdpPorts testvar is used to determine the list of
UDP ports that the DUT has been configured to block access to.
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked |
firewall-out-v6.tcl |
ipv6_firewall_outbound_3 |
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific
IP Protocol types
step 2. Send an IP packet from the LAN to the WAN for each blocked IP
protocol
step 3. Verify the DUT does not forward any of the blocked IP protocols
The ipv6FirewallOutBlockedIpProtos testvar is used to determine the list of
IP Protocol types that the DUT has been configured to block access to.
apps-v6.tcl
Application tests for IPv6
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP session through the router |
apps-v6.tcl |
ipv6_app_100 |
Verify IPv6 HTTP session through the router |
step 1. Initiate an outbound TCP connection to HTTP server over IPv6
step 2. Verify the TCP connection is established
step 3. Verify the IPv6 source address on the WAN side is the LAN client's address
step 4. Send HTTP GET request to server
step 5. Verify HTTP response is received
step 6. Close TCP connection from LAN side
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS session through the router |
apps-v6.tcl |
ipv6_app_110 |
Verify IPv6 HTTPS session through the router |
step 1. Initiate an outbound TCP connection to HTTPS server over IPv6
step 2. Verify the TCP connection is established
step 3. Verify the IPv6 source address on the WAN side is the LAN client's address
step 4. Verify the TLS session is established
step 5. Send HTTPS GET request to server
step 6. Verify HTTPS response is received
step 7. Close TCP connection from LAN side
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS query through the router |
apps-v6.tcl |
ipv6_app_112 |
Verify IPv6 DNS query through the router |
step 1. Enable a DNS server on the IPv6 remoteHost
step 2. Initiate an AAAA IPv6 DNS query to the IPv6 remoteHost
step 3. Verify the query is received by the correct DNS server
(depends on the value of dnsCaptive) on the WAN side
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
NOTE: If the testvar dnsCaptive is set to yes, the test will expect
DNS queries to be sent to the original WAN side DNS servers and
not the 3rd party DNS server.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify IPv6 FTP session through the router |
apps-v6.tcl |
ipv6_app_114 |
Verify IPv6 FTP session through the router |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP EPRT command using all upper case letters
step 4. Verify router translates EPRT command using router's address
step 5. Initiate inbound TCP connection for FTP data connection
step 6. Verify inbound TCP connection is established
step 7. Close both connections
References:
IETF RFC 2428 "FTP Extensions for IPv6 and NATs"
https://tools.ietf.org/html/rfc2428
| Test |
Module |
Name |
Synopsis |
Verify IPv6 SMTP session through the router |
apps-v6.tcl |
ipv6_app_120 |
Verify IPv6 SMTP session through the router |
step 1. Initiate an outbound TCP connection to SMTP server
step 2. Send email message using SMTP server
step 3. Verify SMTP server correctly receives email message
step 4. Close SMTP session from LAN side
References:
IETF RFC 821 "SIMPLE MAIL TRANSFER PROTOCOL"
https://tools.ietf.org/html/rfc821
| Test |
Module |
Name |
Synopsis |
Verify IPv6 POP3 session through the router |
apps-v6.tcl |
ipv6_app_122 |
Verify IPv6 POP3 session through the router |
step 1. Initiate an outbound TCP connection to POP3 server
step 2. Retreive email messages using POP3 protocol
step 3. Verify POP3 server correctly returns email messages
step 4. Close POP3 session from LAN side
References:
IETF RFC 1939 "Post Office Protocol - Version 3"
https://tools.ietf.org/html/rfc1939
| Test |
Module |
Name |
Synopsis |
Verify IPv6 TFTP session through the router |
apps-v6.tcl |
ipv6_app_124 |
Verify IPv6 TFTP session through the router |
step 1. Startup a TFTP server on the WAN
step 2. Initiate an outbound TFTP connection to TFTP server from LAN
step 3. Send TFTP GET to receive file via TFTP
step 4. Verify TFTP server correctly returns file via TFTP
step 5. Close TFTP session from LAN side
References:
IETF RFC 1350 "THE TFTP PROTOCOL (REVISION 2)"
https://tools.ietf.org/html/rfc1350
| Test |
Module |
Name |
Synopsis |
Verify IPv6 NTP session through the router |
apps-v6.tcl |
ipv6_app_126 |
Verify IPv6 NTP session through the router |
step 1. Initiate an outbound NTP connection to NTP server
step 2. Verify NTP request is sent to the WAN
step 3. Verify NTP response is sent to LAN client
| Test |
Module |
Name |
Synopsis |
Verify IPv6 STUN session through the router |
apps-v6.tcl |
ipv6_app_130 |
Verify IPv6 STUN session through the router |
step 1. Initiate an outbound STUN Binding Request to remoteHost
step 2. Verify STUN Binding Response is received
step 3. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6
address of the STUN client
References:
IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"
https://tools.ietf.org/html/rfc3489
| Test |
Module |
Name |
Synopsis |
Verify IPv6 authenticated STUN session through the router |
apps-v6.tcl |
ipv6_app_131 |
Verify IPv6 authenticated STUN session through the router |
step 1. Configure STUN server and client to use authentication
step 2. Initiate an outbound STUN Binding Request to remoteHost
step 3. STUN server should sent back a 401 Binding Error Response
step 4. STUN client retransmits Binding Request using message-integrity attribute
step 5. Verify STUN Binding Response is received
step 6. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6
address of the STUN client
References:
IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"
https://tools.ietf.org/html/rfc3489
| Test |
Module |
Name |
Synopsis |
Verify IPv6 L2GRE session through the router |
apps-v6.tcl |
ipv6_app_140 |
Verify IPv6 L2GRE session through the router |
step 1. Enable L2GRE endpoint on the LAN client
step 2. Create a new IPv6 address on the WAN for the other L2GRE endpoint
step 3. Initiate an ICMPv6 ping from LAN to WAN using L2GRE tunnel
step 4. Verify the ICMPv6 is successful
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify a Multipath TCP connection can be opened (IPv6) |
apps-v6.tcl |
ipv6_mptcp_1 |
Verify a Multipath TCP connection can be opened (IPv6) |
step 1. Initiate MPTCP connection from LAN client to WAN server
step 2. Verify MPTCP connection is established
step 3. Verify MPTCP connection attributes on LAN client and
WAN server match
step 4. Close MPTCP connection
References:
IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"
https://tools.ietf.org/html/rfc8684
| Test |
Module |
Name |
Synopsis |
Verify a Multipath TCP connection with two subflows can be opened (IPv6) |
apps-v6.tcl |
ipv6_mptcp_2 |
Verify a Multipath TCP connection with two subflows can be opened (IPv6) |
step 1. Initiate MPTCP connection from LAN client to WAN server
step 2. Verify MPTCP connection is established
step 3. Verify MPTCP connection attributes on LAN client and
WAN server match
step 4. Transmit data on MPTCP connection from LAN client
step 5. Verify data is received by WAN server
step 6. Initiate new MPTCP subflow on MPTCP connection from
step 1
step 7. Verify new MPTCP subflow is established
step 8. Verify MPTCP subflow attributes on LAN client and WAN
server match
step 9. Transmit data on MPTCP connection from LAN client
step 10. Verify data is received by WAN server
step 11. Close MPTCP connection
References:
IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"
https://tools.ietf.org/html/rfc8684
forward-v6.tcl
IPv6 forwarding tests with different packet sizes and directions
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Hop Limit is decremented for forwarded packets |
forward-v6.tcl |
ipv6_forward_1 |
Verify IPv6 Hop Limit is decremented for forwarded packets |
step 1. Forward an IPv6 packet from a LAN client to the WAN
step 2. Verify the Hop Limit of the packet is decremented by 1
NOTE: Decremented by 1 by each node that forwards the packet.
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format
https://tools.ietf.org/html/rfc2460#section-3
| Test |
Module |
Name |
Synopsis |
Verify IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 |
forward-v6.tcl |
ipv6_forward_2 |
Verify IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 |
step 1. Set the IPv6 Hop Limit of outbound packets to 1
step 2. Forward an IPv6 packet from a LAN client to the WAN
step 3. Verify the packet is not forwarded
step 4. Repeat the test with a Hop Limit of 0
NOTE: The packet is discarded if Hop Limit is decremented to zero.
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format
https://tools.ietf.org/html/rfc2460#section-3
| Test |
Module |
Name |
Synopsis |
Verify IPv6 packet can be forwarded back through incoming LAN interface |
forward-v6.tcl |
ipv6_forward_3 |
Verify IPv6 packet can be forwarded back through incoming LAN interface |
step 1. Forward an IP packet from a LAN client to another LAN client
step 2. Forward packet using router's MAC address
step 3. Verify packet is forwarded back out the LAN interface
NOTE: The router may send an ICMP Redirect back to the originator.
| Test |
Module |
Name |
Synopsis |
Forward IPv6 UDP packets with various packet lengths (LAN to WAN) |
forward-v6.tcl |
ipv6_forward_10 |
Forward IPv6 UDP packets with various packet lengths (LAN to WAN) |
step 1. Initiate an outbound UDP connection with UDP data length of 4
step 2. Verify packets are received on the WAN interface
step 3. Continue forwarding until the maximum unfragmented packet length is reached
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IPv4/IPv6 address. This can cause this test to fail.
NOTE: Some routers allow static configuration of the MTU size. This may
default to 1492 even for routers running DHCP on the WAN side.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardless of the result.
testvar forwardingMaxFailures 20
| Test |
Module |
Name |
Synopsis |
Forward IPv6 UDP packets with various packet lengths (WAN to LAN) |
forward-v6.tcl |
ipv6_forward_11 |
Forward IPv6 UDP packets with various packet lengths (WAN to LAN) |
step 1. Initiate an outbound UDP connection with UDP data length of 4
step 2. Verify packet is received on the WAN interface
step 3. Forward a return packet from the WAN to the LAN
step 4. Verify packets are received on the LAN interface
step 5. Continue forwarding until the maximum unfragmented packet length is reached
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IPv6/IPv6 address. This can cause this test to fail.
NOTE: Some routers allow static configuration of the MTU size. This may
default to 1492 even for routers running DHCP on the WAN side.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardless of the result.
testvar forwardingMaxFailures 20
jumbo-v6.tcl
Jumbo MTU IPv6 forwarding tests with different packet sizes and directions
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Hop Limit is decremented for forwarded jumbo MTU packets |
jumbo-v6.tcl |
ipv6_jumbo_1 |
Verify IPv6 Hop Limit is decremented for forwarded jumbo MTU packets |
step 1. Forward an IPv6 packet from a LAN client to the WAN that utilizes
the maximum supported jumbo mtu of both interfaces
step 2. Verify the Hop Limit of the packet is decremented by 1
NOTE: Decremented by 1 by each node that forwards the packet.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: Header Format
https://tools.ietf.org/html/rfc2460#section-3
| Test |
Module |
Name |
Synopsis |
Verify jumbo MTU IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 |
jumbo-v6.tcl |
ipv6_jumbo_2 |
Verify jumbo MTU IPv6 packet is not forwarded when IPv6 Hop Limit is 1 or 0 |
step 1. Set the IPv6 Hop Limit of outbound packets to 1
step 2. Forward an IPv6 packet from a LAN client to the WAN that utilizes
the maximum supported jumbo mtu of both interfaces
step 3. Verify the packet is not forwarded
step 4. Repeat the test with a Hop Limit of 0
NOTE: The packet is discarded if Hop Limit is decremented to zero.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
References:
IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 3: IPv6 Header Format
https://tools.ietf.org/html/rfc2460#section-3
| Test |
Module |
Name |
Synopsis |
Verify jumbo MTU IPv6 packet can be forwarded back through incoming LAN interface |
jumbo-v6.tcl |
ipv6_jumbo_3 |
Verify jumbo MTU IPv6 packet can be forwarded back through incoming LAN interface |
step 1. Forward an IP packet from a LAN client to another LAN client that
utilizes the maximum supported jumbo mtu of both interfaces
step 2. Forward packet using router's MAC address
step 3. Verify packet is forwarded back out the LAN interface
NOTE: The router may send an ICMP Redirect back to the originator.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
| Test |
Module |
Name |
Synopsis |
Forward jumbo MTU IPv6 UDP packets with various packet lengths (LAN to WAN) |
jumbo-v6.tcl |
ipv6_jumbo_10 |
Forward jumbo MTU IPv6 UDP packets with various packet lengths (LAN to WAN) |
step 1. Initiate an outbound UDP connection with UDP packet that
utilizes the maximum supported standard mtu of both interfaces
step 2. Verify packets are received on the WAN interface
step 3. Continue forwarding until the maximum unfragmented packet length is
reached, i.e. maximum supported jumbo mtu of both interfaces
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IPv4/IPv6 address. This can cause this test to fail.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardless of the result.
testvar forwardingMaxFailures 20
| Test |
Module |
Name |
Synopsis |
Forward jumbo MTU IPv6 UDP packets with various packet lengths (WAN to LAN) |
jumbo-v6.tcl |
ipv6_jumbo_11 |
Forward jumbo MTU IPv6 UDP packets with various packet lengths (WAN to LAN) |
step 1. Initiate an outbound UDP connection with UDP packet that utilizes
the maximum supported standard mtu of both interfaces
step 2. Verify packet is received on the WAN interface
step 3. Forward a return packet from the WAN to the LAN that utilizes the
maximum supported standard mtu of both interfaces
step 4. Verify packets are received on the LAN interface
step 5. Continue forwarding until the maximum unfragmented packet length is
reached, i.e maximum supported jumbo mtu of both interfaces
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IPv6/IPv6 address. This can cause this test to fail.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardless of the result.
testvar forwardingMaxFailures 20
scaling-v6.tcl
Scaling tests for maximum number of IPv6 clients and connections (TCP, HTTP, etc)
| Test |
Module |
Name |
Synopsis |
Verify all IPv6 clients obtain an IPv6 address via autoconf or DHCPv6 and are operational |
scaling-v6.tcl |
ipv6_scale_1 |
Verify all IPv6 clients obtain an IPv6 address via autoconf or DHCPv6 and are operational |
step 1. Determine the size of the LAN IPv6 address pool
step 2. Create a new client for each available address within the pool
step 3. Verify the client obtains an IPv6 address via autoconfiguration or DHCPv6
step 4. Verify there are no address conflicts
step 5. Verify each client can establish an outbound HTTP connection
step 6. Verify each client can send/receive data over the connection
step 7. Close each TCP connection
NOTE: The DHCPv6 address pool size is set in your configuration file using
the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
remains in use through the test run for a host on the LAN side. This test
will attempt to create clients for the pool size - 1. If you are using
multiple LAN interfaces, the number of DHCPv6 clients from each interface
will also be subtracted from the DHCPv6 pool size.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify all IPv6 clients with multiple TCP connections |
scaling-v6.tcl |
ipv6_scale_2 |
Verify all IPv6 clients with multiple TCP connections |
step 1. Determine the size of the IPv6 LAN address pool
step 2. Determine the maximum number of TCP connections to create for
each client
step 3. Create a new client for each available address within the pool
step 4. Verify the client obtains an IPv6 address via autoconf or DHCPv6
step 5. Verify there are no address conflicts
step 6. Verify each client can establish X outbound HTTP connections to
port 80, where X is the number of TCP connections per DHCPv6 client
to create. Each connection is to a unique IP address.
step 7. Verify each client can send/receive data over each connection
step 8. Close each TCP connection
NOTE: The DHCPv6 address pool size is set in your configuration file using
the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
remains in use through the test run for a host on the LAN side. This test
will attempt to create clients for the pool size - 1. If you are using
multiple LAN interfaces, the number of DHCPv6 clients from each interface
will also be subtracted from the DHCPv6 pool size.
NOTE: The maximum number of TCP connections per host is set in your
configuration file using the testvar 'scaleTcpConnsPerHost'. If this entry
is not included in your configuration file, it defaults to 5.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
| Test |
Module |
Name |
Synopsis |
Verify all IPv6 clients with single UDP connection |
scaling-v6.tcl |
ipv6_scale_3 |
Verify all IPv6 clients with single UDP connection |
step 1. Determine the size of the IPv6 LAN address pool
step 2. Determine the maximum number of UDP connections to create for
each DHCP client
step 3. Create a DHCP client for each available address within the pool
step 4. Verify each client obtains an IP address within the range
step 5. Verify there are no address conflicts
step 6. Verify each client can establish one outbound UDP connection
step 7. Verify each client can send/receive data over each connection
step 8. Release all new DHCP client leases
NOTE: The DHCPv6 address pool size is set in your configuration file using
the 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addresses
remains in use through the test run for a host on the LAN side. This test
will attempt to create clients for the pool size - 1. If you are using
multiple LAN interfaces, the number of DHCPv6 clients from each interface
will also be subtracted from the DHCPv6 pool size.
References:
IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
https://tools.ietf.org/html/rfc3315
IETF RFC 4862 "IPv6 Stateless Address Autoconfiguration"
https://tools.ietf.org/html/rfc4862
dslite.tcl
DS-Lite tests for tunneling IPv4 over IPv6
| Test |
Module |
Name |
Synopsis |
Verify NAT is not enabled on DS-Lite B4 interface |
dslite.tcl |
dslite_1 |
Verify NAT is not enabled on DS-Lite B4 interface |
step 1. Initiate an outbound TCP connection to HTTP server
step 2. Verify the connection is established
step 3. Send HTTP GET request to server
step 4. Verify HTTP response is received
step 5. Verify the IPv4 source address on the WAN side is original LAN address
step 6. Close TCP connection from LAN side
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE
A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
interface and a B4 interface, as the NAT function will be performed
by the AFTR in the service provider's network. This will avoid
accidentally operating in a double-NAT environment.
https://tools.ietf.org/html/rfc6333#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify B4 Element announces itself as the IPv4 default gateway using DHCPv4 |
dslite.tcl |
dslite_10 |
Verify B4 Element announces itself as the IPv4 default gateway using DHCPv4 |
step 1. Send a DHCPREQUEST for the current IP address
step 2. Verify DHCP server sends DHCPACK
step 3. Verify the gateway address is the router's LAN IPv4 address
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE
A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
interface and a B4 interface, as the NAT function will be performed
by the AFTR in the service provider's network. This will avoid
accidentally operating in a double-NAT environment.
However, it SHOULD operate its own DHCP(v4) server handing out
[RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.
It SHOULD advertise itself as the default IPv4 router to those home
hosts. It SHOULD also advertise itself as a DNS server in the DHCP
Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy
to accept DNS IPv4 requests from home hosts and send them using IPv6
to the service provider DNS servers, as described in Section 5.5.
https://tools.ietf.org/html/rfc6333#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify B4 Element announces itself as the IPv4 DNS server using DHCPv4 |
dslite.tcl |
dslite_11 |
Verify B4 Element announces itself as the IPv4 DNS server using DHCPv4 |
step 1. Send a DHCPREQUEST for the current IP address
step 2. Verify DHCP server sends DHCPACK
step 3. Verify the DNS server address is the router's LAN IPv4 address
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 4.2: CPE
A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
interface and a B4 interface, as the NAT function will be performed
by the AFTR in the service provider's network. This will avoid
accidentally operating in a double-NAT environment.
However, it SHOULD operate its own DHCP(v4) server handing out
[RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.
It SHOULD advertise itself as the default IPv4 router to those home
hosts. It SHOULD also advertise itself as a DNS server in the DHCP
Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy
to accept DNS IPv4 requests from home hosts and send them using IPv6
to the service provider DNS servers, as described in Section 5.5.
https://tools.ietf.org/html/rfc6333#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify DS-Lite packet fragmentation occurs at IPv6 layer and not the IPv4 layer |
dslite.tcl |
dslite_20 |
Verify DS-Lite packet fragmentation occurs at IPv6 layer and not the IPv4 layer |
step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
step 2. Verify the packet is received on the WAN
step 3. Verify the packet results in IPv6 fragments and no IPv4 fragments
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation
(b) if in the original packet header the Don't Fragment - DF -
bit flag is CLEAR, the tunnel entry-point node encapsulates
the original packet, and subsequently fragments the
resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the Path MTU to the tunnel exit-point.
https://tools.ietf.org/html/rfc2473#section-7.2
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method
to deal with this problem.
A solution to deal with this problem is for the service provider to
increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6
encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.
However, as not all service providers will be able to increase their
link MTU, the B4 element MUST perform fragmentation and reassembly if
the outgoing link MTU cannot accommodate the extra IPv6 header. The
original IPv4 packet is not oversized. The packet is oversized after
the IPv6 encapsulation. The inner IPv4 packet MUST NOT be
fragmented. Fragmentation MUST happen after the encapsulation of the
IPv6 packet. Reassembly MUST happen before the decapsulation of the
IPv4 packet. A detailed procedure has been specified in [RFC2473]
Section 7.2.
https://tools.ietf.org/html/rfc6333#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify IPv4 ICMP Unreachable is generated if DF=1 and packet would fragment |
dslite.tcl |
dslite_21 |
Verify IPv4 ICMP Unreachable is generated if DF=1 and packet would fragment |
step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
step 2. Verify an ICMP unreachable with code 4 is received on the LAN
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation
(b) if in the original packet header the Don't Fragment - DF -
bit flag is CLEAR, the tunnel entry-point node encapsulates
the original packet, and subsequently fragments the
resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the Path MTU to the tunnel exit-point.
https://tools.ietf.org/html/rfc2473#section-7.2
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method
to deal with this problem.
A solution to deal with this problem is for the service provider to
increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6
encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.
However, as not all service providers will be able to increase their
link MTU, the B4 element MUST perform fragmentation and reassembly if
the outgoing link MTU cannot accommodate the extra IPv6 header. The
original IPv4 packet is not oversized. The packet is oversized after
the IPv6 encapsulation. The inner IPv4 packet MUST NOT be
fragmented. Fragmentation MUST happen after the encapsulation of the
IPv6 packet. Reassembly MUST happen before the decapsulation of the
IPv4 packet. A detailed procedure has been specified in [RFC2473]
Section 7.2.
https://tools.ietf.org/html/rfc6333#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify IPv4 packet is dropped if DF=1 and packet would fragment |
dslite.tcl |
dslite_22 |
Verify IPv4 packet is dropped if DF=1 and packet would fragment |
step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496
step 2. Verify packet is not forwarded to the WAN
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation
(b) if in the original packet header the Don't Fragment - DF -
bit flag is CLEAR, the tunnel entry-point node encapsulates
the original packet, and subsequently fragments the
resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the Path MTU to the tunnel exit-point.
https://tools.ietf.org/html/rfc2473#section-7.2
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.3: Fragmentation and Reassembly
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method
to deal with this problem.
A solution to deal with this problem is for the service provider to
increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6
encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.
However, as not all service providers will be able to increase their
link MTU, the B4 element MUST perform fragmentation and reassembly if
the outgoing link MTU cannot accommodate the extra IPv6 header. The
original IPv4 packet is not oversized. The packet is oversized after
the IPv6 encapsulation. The inner IPv4 packet MUST NOT be
fragmented. Fragmentation MUST happen after the encapsulation of the
IPv6 packet. Reassembly MUST happen before the decapsulation of the
IPv4 packet. A detailed procedure has been specified in [RFC2473]
Section 7.2.
https://tools.ietf.org/html/rfc6333#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify DNS queries sent to router over IPv4 are forwarded to IPv6 DNS server |
dslite.tcl |
dslite_30 |
Verify DNS queries sent to router over IPv4 are forwarded to IPv6 DNS server |
step 1. Initiate a DNS query to the router's LAN ip address
step 2. Verify the query is received by real DNS server on the WAN side
step 3. The query may be received by the primary or backup DNS server
step 4. Verify the DNS query is using IPv6 and not IPv4
step 5. Send a return response back to LAN
step 6. Verify the response is received by the LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.5: DNS
A B4 element is only configured from the service provider with IPv6.
As such, it can only learn the address of a DNS recursive server
through DHCPv6 (or other similar method over IPv6). As DHCPv6 only
defines an option to get the IPv6 address of such a DNS recursive
server, the B4 element cannot easily discover the IPv4 address of
such a recursive DNS server, and as such will have to perform all DNS
resolution over IPv6.
https://tools.ietf.org/html/rfc6333#section-5.5
| Test |
Module |
Name |
Synopsis |
Verify LAN clients can reach the IPv4 address of DS-Lite AFTR |
dslite.tcl |
dslite_40 |
Verify LAN clients can reach the IPv4 address of DS-Lite AFTR |
step 1. Initiate an outbound ICMP Echo Request to the IPv4 address of the WAN (AFTR)
step 2. Verify ICMP Echo Reply (ping response) is received
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 6.5: Well-Known IPv4 Address
The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by
IANA to configure the IPv4-in-IPv6 tunnel. That address can then be
used to report ICMP problems and will appear in traceroute outputs.
The following testvars are used to configure the AFTR and B4 addresses:
AFTR: testvar wanIspIp 192.0.0.1
B4: testvar wanIspAssignIp 192.0.0.2
https://tools.ietf.org/html/rfc6333#section-6.5
| Test |
Module |
Name |
Synopsis |
Verify LAN clients can reach the IPv4 address of DS-Lite B4 |
dslite.tcl |
dslite_41 |
Verify LAN clients can reach the IPv4 address of DS-Lite B4 |
step 1. Initiate an outbound ICMP Echo Request to the IPv4 address of the CPE WAN (B4)
step 2. Verify ICMP Echo Reply (ping response) is received
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 5.7: Well-Known IPv4 Address
Any locally unique IPv4 address could be configured on the IPv4-in-
IPv6 tunnel to represent the B4 element. Configuring such an address
is often necessary when the B4 element is sourcing IPv4 datagrams
directly over the tunnel. In order to avoid conflicts with any other
address, IANA has defined a well-known range, 192.0.0.0/29.
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for
the AFTR element, and 192.0.0.2 is reserved for the B4 element. If a
service provider has a special configuration that prevents the B4
element from using 192.0.0.2, the B4 element MAY use any other
addresses within the 192.0.0.0/29 range.
Note: A range of addresses has been reserved for this purpose. The
intent is to accommodate nodes implementing multiple B4 elements.
The following testvars are used to configure the AFTR and B4 addresses:
AFTR: testvar wanIspIp 192.0.0.1
B4: testvar wanIspAssignIp 192.0.0.2
https://tools.ietf.org/html/rfc6333#section-5.7
| Test |
Module |
Name |
Synopsis |
Verify IPv4 TOS is copied to IPv6 Traffic Class |
dslite.tcl |
dslite_42 |
Verify IPv4 TOS is copied to IPv6 Traffic Class |
step 1. Forward an IPv4 packet from a LAN client to the WAN with a specific TOS
step 2. Verify the packet is received on the WAN (AFTR)
step 3. Verify that the IPv4 TOS and IPv6 Traffic Class are set to
the IPv4 TOS from step 1
step 4. Forward an IPv4 packet from the WAN to a LAN client with a specific TOS
step 5. Verify the packet is received by the LAN client
step 6. Verify that the IPv4 TOS are set to the IPv4 TOS from step 4
step 7. Repeat steps 1 to 7 with several different IPv4 TOS values
References:
IETF RFC 6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" Section 7.1: Tunneling
Tunneling MUST be done in accordance to [RFC2473] and [RFC4213].
Traffic classes ([RFC2474]) from the IPv4 headers MUST be carried
over to the IPv6 headers and vice versa.
https://tools.ietf.org/html/rfc6333#section-7.1
dns-v6.tcl
IPv6 DNS proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns-v6.tcl |
ipv6_dns_10 |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns-v6.tcl |
ipv6_dns_11 |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-v6.tcl |
ipv6_dns_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns-v6.tcl |
ipv6_dns_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns-v6.tcl |
ipv6_dns_45 |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
dns-v6.tcl |
ipv6_dns_46 |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns-v6.tcl |
ipv6_dns_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-v6.tcl |
ipv6_dns_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
dns-v6.tcl |
ipv6_dns_60 |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS lookups with multiple IPv4 responses |
dns-v6.tcl |
ipv6_dns_70 |
Verify IPv6 DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy recovers after DNS server outage |
dns-v6.tcl |
ipv6_dns_100 |
Verify IPv6 DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries including the EDNS0 option |
dns-v6.tcl |
ipv6_dns_110 |
Verify IPv6 DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns-v6.tcl |
ipv6_dns_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns-v6.tcl |
ipv6_dns_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for TXT records |
dns-v6.tcl |
ipv6_dns_130 |
Verify IPv6 DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
Reference: RFC 1035 Domain names - implementation and specification
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns-v6.tcl |
ipv6_dns_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns-v6.tcl |
ipv6_dns_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns-v6.tcl |
ipv6_dns_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SPF records |
dns-v6.tcl |
ipv6_dns_140 |
Verify IPv6 DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SRV records |
dns-v6.tcl |
ipv6_dns_141 |
Verify IPv6 DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns-v6.tcl |
ipv6_dns_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to a
value of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
dns-v6.tcl |
ipv6_dns_200 |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
dns-v6.tcl |
ipv6_dns_201 |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy honors TTL values when caching responses |
dns-v6.tcl |
ipv6_dns_300 |
Verify IPv6 DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns-v6.tcl |
ipv6_dns_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that the last 10 hostname lookups are not cached by
the DUT's DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns-v6.tcl |
ipv6_dns_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server.
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1.
step 3. Verify that DNS responses are received for both DNS
queries.
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns-v6.tcl |
ipv6_dns_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns-v6.tcl |
ipv6_dns_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns-v6.tcl |
ipv6_dns_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns-v6.tcl |
ipv6_dns_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using DNS over TLS
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
dns-tcp-v6.tcl
IPv6 DNS over TCP proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns-tcp-v6.tcl |
ipv6_dns_tcp_10 |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns-tcp-v6.tcl |
ipv6_dns_tcp_11 |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tcp-v6.tcl |
ipv6_dns_tcp_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns-tcp-v6.tcl |
ipv6_dns_tcp_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns-tcp-v6.tcl |
ipv6_dns_tcp_45 |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
dns-tcp-v6.tcl |
ipv6_dns_tcp_46 |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns-tcp-v6.tcl |
ipv6_dns_tcp_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tcp-v6.tcl |
ipv6_dns_tcp_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
dns-tcp-v6.tcl |
ipv6_dns_tcp_60 |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS lookups with multiple IPv4 responses |
dns-tcp-v6.tcl |
ipv6_dns_tcp_70 |
Verify IPv6 DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy recovers after DNS server outage |
dns-tcp-v6.tcl |
ipv6_dns_tcp_100 |
Verify IPv6 DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries including the EDNS0 option |
dns-tcp-v6.tcl |
ipv6_dns_tcp_110 |
Verify IPv6 DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns-tcp-v6.tcl |
ipv6_dns_tcp_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
Reference: RFC 6891 Extension Mechanisms for DNS (EDNS0)
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns-tcp-v6.tcl |
ipv6_dns_tcp_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for TXT records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_130 |
Verify IPv6 DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
Reference: RFC 1035 Domain names - implementation and specification
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SPF records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_140 |
Verify IPv6 DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SRV records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_141 |
Verify IPv6 DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns-tcp-v6.tcl |
ipv6_dns_tcp_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to av
alue of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
dns-tcp-v6.tcl |
ipv6_dns_tcp_200 |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
dns-tcp-v6.tcl |
ipv6_dns_tcp_201 |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy honors TTL values when caching responses |
dns-tcp-v6.tcl |
ipv6_dns_tcp_300 |
Verify IPv6 DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns-tcp-v6.tcl |
ipv6_dns_tcp_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that the last 10 hostname lookups are not cached by
the DUT's DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns-tcp-v6.tcl |
ipv6_dns_tcp_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server.
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1.
step 3. Verify that DNS responses are received for both DNS
queries.
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns-tcp-v6.tcl |
ipv6_dns_tcp_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns-tcp-v6.tcl |
ipv6_dns_tcp_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns-tcp-v6.tcl |
ipv6_dns_tcp_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using DNS over TLS
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
dns-tls-v6.tcl
IPv6 DNS over TLS proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns-tls-v6.tcl |
ipv6_dns_tls_10 |
Verify IPv6 DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns-tls-v6.tcl |
ipv6_dns_tls_11 |
Verify IPv6 DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tls-v6.tcl |
ipv6_dns_tls_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns-tls-v6.tcl |
ipv6_dns_tls_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns-tls-v6.tcl |
ipv6_dns_tls_45 |
Verify IPv6 DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
dns-tls-v6.tcl |
ipv6_dns_tls_46 |
Verify IPv6 DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns-tls-v6.tcl |
ipv6_dns_tls_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tls-v6.tcl |
ipv6_dns_tls_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
dns-tls-v6.tcl |
ipv6_dns_tls_60 |
Verify IPv6 DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS lookups with multiple IPv4 responses |
dns-tls-v6.tcl |
ipv6_dns_tls_70 |
Verify IPv6 DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy recovers after DNS server outage |
dns-tls-v6.tcl |
ipv6_dns_tls_100 |
Verify IPv6 DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries including the EDNS0 option |
dns-tls-v6.tcl |
ipv6_dns_tls_110 |
Verify IPv6 DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns-tls-v6.tcl |
ipv6_dns_tls_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns-tls-v6.tcl |
ipv6_dns_tls_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for TXT records |
dns-tls-v6.tcl |
ipv6_dns_tls_130 |
Verify IPv6 DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
Reference: RFC 1035 Domain names - implementation and specification
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns-tls-v6.tcl |
ipv6_dns_tls_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns-tls-v6.tcl |
ipv6_dns_tls_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns-tls-v6.tcl |
ipv6_dns_tls_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SPF records |
dns-tls-v6.tcl |
ipv6_dns_tls_140 |
Verify IPv6 DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS queries for SRV records |
dns-tls-v6.tcl |
ipv6_dns_tls_141 |
Verify IPv6 DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns-tls-v6.tcl |
ipv6_dns_tls_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to av
alue of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
dns-tls-v6.tcl |
ipv6_dns_tls_200 |
Verify IPv6 DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
dns-tls-v6.tcl |
ipv6_dns_tls_201 |
Verify IPv6 DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify IPv6 DNS proxy honors TTL values when caching responses |
dns-tls-v6.tcl |
ipv6_dns_tls_300 |
Verify IPv6 DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns-tls-v6.tcl |
ipv6_dns_tls_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that the last 10 hostname lookups are not cached by
the DUT's DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns-tls-v6.tcl |
ipv6_dns_tls_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server.
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1.
step 3. Verify that DNS responses are received for both DNS
queries.
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns-tls-v6.tcl |
ipv6_dns_tls_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns-tls-v6.tcl |
ipv6_dns_tls_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns-tls-v6.tcl |
ipv6_dns_tls_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns-tls-v6.tcl |
ipv6_dns_tls_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using DNS over TLS
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
url-filter-v6.tcl
IPv6 URL filtering tests for LAN side HTTP clients
| Test |
Module |
Name |
Synopsis |
Verify HTTP GETs to filtered URLs over IPv6 are blocked |
url-filter-v6.tcl |
ipv6_urlfilter_10 |
Verify HTTP GETs to filtered URLs over IPv6 are blocked |
step 1. Set up new web server on WAN side using IPv6 free network address
step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP GETs to filtered URLs over IPv6 are blocked without DNS lookups |
url-filter-v6.tcl |
ipv6_urlfilter_12 |
Verify HTTP GETs to filtered URLs over IPv6 are blocked without DNS lookups |
step 1. Set up new web server on WAN side using IPv6 free network address
step 2. Resolve only domain IPv6 addresses for non-filtered URLs using AAAA
lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP HEADs to filtered URLs over IPv6 are blocked |
url-filter-v6.tcl |
ipv6_urlfilter_15 |
Verify HTTP HEADs to filtered URLs over IPv6 are blocked |
step 1. Set up new web server on WAN side using IPv6 free network address
step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP HEAD from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP POSTs to filtered URLs over IPv6 are blocked |
url-filter-v6.tcl |
ipv6_urlfilter_20 |
Verify HTTP POSTs to filtered URLs over IPv6 are blocked |
step 1. Set up new web server on WAN side using IPv6 free network address
step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP POST from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify URL filtering over IPv6 does not look at Cookie data |
url-filter-v6.tcl |
ipv6_urlfilter_30 |
Verify URL filtering over IPv6 does not look at Cookie data |
step 1. Set up new web server on WAN side using IPv6 free network address
step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. Use one of the filtered URLs as the cookie data
step 7. Verify webserver does return a response
step 8. Repeat for each configured allowed URL
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
| Test |
Module |
Name |
Synopsis |
Verify HTTPS GETs to filtered URLs over IPv6 are blocked |
url-filter-v6.tcl |
ipv6_urlfilter_40 |
Verify HTTPS GETs to filtered URLs over IPv6 are blocked |
step 1. Set up new HTTPS server on WAN side using IPv6 free network address
step 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN client
step 3. Initiate IPv6 TCP connection to web server from LAN client
step 4. If TCP connection is not established, skip to step 9
step 5. Verify TCP connection is opened
step 6. Establish SSL connection to server
step 7. Send HTTPS GET from LAN client to new server for requested URL
step 8. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 9. Repeat for each configured filtered URL
step 10. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 8, or using a proxy to return a 200 HTTP status code
in step 8 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
mcast-v6.tcl
MLDv1/v2 and multicast data tests for IPv6 MLD proxy
| Test |
Module |
Name |
Synopsis |
MLD packets from LAN are proxied to WAN interface |
mcast-v6.tcl |
ipv6_mcast_1 |
MLD packets from LAN are proxied to WAN interface |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Repeat test using an MLDv1 Leave packet or MLDv2 Memebership Report
to leave the multicast group
step 6. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: Some routers may send an MLD query on the LAN interface after the
MLD Leave from the LAN client. The MLD Leave may not be sent on the
WAN interface until the LAN side has made multiple queries.
The amount of time this test case should wait before expecting the
MLD Leave on the WAN interface may be configured by setting the
testvar 'ipv6MulticastCacheTimeout'.
Example:
testvar ipv6MulticastCacheTimeout 30
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify IPv6 Hop-Limit is decremented for multicast packets |
mcast-v6.tcl |
ipv6_mcast_2 |
Verify IPv6 Hop-Limit is decremented for multicast packets |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Verify the TTL is decremented by the expected IP hop count
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The number of expected IP hops can be configured using the testvar
'IPv6HopCount'. The default is 1 IP hop. If the device is using bridge
mode, the expected IPv6HopCount is 0.
NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
MLD report. The default value is 2 seconds.
testvar ipv6MulticastJoinDelay 2
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Forward Multicast IPv6 UDP packets with various packet lengths (LAN to WAN) |
mcast-v6.tcl |
ipv6_mcast_11 |
Forward Multicast IPv6 UDP packets with various packet lengths (LAN to WAN) |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the WAN interface
step 3. Forward a multicast UDP packet from the LAN with UDP length 4
step 4. Verify the packet is received on the WAN interface
step 5. Repeat for all packet sizes up to the max MTU
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
MLD report. The default value is 2 seconds.
testvar ipv6MulticastJoinDelay 2
NOTE: If the device does not support forwarding multiast traffic
to the WAN, this test case may be skipped by setting
the testvar supportsIPv6MulticastOut to no.
For example,
testvar supportsIPv6MulticastOut no
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Forward Multicast IPv6 UDP packets with various packet lengths (WAN to LAN) |
mcast-v6.tcl |
ipv6_mcast_12 |
Forward Multicast IPv6 UDP packets with various packet lengths (WAN to LAN) |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Forward a multicast UDP packet from the WAN with UDP length 4
step 4. Verify the packet is received on the LAN interface
step 5. Repeat for all packet sizes up to the max MTU
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
MLD report. The default value is 2 seconds.
testvar ipv6MulticastJoinDelay 2
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLD router periodically sends general MLD Query on LAN interface |
mcast-v6.tcl |
ipv6_mcast_20 |
Verify MLD router periodically sends general MLD Query on LAN interface |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Wait up to mldQueryInterval seconds for a general MLD Query on the LAN
step 3. Repeat for 2 queries
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded if no group members exist |
mcast-v6.tcl |
ipv6_mcast_50 |
Multicast streams are not forwarded if no group members exist |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Allocate a multicast group that has no members on the LAN
step 3. Forward UDP multicast packet from WAN to LAN using group
step 4. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded after last member leaves group |
mcast-v6.tcl |
ipv6_mcast_51 |
Multicast streams are not forwarded after last member leaves group |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Send a MLD Leave packet on the LAN interface for group
step 6. Wait for the multicast cache to expire
step 7. Forward UDP multicast packet from WAN to LAN using group
step 8. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded after last member ages out |
mcast-v6.tcl |
ipv6_mcast_52 |
Multicast streams are not forwarded after last member ages out |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Wait for the multicast group to expire
step 6. Forward UDP multicast packet from WAN to LAN using group
step 7. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
NOTE: The amount of time it takes the multicast group to expire is
based on the mldQueryInterval, mldRobustnessVariable, and
mldQueryResponseInterval. These can all be configured using the
following testvars:
testvar mldQueryInterval 125
testvar mldRobustnessVariable 2
testvar mldQueryResponseInterval 10
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
MLD proxy interface answers MLD general query requests |
mcast-v6.tcl |
ipv6_mcast_53 |
MLD proxy interface answers MLD general query requests |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for MLD membership report on the WAN
step 4. Issue an MLD Membership query to ff02::1 on WAN for group address ::
step 5. Verify router's WAN side responds with MLD membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
MLD proxy interface answers MLD specific query requests |
mcast-v6.tcl |
ipv6_mcast_54 |
MLD proxy interface answers MLD specific query requests |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for MLD membership report on the WAN
step 4. Issue an MLD Membership query to ff02::1 on WAN for specific group address
step 5. Verify router's WAN side responds with MLD membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLD router sends MLD Group Specific Query after last member leaves group |
mcast-v6.tcl |
ipv6_mcast_60 |
Verify MLD router sends MLD Group Specific Query after last member leaves group |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
step 3. Send an MLDv2 Leave or MLDv2 Memebership packet on the LAN interface
to leave the multicast group
step 4. Verify an MLDv1/2 Query packet is sent on the LAN interface
to the specific multicast group. If mldFastLeave is set
to yes, verify that no MLD Query is sent.
NOTE: This test will work with a multicast proxy implementation only.
NOTE: If the device supports MLD Fast Leave, the testvar mldFastLeave
should be set to yes. In this case, the test case will verify that
no group specific MLD query is sent after the MLD Leave.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLD router sends MLD Leave after last group member ages out |
mcast-v6.tcl |
ipv6_mcast_70 |
Verify MLD router sends MLD Leave after last group member ages out |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Let group member on the LAN age out. No responses will sent to MLD
queries and no MLD Leave will be sent.
step 6. Verify MLD leave or MLDv2 membership report is received for the group
on the WAN interface
step 7. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The amount of time it takes the multicast group to expire is
based on the mldQueryInterval, mldRobustnessVariable, and
mldQueryResponseInterval. These can all be configured using the
following testvars:
testvar mldQueryInterval 125
testvar mldRobustnessVariable 2
testvar mldQueryResponseInterval 10
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLD router accepts reports with unspecified source address |
mcast-v6.tcl |
ipv6_mcast_80 |
Verify MLD router accepts reports with unspecified source address |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv1/2 Membership Report packet on the LAN interface
with IP src ::
step 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interface
step 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Repeat test using an MLDv1 Leave packet or MLDv2 Memebership Report
to leave the multicast group
step 6. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: Some routers may send an MLD query on the LAN interface after the
MLD Leave from the LAN client. The MLD Leave may not be sent on the
WAN interface until the LAN side has made multiple queries.
The amount of time this test case should wait before expecting the
MLD Leave on the WAN interface may be configured by setting the
testvar 'ipv6MulticastCacheTimeout'.
Example:
testvar ipv6MulticastCacheTimeout 30
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify MLD snooping switch scenario with unspecified source address |
mcast-v6.tcl |
ipv6_mcast_81 |
Verify MLD snooping switch scenario with unspecified source address |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface with IP src ::
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Verify the TTL is decremented by the expected IP hop count
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The number of expected IP hops can be configured using the testvar
'IPv6HopCount'. The default is 1 IP hop.
NOTE: The testvar ipv6MulticastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
MLD report. The default value is 2 seconds.
testvar ipv6MulticastJoinDelay 2
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of multicast groups received on the LAN |
mcast-v6.tcl |
ipv6_mcast_100 |
Verify the maximum number of multicast groups received on the LAN |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Join mldMaxGroups multicast groups on the LAN interface
step 3. Forward a multicast UDP packet from the WAN to each group
step 4. Verify each group is received on the LAN interface
step 5. Send a MLD Leave for each multicast group
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: You can slow down the rate at which CDRouter will join each group
by configuring the testvar ipv6MulticastScaleDelay. It defaults to 1
millisecond.
testvar ipv6MulticastScaleDelay 1
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify IPTV channel change test scenario 1 (no overlap) |
mcast-v6.tcl |
ipv6_mcast_110 |
Verify IPTV channel change test scenario 1 (no overlap) |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the MLDv1 or MLDv2 report is received in the WAN
step 5. Start sending multicast data on the WAN for the new group
step 6. Verify the LAN side starts to receive the multicast data
step 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
step 8. Leave the multicast group on the LAN using MLDv1/2
step 9. Switch to the next channel or exit if too many failures have
occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar ipv6IptvChannelRange specifies the total number of channel changes to
attempt.
The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test early if many channels start failing.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify IPTV channel change test scenario 2 (overlap) |
mcast-v6.tcl |
ipv6_mcast_120 |
Verify IPTV channel change test scenario 2 (overlap) |
step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD version
step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the MLDv1 or MLDv2 report is received in the WAN
step 5. Leave any previous multicast group for the last channel
step 6. Start sending multicast data on the WAN for the new group
step 7. Verify the LAN side starts to receive the multicast data
step 8. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
step 9. Switch to the next channel or exit if too many failures have occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar ipv6IptvChannelRange specifies the total number of channel changes to
attempt.
The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test early if many channels start failing.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES |
mcast-v6.tcl |
ipv6_mcast_200 |
Verify MLDv2 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv2 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding from WAN to LAN for new group using
the specific source address.
step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
step 7. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 router blocks incoming multicast sources that do not match the source list |
mcast-v6.tcl |
ipv6_mcast_210 |
Verify MLDv2 router blocks incoming multicast sources that do not match the source list |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv2 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding fails from WAN to LAN for new group using
the different source address.
step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
step 7. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 router blocks incoming sources on a per group basis |
mcast-v6.tcl |
ipv6_mcast_220 |
Verify MLDv2 router blocks incoming sources on a per group basis |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Send an MLDv2 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an MLDv2 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding from WAN to LAN for new group using
the specific source address.
step 6. Verify multicast forwarding fails from WAN to LAN for a different group
using the same specific source address.
step 7. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
step 8. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 source specific group with multiple sources |
mcast-v6.tcl |
ipv6_mcast_230 |
Verify MLDv2 source specific group with multiple sources |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Create a new server on the WAN for a multicast source
step 3. Send an MLDv2 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing multiple specific source
step 4. Verify an MLDv2 Membership Report packet is received on the WAN interface
step 5. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 6. Verify multicast forwarding from WAN to LAN for new group using
the specific source address from source address 1.
step 7. Verify multicast forwarding from WAN to LAN for new group using
the specific source address from source address 2.
step 8. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast group
step 9. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 general query requests with source specific memberships |
mcast-v6.tcl |
ipv6_mcast_240 |
Verify MLDv2 general query requests with source specific memberships |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for MLD membership report on the WAN
step 4. Issue an MLD Membership query to ff02::1 on WAN for group ::
step 5. Verify router's WAN side responds with MLD membership report for
the multicast group
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 specific query requests with source specific memberships |
mcast-v6.tcl |
ipv6_mcast_250 |
Verify MLDv2 specific query requests with source specific memberships |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for MLD membership report on the WAN
step 4. Issue an MLD Membership query on WAN for specific group address
step 5. Verify router's WAN side responds with MLD membership report for
the multicast group
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 group and source specific query requests |
mcast-v6.tcl |
ipv6_mcast_260 |
Verify MLDv2 group and source specific query requests |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 1. Join a multicast group on the LAN interface
step 2. Wait up to 20 seconds for MLD membership report on the WAN
step 3. Issue an MLD Membership query on WAN for specific group address
step 4. Verify router's WAN side responds with MLD membership report for
the multicast group
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 maximum number of multicast groups with multiple group records |
mcast-v6.tcl |
ipv6_mcast_300 |
Verify MLDv2 maximum number of multicast groups with multiple group records |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Join mldMaxGroups multicast groups on the LAN interface using
multiple group records in a single MLDv2 membership report
step 3. Forward a multicast UDP packet from the WAN to each group
step 4. Verify each group is received on the LAN interface
step 5. Send a MLD Leave for each multicast group
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
| Test |
Module |
Name |
Synopsis |
Verify MLDv2 source specific IPTV channel change test scenario |
mcast-v6.tcl |
ipv6_mcast_310 |
Verify MLDv2 source specific IPTV channel change test scenario |
step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD version
step 2. Check the testvar ipv6IptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the MLDv2 report is received in the WAN
step 5. Start sending multicast data on the WAN for the new group
step 6. Verify the LAN side starts to receive the multicast data
step 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelay
step 8. Send new MLDv2 report to leave current channel and join next channel
or exit if too many failures have occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar ipv6IptvChannelRange specifies the total number of channel changes to
attempt.
The testvar ipv6IptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test earily is many channels start failing.
References:
IETF RFC 2710 "Multicast Listener Discovery (MLD) for IPv6"
https://tools.ietf.org/html/rfc2710
IETF RFC 3810 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6"
https://tools.ietf.org/html/rfc3810
ula.tcl
IPv6 unique local address (ULA) test module
| Test |
Module |
Name |
Synopsis |
Verify Router Advertisements include valid unique local prefix |
ula.tcl |
ula_1 |
Verify Router Advertisements include valid unique local prefix |
step 1. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 2. Verify at least one Router Advertisement contains a valid unique
local prefix that matches the expected unique local prefix
configured using the testvar ipv6LanUlaPrefix
step 3. Verify that the unique local prefix discovered in Step 2 contains
a valid lifetime
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information
https://tools.ietf.org/html/rfc4861#section-4.6.2
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-side Configuration
ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA
prefix [RFC4193].
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify Route Information option is advertised for unique local prefix |
ula.tcl |
ula_2 |
Verify Route Information option is advertised for unique local prefix |
step 1. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 2. Verify at least one Router Advertisement contains a valid unique
local prefix that matches the expected unique local prefix
configured using the testvar ipv6LanUlaPrefix
step 3. Verify that the unique local prefix discovered in Step 2 contains
a valid lifetime
step 4. Verify that the DUT includes a Route Information option for the
unqiue local prefix discovered in Step 2
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-side Configuration
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify advertised unique local prefix includes A bit and L bit based on LAN settings |
ula.tcl |
ula_3 |
Verify advertised unique local prefix includes A bit and L bit based on LAN settings |
step 1. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 2. Verify at least one Router Advertisement contains a valid unique
local prefix that matches the expected unique local prefix
configured using the testvar ipv6LanUlaPrefix
step 3. Verify that the unique local prefix discovered in Step 2 contains
a valid lifetime
step 4. Check the autonomous address-configuration flag (A bit) in the
Router Advertisement received in Step 1
step 5. If the DUT is configured to provide global addresses via DHCPv6 on
the LAN, the A bit should not be set; if autoconfiguration is used
instead, the A bit should be set
step 6. Verify that the prefix discovered in Step 2 has the on-link flag
(L bit) set
NOTE: This test is designed to work with DUT's that support only a single
LAN mode for address autoconfiguration, either DHCPv6 or autoconf.
DUT configurations in which both modes are enabled simultaneously
(where the 'A' and 'M' bits are both set) are not currently supported
by this test.
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" Section 4.6.2: Prefix Information
https://tools.ietf.org/html/rfc4861#section-4.6.2
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to Neighbor Solicitations for its IPv6 unique local address |
ula.tcl |
ula_4 |
Verify DUT responds to Neighbor Solicitations for its IPv6 unique local address |
step 1. Send a Neighbor Solicitation on the LAN for the DUT's IPv6 unique
local address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify fields of Neighbor Advertisement
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify that DUT does not advertise unique local prefixes on the WAN |
ula.tcl |
ula_5 |
Verify that DUT does not advertise unique local prefixes on the WAN |
step 1. Send a Router Solicitation from the WAN
step 2. Wait to see if DUT sends a Router Advertisement on the WAN
step 3. Verify that Router Advertisement does not contain any unique local
prefixes
NOTE: The testvar ipv6ExpectRAonWan determines if this test should expect to
see Router Advertisements from the DUT on the WAN.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"
https://tools.ietf.org/html/rfc4861
| Test |
Module |
Name |
Synopsis |
Verify unique local prefix is advertised when WAN link is down |
ula.tcl |
ula_10 |
Verify unique local prefix is advertised when WAN link is down |
step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
server and wait for the current IA_NA and/or IA_PD bindings to
expire.
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
Information option with a Valid Lifetime greater than 0 for the
expected unique local prefix
step 3. Restore all services on the WAN and wait for the WAN link to be
re-established by the DUT
step 4. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify Route Information option for unique local prefix is valid when WAN link is down |
ula.tcl |
ula_11 |
Verify Route Information option for unique local prefix is valid when WAN link is down |
step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
server and wait for the current IA_NA and/or IA_PD bindings to
expire.
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT sends RAs on the LAN that contain both a Prefix
Information with a Valid Lifetime greater than 0 and a Route
Information option for the expected unique local prefix
step 3. Restore all services on the WAN and wait for the WAN link to be
re-established by the DUT
step 4. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify DUT does not advertise itself as a default router when WAN link is down |
ula.tcl |
ula_12 |
Verify DUT does not advertise itself as a default router when WAN link is down |
step 1. Bring down WAN link. For PPPoE WAN modes actively terminate the WAN
link with a PPP LCP Terminate message. For DHCPv6 WAN modes or WAN
modes where DHCPv6 prefix delegation is enabled, disable the DHCPv6
server and wait for the current IA_NA and/or IA_PD bindings to
expire.
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT eventually stops advertising itself as a default
router by setting the Router Lifetime in LAN RAs to a value of 0
while still sending valid Prefix Information option for the expected
unique local prefix
step 4. Restore all services on the WAN and wait for the WAN link to be
re-established by the DUT
step 5. Verify that the DUT starts advertising itself as a default router by
setting the Router Lifetime in LAN RAs to a value greater than 0
step 6. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the expected
unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify unique local prefix is advertised when WAN RA lifetime is 0 |
ula.tcl |
ula_13 |
Verify unique local prefix is advertised when WAN RA lifetime is 0 |
step 1. Send Router Advertisements on the WAN with a Router
Lifetime of 0
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
Information and with a Valid Lifetime greater than 0 for the
expected unique local prefix
step 4. Restore original Router Lifetime on WAN and start sending Router
Advertisements on the WAN with a non-zero Router Lifetime
step 5. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it
originates [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify Route Information option for unique local prefix is valid when WAN RA lifetime is 0 |
ula.tcl |
ula_14 |
Verify Route Information option for unique local prefix is valid when WAN RA lifetime is 0 |
step 1. Send Router Advertisements on the WAN with a Router
Lifetime of 0
step 2. Listen for RAs from the DUT on the LAN for up to the [WAN RA
lifetime + 1 LAN RA interval] or the [LAN RA interval + 1 LAN RA
interval] (whichever is greater)
step 3. Verify that the DUT sends RAs on the LAN that contain a Prefix
Information and with a Valid Lifetime greater than 0 for the
expected unique local prefix
step 4. Verify that the DUT sends RAs on the LAN that contain a Route
Information and with a Route Lifetime greater than 0 for the
expected unique local prefix
step 5. Restore original Router Lifetime on WAN and start sending Router
Advertisements on the WAN with a non-zero Router Lifetime
step 6. Wait for the duration of the dhcpv6PDLatency testvar and perform a
connectivity check to ensure that the WAN link is operational
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it
originates [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to its IPv6 unique local address from LAN |
ula.tcl |
ula_20 |
Verify DUT responds to ICMPv6 Echo Requests to its IPv6 unique local address from LAN |
step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's IPv6 unique
local address
step 2. Verify ICMPv6 Echo Reply is received
step 3. Verify the IPv6 source address is a unique local address
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a unique local prefix |
ula.tcl |
ula_21 |
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a unique local prefix |
step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the LAN client's
unique local address
step 2. Verify ICMPv6 Echo Reply is received
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ICMPv6 Echo Requests to the All Nodes group from a unique local IPv6 address |
ula.tcl |
ula_22 |
Verify DUT responds to ICMPv6 Echo Requests to the All Nodes group from a unique local IPv6 address |
step 1. Send an ICMPv6 Echo Request from the LAN client's unique local
address to the All-Nodes Multicast group (ff02::1)
step 2. Wait for an ICMPv6 Echo Response
step 3. Verify the Echo Response is from the DUT
step 4. Continue waiting until the DUT responds, or timeout
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
| Test |
Module |
Name |
Synopsis |
Verify packets with IPv6 unique local source addresses are not forwarded to the WAN |
ula.tcl |
ula_30 |
Verify packets with IPv6 unique local source addresses are not forwarded to the WAN |
step 1. Force the LAN client to transmit using its IPv6 unique local address
step 2. Forward an IPv6 packet from the LAN client to the IPv6 remote host
on the WAN
step 3. Verify the packet is not forwarded
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify packets with IPv6 unique local destination addresses are not forwarded to the WAN |
ula.tcl |
ula_31 |
Verify packets with IPv6 unique local destination addresses are not forwarded to the WAN |
step 1. Force the LAN client to transmit using its IPv6 global address
step 2. Create a new IPv6 host on the WAN with only unique local address
step 3. Forward an IPv6 packet from the LAN client to the new IPv6 host on
the WAN
step 4. Verify the packet is not forwarded
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify packets with IPv6 unique local source addresses are not forwarded to the LAN |
ula.tcl |
ula_32 |
Verify packets with IPv6 unique local source addresses are not forwarded to the LAN |
step 1. Create a new IPv6 host on the WAN with only unique local address
step 2. Forward an IPv6 packet from the new host on the WAN to the LAN
client using the LAN client's global address as the destination
address
step 3. Verify the packet is not forwarded
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Verify packets with IPv6 unique local destination addresses are not forwarded to the LAN |
ula.tcl |
ula_33 |
Verify packets with IPv6 unique local destination addresses are not forwarded to the LAN |
step 1. Set the IPv6 remote host on the WAN to send using its global address
step 2. Forward an IPv6 packet from the new host on the WAN to the LAN
client using the LAN client's unique local address as the destination
address
step 3. Verify the packet is not forwarded
References:
IETF RFC 4193 "Unique Local IPv6 Unicast Addresses"
https://tools.ietf.org/html/rfc4193
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
https://tools.ietf.org/html/rfc7084#section-4.3
static-v6.tcl
IPv6 static route related tests
| Test |
Module |
Name |
Synopsis |
Verify all LAN IPv6 static routes with LAN side traffic only |
static-v6.tcl |
static_v6_1 |
Verify all LAN IPv6 static routes with LAN side traffic only |
step 1. Find all configured IPv6 static routes with next hops on the LAN interface
step 2. Create new gateways for each next hop on the LAN
step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
step 4. Verify that the host in the static route reponds with ICMPv6 Echo Reply
NOTE: When configuring static routes on the CPE device, CDRouter expects
that the next hop or gateway address is not contained within any LAN-side
DHCPv6 address pools. CDRouter will create a new host for each next hop
address.
| Test |
Module |
Name |
Synopsis |
Verify all LAN IPv6 static routes with LAN to WAN traffic |
static-v6.tcl |
static_v6_2 |
Verify all LAN IPv6 static routes with LAN to WAN traffic |
step 1. Find all configured IPv6 static routes with next hops on the LAN interface
step 2. Create new gateways for each nexthop on the LAN
step 3. Send ICMPv6 Echo Request from host in static route network to the WAN side remoteHost
step 4. Verify that the remoteHost on the WAN receives the ICMPv6 Echo Request
step 5. Verify the WAN host ICMPv6 Echo Reply is received by the host in static route network
NOTE: When configuring static routes on the CPE device, CDRouter expects
that the next hop or gateway address is not contained within any LAN-side
DHCPv6 address pools. CDRouter will create a new host for each next hop
address.
| Test |
Module |
Name |
Synopsis |
Verify all WAN IPv6 static routes |
static-v6.tcl |
static_v6_10 |
Verify all WAN IPv6 static routes |
step 1. Find all configured IPv6 static routes with next hops on the WAN interface
step 2. Create new gateways for each next hop on the WAN if not the ipv6WanIspIp
step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
step 4. Verify that the host in the static route receives the ICMPv6 Echo Request
| Test |
Module |
Name |
Synopsis |
Verify all WAN IPv6 static routes after WAN ISP address change |
static-v6.tcl |
static_v6_20 |
Verify all WAN IPv6 static routes after WAN ISP address change |
step 1. Find all configured IPv6 static routes with next hops on the WAN interface
step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
step 3. Send ICMPv6 Echo Request to a host within the static route from the LAN host
step 4. Verify that the host in the static route reponds with ICMPv6 Echo Reply
NOTE: This test is intended to test static routes that are configured on the CPE
device by specifying a next hop address of "Wan" instead of a specific IPv6 address.
Most CPEs allow this type of static route configuration since the actual next hop will
not be known during configuration when running a dynamic WAN protocol such as PPPoE,
PPTP, L2TP, or DHCP.
NOTE: This test is only run when the WAN protocol is dynamic.
cpe-v6.tcl
Tests to verify requirements in RFC 7084
| Test |
Module |
Name |
Synopsis |
RA Prefix Information Option L-flag, L-flag=0 without Default Router |
cpe-v6.tcl |
cpe_v6_1 |
RA Prefix Information Option L-flag, L-flag=0 without Default Router |
Purpose: Verify that the DUT properly processes the L-flag of the Prefix
Information Option in the RA.
Procedure:
step 1. Reboot the DUT.
step 2. TR1 transmits a Router Advertisement on the WAN network. The Router
lifetime is set to 0 and the L-Flag in the Prefix Information Option
is set to 0.
step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must not forward the Echo Request to the WAN.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
https://tools.ietf.org/html/rfc7084#section-4.2
IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules
https://tools.ietf.org/html/rfc5942#section-4
| Test |
Module |
Name |
Synopsis |
RA Prefix Information Option L-flag, L-flag=1 without Default Router |
cpe-v6.tcl |
cpe_v6_2 |
RA Prefix Information Option L-flag, L-flag=1 without Default Router |
Purpose: Verify that the DUT properly processes the L-flag of the Prefix
Information Option in the RA.
Procedure:
step 1. Reboot the DUT.
step 2. TR1 transmits a Router Advertisement on the WAN network. The Router
lifetime is set to 0 and the L-Flag in the Prefix Information Option
is set to 1.
step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must forward the Echo Request to the WAN using REF-Node1
as the next hop.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
https://tools.ietf.org/html/rfc7084#section-4.2
IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules
https://tools.ietf.org/html/rfc5942#section-4
| Test |
Module |
Name |
Synopsis |
RA Prefix Information Option L-flag, L-flag=0 with Default Router |
cpe-v6.tcl |
cpe_v6_3 |
RA Prefix Information Option L-flag, L-flag=0 with Default Router |
Purpose: Verify that the DUT properly processes the L-flag of the Prefix
Information Option in the RA.
Procedure:
step 1. Reboot the DUT.
step 2. TR1 transmits RA1 on the WAN network. The L-flag is set to 0.
step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must forward the Echo Request to the WAN using TR1 as the
next hop.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.8: L Flag Processing
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
RA Prefix Information Option L-flag, L-flag=1 with Default Router |
cpe-v6.tcl |
cpe_v6_4 |
RA Prefix Information Option L-flag, L-flag=1 with Default Router |
Purpose: Verify that the DUT properly processes the L-flag of the Prefix
Information Option in the RA.
Procedure:
step 1. Reboot the DUT.
step 2. TR1 transmits a Router Advertisement on the WAN network.
The L-flag in the Prefix Information Option is set to 1.
step 3. TAR-Host1 Transmits an Echo Request to REF-Node1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must forward the Echo Request to the WAN using REF-Node1
as the next hop.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
https://tools.ietf.org/html/rfc7084#section-4.2
IETF RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" Section 4: Host Rules
https://tools.ietf.org/html/rfc5942#section-4
| Test |
Module |
Name |
Synopsis |
DHCPv6 Required Options |
cpe-v6.tcl |
cpe_v6_5 |
DHCPv6 Required Options |
Purpose: Verify an IPv6 CE Router properly implements the required DHCPv6
Options.
Procedure:
step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
step 2. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must transmit a DHCPv6 Solicit message including a
Reconfigure Accept Option and Option Request Option. The option
request option must include the DNS_SERVERS Option and SHOULD
contain the DNS Search List option. DHCP-Server1 sends a DHCPv6
Advertisement message with the IPv6 address information included.
DUT sends a DHCPv6 Request messages to confirm the IPv6 address and
ask for additional information. DHCP-Server1 responds with a DHCPv6
Reply message that contains the confirmed address.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
WAA-4: The IPv6 CE router MUST be able to support the following
DHCPv6 options: Identity Association for Non-temporary
Address (IA_NA), Reconfigure Accept [RFC3315], and
DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to
support the DNS Search List (DNSSL) option as specified in
[RFC3646].
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
RA M-flag is Set |
cpe-v6.tcl |
cpe_v6_6 |
RA M-flag is Set |
Purpose: Verify an IPv6 CE Router properly process the M flag in Router
Advertisement.
Procedure:
step 1. Reboot the DUT.
step 2. In response to Router Solicitations from the DUT, TR1
transmits a Router Advertisement with the M-flag set to 1.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must transmit a DHCPv6 Solicit message containing an
IA_NA Option.
References:
IPv6 Ready CE Router Conformance Test Specification, Rev 1.0.3: Test CERouterInterop.1.6.4: M Flag Processing
https://ipv6ready.org/docs/IPv6_Ready_Test_Specification_CE_Router_Conformance.pdf
| Test |
Module |
Name |
Synopsis |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=0 |
cpe-v6.tcl |
cpe_v6_7 |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=0 |
Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
determining initiating DHCPv6 Prefix Delegation.
Procedure:
step 1. Reboot the DUT.
step 2. In response to Router Solicitations from the DUT, TR1
transmits a Router Advertisement with the M-flag set to 1 and the
O-flag set to 0.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must transmit a DHCPv6 Solicit message containing an
IA_PD Option.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5F: DHCPv6 Prefix Delegation, M Flag
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=1 |
cpe-v6.tcl |
cpe_v6_8 |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=1 |
Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
determining initiating DHCPv6 Prefix Delegation.
Procedure:
step 1. Reboot the DUT.
step 2. In response to Router Solicitations from the DUT, TR1
transmits a Router Advertisement with the M-flag set to 0 and the
O-flag set to 1.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must transmit a DHCPv6 Solicit message containing an
IA_PD Option.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5G: DHCPv6 Prefix Delegation, O Flag
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=1 |
cpe-v6.tcl |
cpe_v6_9 |
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=1 |
Purpose: Verify an IPv6 CE Router properly handles the M and O flag for
determining initiating DHCPv6 Prefix Delegation.
Procedure:
step 1. Reboot the DUT.
step 2. In response to Router Solicitations from the DUT, TR1
transmits a Router Advertisement with the M-flag set to 1 and the
O-flag set to 1.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must transmit a DHCPv6 Solicit message containing an
IA_PD Option.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix
delegation when either the M or O flags are set to 1 in a
received Router Advertisement (RA) message. Behavior of the
CE router to use DHCPv6 prefix delegation when the CE router
has not received any RA or received an RA with the M and the
O bits set to zero is out of scope for this document.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
No Global Address is Configured |
cpe-v6.tcl |
cpe_v6_10 |
No Global Address is Configured |
Purpose: Verify an IPv6 CE Router properly follows the weak host model
when no suitable scope exists for a source address on the WAN
interface.
Procedure:
step 1. Reboot the DUT.
step 2. In response to Router Solicitations from the DUT, TR1
transmits a Router Advertisement with the M-flag set to 0 and the
A-flag in the prefix set to 0 so that no global address is assigned
to the DUT on the WAN.
step 3. Observe the packets transmitted on the WAN.
step 4. REF-Host1 transmits an IPv6 packet to TAR-Host1 with a hop-limit of
2.
step 5. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
transmits a valid DHCPv6 Advertise Message to DUT. DUT
transmits a valid DHCPv6 Request Message. DHCP-Server1 transmits a
valid Reply message to DUT.
step 4. DUT must transmit an ICMPv6 Time Exceeded message using the
global source address acquired on the LAN interface to REF-Host1.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.6: Unnumbered WAN
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Different DHCPv6 Prefix Size from Hint |
cpe-v6.tcl |
cpe_v6_11 |
Different DHCPv6 Prefix Size from Hint |
Purpose: Verify that the DUT properly supports prefix delegation and accepts
a different delegated prefix length from its hint.
Procedure:
step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
step 2. Observe the packets transmitted on the WAN.
step 3. If the DUT includes a prefix hint, configure DHCP-Server1 to
assign a different prefix length than the prefix hint supplied in
the DHCPv6 Solicit message from the DUT.
step 3. Wait for timer T1 (50s) to expire.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
transmits a valid DHCPv6 Advertise Message to DUT. DUT
transmits a valid DHCPv6 Request Message. DHCP-Server1 transmits a
valid DHCPv6 Reply message to DUT.
step 4. The DUT transmits a valid DHCPv6 Renew Message including IA_PD
option and IA_PD Prefix option and the value within these two
options must be the same as given in the DHCPv6 Reply message in
step 2.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.1.5: DHCPv6 Prefix Delegation
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Prevent Forwarding Loops |
cpe-v6.tcl |
cpe_v6_12 |
Prevent Forwarding Loops |
Purpose: Verify an IPv6 CE Router properly prevents routing loops by
discarding packets that match aggregate routes in the delegated
prefixes.
Procedure:
step 1. Configure DHCP-Server1 to delegate a prefixes larger than DUT can
delegate.
step 2. Allow the DUT's DHCPv6 Lease to expire on the WAN.
step 3. Observe the packets transmitted on the WAN.
step 4. TAR-Host1 transmits ICMPv6 Echo Request to an address that was not
assigned to a LAN interface on the DUT.
step 5. Observe the packets transmitted on the WAN.
step 6. REF-Host1 transmits ICMPv6 Echo Request to an address that was
not assigned to a LAN interface on the DUT.
step 7. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT transmits a valid DHCPv6 Solicit Message. DHCP-Server1
transmits a valid DHCPv6 Advertise Message to DUT. DUT
transmits a valid DHCPv6 Request Message. DHCP-Server transmits a
valid DHCPv6 Reply message to DUT.
step 5. The DUT must not forward the ICMPv6 Echo Request to
TAR-Router1. The DUT should transmit an ICMPv6 Destination
Unreachable message to TAR-Host1.
step 7. The DUT must not forward the ICMPv6 Echo Request to the LAN.
The DUT should transmit an ICMPv6 Destination Unreachable message
to REF-Host1.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.3.4: Forwarding Loops
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /64 |
cpe-v6.tcl |
cpe_v6_13 |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /64 |
Purpose: Verify an IPv6 CE Router properly assigns address from prefix
delegation to LAN interfaces.
Procedure:
step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
and assign addresses to the LAN side hosts. The prefix length is 64.
step 4. Observe the packets transmitted on the LAN.
step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
step 6. Observe the packets transmitted on the LAN.
step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
step 8. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit an RA including a PIO with PF1/64
and non-zero lifetimes.
step 6. The DUT must reply to the Echo Request.
step 8. The DUT must forward the Echo Request to REF-Host1.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.2A: Assigning Prefixes to LAN Interfaces, Prefix Length of /64
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /48 |
cpe-v6.tcl |
cpe_v6_14 |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /48 |
Purpose: Verify that the DUT assigns /64 addresses from prefix delegation to
the LAN interfaces.
Procedure:
step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
and assign addresses to the LAN side hosts. The prefix length is 48.
step 4. Observe the packets transmitted on the LAN.
step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
step 6. Observe the packets transmitted on the LAN.
step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
step 8. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit an RA including a PIO with PF1/64
and non-zero lifetimes.
step 6. The DUT must reply to the Echo Request.
step 8. The DUT must forward the Echo Request to REF-Host1.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /56 |
cpe-v6.tcl |
cpe_v6_15 |
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /56 |
Purpose: Verify an IPv6 CE Router properly assigns address from prefix
delegation to LAN interfaces.
Procedure:
step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
and assign addresses to the LAN side hosts. The prefix length is 56.
step 4. Observe the packets transmitted on the LAN.
step 5. TAR-Host1 transmits an Echo Request to the DUT's LAN address.
step 6. Observe the packets transmitted on the LAN.
step 7. TAR-Host1 transmits an Echo Request to REF-Host1.
step 8. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit an RA including a PIO with PF1/64
and non-zero lifetimes.
step 6. The DUT must reply to the Echo Request.
step 8. The DUT must forward the Echo Request to REF-Host1.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.2B: Assigning Prefixes to LAN Interfaces, Prefix Length of /56
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
RA Route Information Option, Having WAN Connectivity |
cpe-v6.tcl |
cpe_v6_16 |
RA Route Information Option, Having WAN Connectivity |
Purpose: Verify an IPv6 CE Router advertises itself as a router for
delegated prefixes.
Procedure:
step 1. Configure DHCP-Server1 to assign a /60 prefix through Prefix
Delegation.
step 1. Allow the DUT's DHCPv6 Lease to expire on the WAN.
step 3. Observe the packets transmitted on the WAN.
step 4. Observe the packets transmitted on the LAN.
step 5. REF-Host1 transmits an ICMPv6 Echo Request to TAR-Host1's global
address.
step 6. Observe the packets transmitted on the LAN and WAN.
Observable Results:
step 3. The DUT transmits a valid DHCP Solicit Message. DHCP-Server1
transmits a valid DHCP Advertise Message to DUT. The DUT
transmits a valid DHCP Request Message. DHCP-Server1 transmits a
valid DHCP Reply message to DUT.
step 4: The DUT transmits a Router Advertisement containing the Route
Information Option containing a delegated prefix. The Prefix Length
and Route Lifetime must match the information supplied from DHCPv6
Prefix Delegation.
step 6: TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
with ICMPv6 Echo Replies.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3A: Router Advertisement, Route Information Option
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
RA Route Information Option, Without WAN Connectivity |
cpe-v6.tcl |
cpe_v6_17 |
RA Route Information Option, Without WAN Connectivity |
Purpose: Verify that the DUT advertises itself as a router for the delegated
prefix using the Route Information Option and the advertising is
independent of having or not IPv6 connectivity on WAN.
Procedure:
step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire.
step 2. Wait for the DUT to perform DHCPv6 to obtain a new IA_PD lease
and assign addresses to the LAN side hosts. The prefix length is
60. The IA_PD lifetime is three times that of the IA_NA lifetime.
step 3. TAR-Host1 transmits a Router Solicitation. Observe the packets
transmitted on the LAN.
step 4. Disable the DUT's connection on the WAN network.
step 5. Wait for the DUT's IA_NA lifetime to expire.
step 6. TAR-Host1 transmits a Router Solicitation. Observe the packets
transmitted on the LAN.
Observable Results:
step 3. The DUT must transmit an RA with a Route Information option for PF1.
The Prefix, Prefix Length and Route Lifetime must match the
information supplied from DHCPv6 Prefix Delegation.
step 6. The DUT must transmit an RA with a Route Information option for PF1.
The Prefix, Prefix Length and Route Lifetime must match the
information supplied from DHCPv6 Prefix Delegation.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
No Prefixes Delegated |
cpe-v6.tcl |
cpe_v6_18 |
No Prefixes Delegated |
Purpose: Verify an IPv6 CE Router advertises itself as a router for
delegated prefixes.
eure:
step 1. Configure DHCP-Server1 to not assign IA_PD.
step 2. Reboot the DUT.
step 3. Observe the packets transmitted on the LAN and WAN.
Observable Results:
step 3. The DUT must not transmit Router Advertisements with a router
lifetime greater zero on the LAN.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3B: Router Advertisement, No Prefixes
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
No Prefixes Delegated, Delegated Prefix Expired |
cpe-v6.tcl |
cpe_v6_19 |
No Prefixes Delegated, Delegated Prefix Expired |
Purpose: Verify that the DUT does not advertise itself as a default router
if its delegated prefix has expired.
Procedure:
step 1. Wait for the DUT to perform the DHCPv6-PD process.
step 2. TAR-Host1 transmits a Router Solicitation to the all-routers
address.
step 3. Observe the packets transmitted on the LAN.
step 4. Wait for delegated prefix to expire.
step 5. TAR-Host1 transmits RS1 to the all-routers address.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 3. The DUT must transmit an RA with router lifetime greater than 0 in
response to the Router Solicitation.
step 6. The DUT must not transmit an RA with Router Lifetime greater than
0 in response to the Router Solicitation.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.3: LAN-Side Configuration
L-4: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime [RFC4861] greater than zero if
it has no prefixes configured or delegated to it.
https://tools.ietf.org/html/rfc7084#section-4.3
| Test |
Module |
Name |
Synopsis |
Router Advertisement, Advertising Interface |
cpe-v6.tcl |
cpe_v6_20 |
Router Advertisement, Advertising Interface |
Purpose: Verify an IPv6 CE Router advertises itself as a router for
delegated prefixes.
Procedure:
step 1. TAR-Host1 transmits RS1 to the all-routers address.
step 2. Observe the packets transmitted on the LAN.
Observable Results:
step 2. The DUT must transmit a Router Advertisement. The Prefix
Information Option A and L flags must be set to one.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.3C: Router Advertisement, Advertising Interface
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Delegated Prefix Change |
cpe-v6.tcl |
cpe_v6_21 |
Delegated Prefix Change |
Purpose: Verify that the DUT properly advertises RA when the delegated
prefix changed.
Procedure:
step 1. Allow time for the DUT's DHCPv6 IA_PD lease to expire and
restart DHCPv6 to be assigned Prefix X with a preferred and valid lifetime of 1 minute.
step 2. Allow time for DUT to distribute the Prefix X on LAN
interfaces.
step 3. REF-Host1 transmits ICMPv6 Echo Request to TAR-Host1's Prefix X
global address.
step 4. Observe the packets transmitted on the LAN and WAN.
step 5. Configure DHCP-Server1 to remove Prefix X from the available
Prefixes. Configure Prefix Y to be available for DUT.
step 6. Wait for DUT to transmit a DHCPv6 Renew for Prefix X.
step 7. Observe the packets transmitted on the LAN and WAN.
step 8. Wait for the valid lifetime of Prefix X to timeout.
step 9. Assign REF-Host2 a global address using Prefix X from step 2.
step 10. REF-Host1 transmits ICMPv6 Echo Request to Prefix Y global address
of TAR-Host1.
step 11. Observe the packets transmitted on the LAN and WAN.
step 12. REF-Host2 transmits ICMPv6 Echo Request from Prefix X global
address from Step 9 to REF-Host1.
step 13. Observe the packets transmitted on the LAN and WAN.
Observable Results:
step 4: TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
with ICMPv6 Echo Replies.
step 7: The DUT transmits a valid DHCPv6 Renew message. DHCP-Server1
transmits a valid DHCP Reply message with a new IPv6 prefix from
Step 5 on the WAN. The DUT must transmit Router Advertisements with
a Prefix Information Option containing a preferred lifetime of zero
for all prefixes previous delegated on the LAN. The valid lifetime of
the Prefix Option must not be greater then the value advertised in
the IA_PD. Future DHCPv6 Renew messages from the DUT must NOT
include the old IPv6 prefix.
step 11: TAR-Host1 must respond to all ICMPv6 Echo Requests from REF-Host1
with ICMPv6 Echo Replies.
step 13: The DUT must not forward ICMPv6 Echo Request from REF-Host2.
The DUT must transmit an ICMPv6 Destination Unreachable message
with a code 5 to REF-Host2.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.2.6A: Prefix Change, Prefix Timeout
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Default Source Address Selection, Prefer Appropriate Scope |
cpe-v6.tcl |
cpe_v6_22 |
Default Source Address Selection, Prefer Appropriate Scope |
Purpose: Verify that the DUT properly selects a source address of the
appropriate scope when originating IPv6 traffic.
Procedure:
step 1. Ref-Host1 transmits an Echo Request to an address on the DUT's LAN
network.
The Hop Limit of the Echo Request is set to 2.
step 2. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must transmit a Time Exceeded message with a global source
address.
References:
IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection
Rule 2: Prefer appropriate scope.
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
https://tools.ietf.org/html/rfc6724#section-5
| Test |
Module |
Name |
Synopsis |
Default Source Address Selection, Avoid Deprecated Addresses |
cpe-v6.tcl |
cpe_v6_23 |
Default Source Address Selection, Avoid Deprecated Addresses |
Purpose: Verify that the DUT properly selects default source address.
Procedure:
step 1. TAR-Router1 transmits RA1 on the WAN network. RA1 contains Prefix 1
with valid lifetime set to 60 and preferred lifetime set to 20. It
also contains Prefix 2 with the valid and preferred lifetimes set
to 60.
step 2. Wait 20 seconds.
step 3. REFHost1 transmits an Echo Request to an address on the DUT's LAN
network. The Hop Limit of the Echo Request is set to 2.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 5. The DUT must transmit a Time Exceeded message with Prefix 2 as the
source address.
References:
IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection
Rule 3: Avoid deprecated addresses.
If one of the two source addresses is "preferred" and one of them is
"deprecated" (in the RFC 4862 sense), then prefer the one that is
"preferred".
https://tools.ietf.org/html/rfc6724#section-5
| Test |
Module |
Name |
Synopsis |
Default Source Address Selection, Use Longest Matching Prefix |
cpe-v6.tcl |
cpe_v6_24 |
Default Source Address Selection, Use Longest Matching Prefix |
Purpose: Verify that the DUT properly selects default source address.
Procedure:
step 1. TR1 transmits an RA on the WAN network. The RA contains two
prefixes, Prefix 1 and Prefix 2, that have only the first 56 bits
in common. The preferred and valid lifetimes last the entire test.
step 2. Allow the DUT time to bind both addresses.
step 3. REFHost1 transmits an Echo Request to an address on the DUT's LAN
network. The Hop Limit of the Echo Request is set to 2. REFHost1's
source address matches only the first 60 bits of Prefix 2.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must transmit a Time Exceeded message with its Prefix 2
address as the source address.
References:
IETF RFC 6704 "Default Address Selection for Internet Protocol Version 6 (IPv6)" Section 5: Source Address Selection
Rule 8: Use longest matching prefix.
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
prefer SB.
https://tools.ietf.org/html/rfc6724#section-5
| Test |
Module |
Name |
Synopsis |
Default Router Lost |
cpe-v6.tcl |
cpe_v6_25 |
Default Router Lost |
Purpose: Verify an IPv6 CE Router does not advertise itself as a default
route on LAN interfaces when no default route exists on the WAN
interface.
Procedure:
step 1. Configure TAR-Router1 to transmit Router Advertisement with a
Router Lifetime of 600.
step 2. Observe the packets transmitted on the LAN.
step 3. REF-Host1 transmits ICMPv6 Echo Request to TAR-Host1.
step 4. Observe the packets transmitted on the LAN.
step 5. Configure TAR-Router1 to transmit Router Advertisement with a
Router Lifetime of 0.
step 6. Observe the packets transmitted on the LAN.
step 7. REF-Host1 transmits ICMPv6 Echo Request to DUT.
step 8. Observe the packets transmitted on the WAN.
Observable Results:
step 2: The DUT must transmit a Router Advertisements with a Router
Lifetime greater than zero.
step 4: TAR-Host1 must transmit an ICMPv6 Echo Replies to REF-Host1.
step 6: The DUT must immediately transmit Router Advertisements with a
Router Lifetime with a lifetime of zero.
step 8: The DUT must not transmit an ICMPv6 Echo Reply to REF-Host1.
References:
IPv6 Ready CE Router Interoperability Test Specification, Rev 1.0.3: Test CERouterInterop.3.3B: No Default Route, Loses Default Route
https://ipv6ready.org/docs/IPv6_Ready_Specification_CE_Router_Interoperability.pdf
| Test |
Module |
Name |
Synopsis |
Forwarding before address acquisition - DHCPv6 Leases Expired |
cpe-v6.tcl |
cpe_v6_26 |
Forwarding before address acquisition - DHCPv6 Leases Expired |
Purpose: Verify an IPv6 CE Router does not forward traffic between its WAN
and LAN interfaces before it has completed address acquisition on
the WAN
Procedure:
step 1. Wait for the DUT's DHCPv6 leases to expire on the WAN.
step 2. Send an Echo Request from TAR-Host1 to REF-Host1.
step 3. Observe the traffic on the WAN.
step 4. Allow the DUT to acquire new DHCPv6 leases on the WAN.
step 5. Send an Echo Request from TAR-Host1 to REF-Host1.
step 6. Observe the packets transmitted on the WAN.
Observable Results:
step 3: The DUT must not forward the Echo Request to the WAN.
step 6: The DUT must forward the Echo Request to the WAN.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
its LAN interface(s) and its WAN interface until the router has
successfully completed the IPv6 address and the delegated
prefix acquisition process.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
Forwarding before address acquisition - Reboot |
cpe-v6.tcl |
cpe_v6_27 |
Forwarding before address acquisition - Reboot |
Purpose: Verify an IPv6 CE Router does not forward traffic between its WAN
and LAN interfaces before it has completed address acquisition on
the WAN
Procedure:
step 1. Disable the DHCPv6 Server on the WAN.
step 2. Reboot the DUT.
step 3. After receiving the first Solicit on the WAN, send traffic from
TAR-Host1 to REF-Host1.
step 4. Observe the traffic on the WAN.
step 5. Wait for the DUT to retransmit a Solicit message and complete
DHCPv6.
step 6. Observe the packets transmitted on the WAN.
Observable Results:
step 3: The DUT must not forward any traffic to the WAN,
step 6. The DUT must forward the Echo Requests to the LAN after it completes
DHCPv6.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
its LAN interface(s) and its WAN interface until the router has
successfully completed the IPv6 address and the delegated
prefix acquisition process.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
No Default Router |
cpe-v6.tcl |
cpe_v6_28 |
No Default Router |
Purpose: Verify an IPv6 CE Router does not advertise itself as a default
route on LAN interfaces when no default route exists on the WAN
interface.
Procedure:
step 1. Reboot the DUT.
step 2. Configure TAR-Router1 to transmit Router Advertisement with a
Router Lifetime of 0.
step 3. Observe the packets transmitted on the LAN.
step 4. REF-Host1 transmits ICMPv6 Echo Request to the DUT's WAN address.
step 5. Observe the packets transmitted on the WAN.
Observable Results:
step 3: The DUT must not transmit a Router Advertisement with a Router
Lifetime greater than zero.
step 5. The DUT must not transmit an ICMPv6 Echo Reply to REF-Host1.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.1: General Requirements
G-4: By default, an IPv6 CE router that has no default
router(s) on its WAN interface MUST NOT advertise itself as an IPv6
default router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it originates
[RFC4861].
https://tools.ietf.org/html/rfc7084#section-4.1
| Test |
Module |
Name |
Synopsis |
IPv6 Host on WAN |
cpe-v6.tcl |
cpe_v6_29 |
IPv6 Host on WAN |
Purpose: Verify that the DUT acts as an IPv6 Host on its WAN interface.
Procedure:
step 1. Wait for the DUT to send a DHCPv6 Renew message to learn the DUT's
link-local address.
step 2. Reboot the DUT.
step 3. Observe the traffic on the WAN.
step 4. TR1 transmits a Router Solicitation on the WAN.
step 5. Observe the traffic on the WAN.
Observable Results:
step 3: The DUT must acquire a global IPv6 address on the WAN via stateless
or stateful address assignment. The DUT must not transmit a Router
Advertisement on the WAN.
step 5. The DUT must not transmit a Router Advertisement on the WAN in
response to the Router Solicitation.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
W-1: When the router is attached to the WAN interface link, it MUST
act as an IPv6 host for the purposes of stateless [RFC4862] or
stateful [RFC3315] interface address assignment.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
Duplicate Address Detection before Router Discovery |
cpe-v6.tcl |
cpe_v6_30 |
Duplicate Address Detection before Router Discovery |
Purpose: Verify that the DUT completes Duplicate Address Detection before
performing Router Discovery
Procedure:
step 1. Wait for the DUT to send a DHCPv6 Renew message to learn the DUT's
link-local address.
step 2. Reboot the DUT.
step 3. Observe the traffic on the WAN.
step 4. Send an ICMPv6 Echo Request from TAR-Host1 to REF-Host1.
step 5. Observe the traffic on the WAN.
Observable Results:
step 3: The DUT must complete Duplicate Address Detection for its
link-local address before it sends a Router Solicitation message
on the WAN. The Router Solicitation must have a source address equal
to the DUT's link-local address.
step 5. The DUT must forward the Echo Request to TAR-Router1, indicating
that it installed a default route.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
W-2: The IPv6 CE router MUST generate a link-local address and
finish Duplicate Address Detection according to [RFC4862] prior
to sending any Router Solicitations on the interface. The
source address used in the subsequent Router Solicitation MUST
be the link-local address on the WAN interface.
W-3: Absent other routing information, the IPv6 CE router MUST use
Router Discovery as specified in [RFC4861] to discover a
default router(s) and install a default route(s) in its routing
table with the discovered router's address as the next hop.
https://tools.ietf.org/html/rfc7084#section-4.2
| Test |
Module |
Name |
Synopsis |
Persistent DUID |
cpe-v6.tcl |
cpe_v6_31 |
Persistent DUID |
Purpose: Verify that the DUT uses a persistent DUID for DHCPv6 Messages
Procedure:
step 1. Wait for the DUT to send a DHCPv6 message on the WAN and record the
DUID.
step 2. Reboot the DUT.
step 3. Observe the traffic on the WAN.
Observable Results:
step 3: The DUT must send a DHCPv6 Solicit that includes an IA_PD option
with a DUID that matches the DUID in step 1.
References:
IETF RFC 7084 "IPv6 CE Router Requirements" Section 4.2: WAN-Side Configuration
W-4: The router MUST act as a requesting router for the purposes of
DHCPv6 prefix delegation ([RFC3633]).
W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier
(DUID) for DHCPv6 messages. The DUID MUST NOT change between
network-interface resets or IPv6 CE router reboots.
https://tools.ietf.org/html/rfc7084#section-4.2
sip-v6.tcl
SIP over IPv6 testing
| Test |
Module |
Name |
Synopsis |
Verify SIPv6 registration |
sip-v6.tcl |
ipv6_sip_1 |
Verify SIPv6 registration |
step 1. Send a REGISTER from LAN client to SIP proxy on WAN
step 2. Verify the LAN client's registration is successful
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify SIPv6 registration with short format SIP headers |
sip-v6.tcl |
ipv6_sip_2 |
Verify SIPv6 registration with short format SIP headers |
step 1. Configure the SIP client and server to use short
header formats
step 2. Send a REGISTER from LAN client to SIP proxy on WAN
step 3. Verify the LAN client's registration is successful
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIPv6 outbound call |
sip-v6.tcl |
ipv6_sip_10 |
Verify SIPv6 outbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify the outbound call is successful
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify short format SIP headers during outbound SIPv6 call |
sip-v6.tcl |
ipv6_sip_11 |
Verify short format SIP headers during outbound SIPv6 call |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Verify the outbound call is successful
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIPv6 inbound call |
sip-v6.tcl |
ipv6_sip_20 |
Verify SIPv6 inbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call to LAN side SIP destination
step 3. Verify the inbound call is successful
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify short format SIP headers during inbound SIPv6 call |
sip-v6.tcl |
ipv6_sip_21 |
Verify short format SIP headers during inbound SIPv6 call |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an inbound call to LAN side SIP destination
step 4. Verify the inbound call is successful
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIPv6 calls with multiple DHCP LAN clients |
sip-v6.tcl |
ipv6_sip_200 |
Verify outbound SIPv6 calls with multiple DHCP LAN clients |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the
testvar 'sipMaxOutboundCalls'. It defaults to 10.
By default, the SIP server and client use port 5060. The SIP
server port may be configured using the testvar sipScaleServerPort.
The sipScaleClientPort testvar may be used to configure a specific
SIP client source port for the clients. The value of unique may
also be specified to dynamically allocate the SIP client port.
Example:
testvar sipScaleServerPort 10001
testvar sipScaleClientPort unique
For this testing scenario, the pace of the RTP stream is slowed down
to allow fewer RTP packets per stream. The actual RTP send interval
can be configured using the testvar 'rtpSendInterval'. This is the
interval between each RTP packet in milliseconds. The default value is
5000 milliseconds. If this is increased to a larger value, changing the
value of 'sipScaleRunTime' should also be increased. This controls the
duration must be long enough to allow each RTP stream to send and
receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIPv6 calls with multiple DHCP LAN clients without registering a port |
sip-v6.tcl |
ipv6_sip_201 |
Verify outbound SIPv6 calls with multiple DHCP LAN clients without registering a port |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the
testvar 'sipMaxOutboundCalls'. It defaults to 10.
By default, the SIP server and client use port 5060. The SIP
server port may be configured using the testvar sipScaleServerPort.
The sipScaleClientPort testvar may be used to configure a specific
SIP client source port for the clients. The value of unique may
also be specified to dynamically allocate the SIP client port.
Example:
testvar sipScaleServerPort 10001
testvar sipScaleClientPort unique
For this testing scenario, the pace of the RTP stream is slowed down
to allow fewer RTP packets per stream. The actual RTP send interval
can be configured using the testvar 'rtpSendInterval'. This is the
interval between each RTP packet in milliseconds. The default value is
5000 milliseconds. If this is increased to a larger value, changing the
value of 'sipScaleRunTime' should also be increased. This controls the
duration must be long enough to allow each RTP stream to send and
receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) |
sip-v6.tcl |
ipv6_sip_300 |
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the
testvar 'sipMaxOutboundCalls'. It defaults to 10.
By default, the SIP server and client use port 5060. The SIP
server port may be configured using the testvar sipScaleServerPort.
The sipScaleClientPort testvar may be used to configure a specific
SIP client source port for the clients. The value of unique may
also be specified to dynamically allocate the SIP client port.
Example:
testvar sipScaleServerPort 10001
testvar sipScaleClientPort unique
For this testing scenario, the pace of the RTP stream is slowed down
to allow fewer RTP packets per stream. The actual RTP send interval
can be configured using the testvar 'rtpSendInterval'. This is the
interval between each RTP packet in milliseconds. The default value is
5000 milliseconds. The call duration can be changed using the testvar
'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) without registering a port |
sip-v6.tcl |
ipv6_sip_301 |
Verify outbound SIPv6 calls with multiple DHCP LAN clients (TCP) without registering a port |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the
testvar 'sipMaxOutboundCalls'. It defaults to 10.
This test will start the SIP server and SIP clients on the default
port of 5060.
For this testing scenario, the pace of the RTP stream is slowed down
to allow fewer RTP packets per stream. The actual RTP send interval
can be configured using the testvar 'rtpSendInterval'. This is the
interval between each RTP packet in milliseconds. The default value is
5000 milliseconds. The call duration can be changed using the testvar
'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
triggerp-v6.tcl
Tests to verify configured IPv6 trigger ports on the router
| Test |
Module |
Name |
Synopsis |
Verify basic case for each configured IPv6 trigger port application |
triggerp-v6.tcl |
ipv6_tport_10 |
Verify basic case for each configured IPv6 trigger port application |
step 1. Read all the configured trigger ports
step 2. For each port, verify that none of the public triggered ports
are currently open on the WAN side.
step 3. Initiate a TCP or UDP session from the LAN to the WAN side
using the triggered port as the destination port.
step 4. Verify the TCP or UDP session is created
step 5. For each public port that should now be triggered, open
a connection from the WAN to the LAN using the public
port as the destination port and the router's nat IP address
as the destination IP address
step 5. Verify a connection can be estabished for each public port
step 6. Close down each public port
step 7. Close down the original LAN side connection used for the trigger
step 8. Repeat for each configured port trigger
NOTE: Up to 4096 trigger ports can be configured in your configuration
file. For example,
testvar triggerName1 net2phone-1
testvar triggerAddrType1 ipv6
testvar triggerPort1 6801
testvar triggerType1 udp
testvar triggerPublic1 30000
testvar triggerPublicType1 both
testvar triggerName2 app1
testvar triggerAddrType2 ipv6
testvar triggerPort2 20000
testvar triggerType2 udp
testvar triggerPublic2 20001-20010
testvar triggerPublicType2 udp
NOTE: Many routers will not time out the triggered port connection once
it is open. This will cause this test to fail if it is executed more
than once.
The PublicType may be either "tcp", "udp", or "both". If "both" is used,
the test case will verify both a TCP and UDP connection for each port
in the Public range.
A delay can be configured between each trigger port. This is sometimes
required for port trigger implementations using Smart ALGs. To configure
the delay, configure the testvar 'portTriggerDelay' with the number of
milliseconds.
A delay can also be configured before a trigger port is verified as being
open with WAN to LAN traffic. This is sometimes required for
implemenatations that have a delay associated with processing the outbound
trigger packet. To configure the delay, configure the testvar
'portTriggerOpenDelay' with the number of milliseconds.
Examples:
testvar portTriggerDelay 5000
testvar portTriggerOpenDelay 1000
| Test |
Module |
Name |
Synopsis |
Verify multiple LAN hosts can use IPv6 trigger ports after mappings are aged out |
triggerp-v6.tcl |
ipv6_tport_30 |
Verify multiple LAN hosts can use IPv6 trigger ports after mappings are aged out |
step 1. Read all the configured trigger ports
step 2. Create a second DHCP LAN client
step 3. Initiate a TCP or UDP session from the LAN to the WAN side
using the triggered port as the destination port
step 4. Verify the TCP or UDP session is created
step 5. For each public port that should now be triggered, open
a connection from the WAN to the LAN using the public
port as the destination port and the router's nat IP address
as the destination IP address.
step 6. Verify a connection can be estabished for each public port
step 7. Close down each public port
step 8. Close down the original LAN side connection used for the trigger
step 9. Wait for port mappings to be aged out
step 10. Repeat from step 2. using the second LAN client
step 11. Repeat for each configured port trigger
NOTE: The port mapping aging time for trigger ports is configured
using the portTriggerTimeout variable in your config file. Your
router must support the aging of trigger ports in order to run this
test.
NOTE: Up to 4096 trigger ports can be configured in your configuration
file. For example,
testvar triggerName1 net2phone-1
testvar triggerAddrType1 ipv6
testvar triggerPort1 6801
testvar triggerType1 udp
testvar triggerPublic1 30000
testvar triggerPublicType1 both
NOTE: Many routers will not time out the triggered port connection once
it is open. This will cause this test to fail if it is executed more
than once.
The PublicType may be either tcp, udp, or both. If "both" is used,
the test case will verify both a TCP and UDP connection for each port
in the Public range.
A delay can be configured between each trigger port. This is sometimes
required for port trigger implementations using Smart ALGs. To configure
the delay, configure the testvar 'portTriggerDelay' with the number of
milliseconds.
A delay can also be configured before a trigger port is verified as being
open with WAN to LAN traffic. This is sometimes required for
implemenatations that have a delay associated with processing the outbound
trigger packet. To configure the delay, configure the testvar
'portTriggerOpenDelay' with the number of milliseconds.
Examples:
testvar portTriggerDelay 5000
testvar portTriggerOpenDelay 1000
rfc6092.tcl
IETF RFC 6092 simple security in IPv6 gateway CPE tests
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-1 |
rfc6092.tcl |
rfc6092_rec_1 |
Section 3.1: Stateless filters, REC-1 |
step 1. Forward a packet with a node-local multicast source address from LAN to WAN
step 2. Verify packet in Step 1 is not forwarded to the WAN
step 3. Repeat steps 1 and 2 with a site-local multicast source address
step 4. Repeat steps 1 and 2 with a global multicast source address
step 5. Forward a packet with a node-local multicast source address from WAN to LAN
step 6. Verify packet in Step 3 is not forwarded to the LAN
step 7. Repeat steps 5 and 6 with a site-local multicast source address
step 8. Repeat steps 5 and 6 with a global multicast source address
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-1: Packets bearing multicast source addresses in their outer IPv6
headers MUST NOT be forwarded or transmitted on any interface.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-2 |
rfc6092.tcl |
rfc6092_rec_2 |
Section 3.1: Stateless filters, REC-2 |
step 1. Forward a packet with a node-local multicast destination
address from WAN to LAN
step 2. Verify packet in Step 1 is not forwarded to the LAN
step 3. Forward a packet with a node-local multicast destination
address from LAN to WAN
step 4. Verify packet in Step 3 is not forwarded to the WAN
step 5. Repeat steps 1-4 with a link-local multicast destination
address
step 6. Repeat steps 1-4 with a site-local multicast destination
address
step 7. Repeat steps 1-4 with a organization-local multicast
destination address
References:
IETF RFC 2464 "Transmission of IPv6 Packets over Ethernet Networks" Section 7: Address Mapping -- Multicast
An IPv6 packet with a multicast destination address DST, consisting
of the sixteen octets DST[1] through DST[16], is transmitted to the
Ethernet multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets of
DST.
https://tools.ietf.org/html/rfc2464#section-7
IETF RFC 6085 "Address Mapping of IPv6 Multicast Packets on Ethernet" Section 3: Receiving IPv6 Multicast Packets
An IPv6 node receiving an IPv6 packet with a multicast destination
address and an Ethernet link-layer unicast address MUST NOT drop the
packet as a result of the use of this form of address mapping.
https://tools.ietf.org/html/rfc6085#section-3
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-2: Packets bearing multicast destination addresses in their outer
IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
Architecture" [RFC4007]) than the configured scope boundary level of
the gateway MUST NOT be forwarded in any direction. The DEFAULT
scope boundary level SHOULD be organization-local scope, and it
SHOULD be configurable by the network administrator.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-3 |
rfc6092.tcl |
rfc6092_rec_3 |
Section 3.1: Stateless filters, REC-3 |
step 1. Forward a packet with a non-routable source address from LAN to WAN
step 2. Verify packet in Step 1 is not forwarded to the WAN
step 3. Forward a packet with a non-routable destination address from LAN to
WAN
step 4. Verify packet in Step 3 is not forwarded to the WAN
step 5. Repeat steps 1 through 4 for various well known non-routable
addresses
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-3: Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the public
Internet MUST NOT be forwarded. In particular, site-local addresses
are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible
Addresses, Documentation Prefix, and Overlay Routable Cryptographic
Hash IDentifiers (ORCHID).
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-4 |
rfc6092.tcl |
rfc6092_rec_4 |
Section 3.1: Stateless filters, REC-4 |
step 1. Forward a packet with routing extension header type 0 from LAN to
WAN
step 2. Verify packet in Step 1 is not forwarded to the WAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-4: Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or
transmitted on any interface. In particular, all packets with
routing extension header type 0 [RFC2460] preceding the first upper-
layer-protocol header MUST NOT be forwarded. See [RFC5095] for
additional background.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-5 |
rfc6092.tcl |
rfc6092_rec_5 |
Section 3.1: Stateless filters, REC-5 |
step 1. Create a new LAN client
step 2. Assign a global prefix to the LAN client that is different
from the one belonging to the LAN
step 3. Send traffic to the WAN from the martian source address
step 4. Verify traffic is not forwarded
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-5: Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix configured
for use by globally reachable nodes on the interior network.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-6 |
rfc6092.tcl |
rfc6092_rec_6 |
Section 3.1: Stateless filters, REC-6 |
step 1. Create a new stack on the remoteHost
step 2. Assign the stack the same global prefix as is used on the LAN
step 3. Send traffic to the LAN from the remote stack
step 4. Verify traffic is NOT forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-6: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use
by globally reachable nodes on the interior network.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-7 |
rfc6092.tcl |
rfc6092_rec_7 |
Section 3.1: Stateless filters, REC-7 |
step 1. Send traffic from the LAN to the WAN with a unique-local source address
step 2. Verify traffic is not forwarded to the WAN
step 3. Initiate a new UDP session with the device to allow inbound traffic
step 4. Configure a new stack on the WAN with a unique-local prefix as the source
step 5. Send traffic from this new stack to the LAN
step 6. Verify traffic is not forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-7: By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or from
the exterior network.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-8 |
rfc6092.tcl |
rfc6092_rec_8 |
Section 3.1: Stateless filters, REC-8 |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT's
global IPv6 address
step 2. Verify that the query is received by either the primary or backup
DNS server on the WAN
step 3. Verify that the DNS response is received by the LAN client
step 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to the
DUT's global IPv6 address
step 5. Verify that a DNS response is not received by the remote host on the
WAN that initiated the original request
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-8: By DEFAULT, inbound DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS resolving
server.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.1: Stateless filters, REC-9 |
rfc6092.tcl |
rfc6092_rec_9 |
Section 3.1: Stateless filters, REC-9 |
step 1. Start new DHCPv6 client on WAN interface
step 2. Verify new client does not obtain an IPv6 address via DHCPv6 from
the DUT
step 3. Send three pings from LAN to WAN to verify that the DUT is still
operating properly
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.1: Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved
prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the
public Internet.
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
exterior interfaces MUST NOT be processed by any integrated DHCPv6
server or relay agent.
https://tools.ietf.org/html/rfc6092#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.2.1: Internet Control and Management, REC-10 |
rfc6092.tcl |
rfc6092_rec_10 |
Section 3.2.1: Internet Control and Management, REC-10 |
step 1. Send UDP message from LAN client to WAN server
step 2. Verify UDP message is received by WAN server
step 3. Send ICMPv6 Destination Unreachable message from WAN
server to LAN client containing a different UDP port than
the UDP message sent by the LAN client in step 1.
step 4. Verify the DUT does not forward the ICMPv6 message to the
LAN client
step 5. Repeat steps 3 and 4 with an ICMPv6 Packet Too Big
message
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.1: Internet Control and Management
Recommendations for filtering ICMPv6 messages in firewall devices are
described separately in [RFC4890] and apply to residential gateways,
with the additional recommendation that incoming "Destination
Unreachable" and "Packet Too Big" error messages that don't match any
filtering state should be dropped.
REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
Unreachable" and "Packet Too Big" messages containing IP headers that
do not match generic upper-layer transport state records.
https://tools.ietf.org/html/rfc6092#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Section 3.2.2: Upper Layer Transport Protocols, REC-12 |
rfc6092.tcl |
rfc6092_rec_12 |
Section 3.2.2: Upper Layer Transport Protocols, REC-12 |
step 1. Initiate LAN client UDP ping to WAN server
step 2. Verify LAN client receives response
step 3. Wait 115 seconds
step 4. Initiate WAN client UDP ping on same connection as step 1
from WAN side
step 5. Verify WAN client receives a response
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.2: Upper Layer Transport Protocols
Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be
treated consistently, i.e., as having connection-free semantics and
no special requirements to inspect the transport headers.
In general, upper-layer transport filter state records are expected
to be created when an interior endpoint sends a packet to an exterior
address. The filter allocates (or reuses) a record for the duration
of communications, with an idle timer to delete the state record when
no further communications are detected.
One key aspect of how a packet filter behaves is the way it evaluates
the exterior address of an endpoint when applying a filtering rule.
A gateway is said to have "endpoint-independent filtering" behavior
when the exterior address is not evaluated when matching a packet
with a flow. A gateway is said to have "address-dependent filtering"
behavior when the exterior address of a packet is required to match
the exterior address for its flow.
REC-12: Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a packet
matching the state in some configurable amount of time. By DEFAULT,
the idle timer for such state records is five minutes.
https://tools.ietf.org/html/rfc6092#section-3.2.2
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-14 |
rfc6092.tcl |
rfc6092_rec_14 |
Section 3.2.3: UDP Filters, REC-14 |
step 1. Initiate LAN client UDP ping to WAN server
step 2. Verify LAN client receives response
step 3. Wait natUdpTimeout - 10 seconds
step 4. Send UDP ping on same connection from WAN side
step 5. Verify WAN client receives response
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
"Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP" [RFC4787] defines the terminology and best current
practice for stateful filtering of UDP applications in IPv4 with NAT,
which serves as the model for behavioral requirements for simple UDP
security in IPv6 gateways, notwithstanding the requirements related
specifically to network address translation.
An interior endpoint initiates a UDP flow through a stateful packet
filter by sending a packet to an exterior address. The filter
allocates (or reuses) a filter state record for the duration of the
flow. The state record defines the interior and exterior IP
addresses and ports used between all packets in the flow.
State records for UDP flows remain active while they are in use and
are only abandoned after an idle period of some time.
REC-14: A state record for a UDP flow where both source and
destination ports are outside the well-known port range
(ports 0-1023) MUST NOT expire in less than two minutes of idle time.
The value of the UDP state record idle timer MAY be configurable.
The DEFAULT is five minutes.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-16 |
rfc6092.tcl |
rfc6092_rec_16 |
Section 3.2.3: UDP Filters, REC-16 |
step 1. Initiate a LAN client UDP ping to WAN server
step 2. Verify LAN client receives response
step 3. Wait natUdpTimeout/2 seconds
step 4. Initiate a LAN client UDP ping to WAN server
step 5. Verify LAN client receives a response
step 6. Wait natUdpTimeout - 10 seconds
step 7. Initiate a WAN server UDP ping to LAN client
step 8. Verify WAN server received a response
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
As [RFC4787] notes, outbound refresh is necessary for allowing the
interior endpoint to keep the state record alive. Inbound refresh
may be useful for applications with no outbound UDP traffic.
However, allowing inbound refresh can allow an attacker in the
exterior or a misbehaving application to keep a state record alive
indefinitely. This could be a security risk. Also, if the process
is repeated with different ports, over time, it could use up all the
state record memory and resources in the filter.
REC-16: A state record for a UDP flow MUST be refreshed when a packet
is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse direction.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-17 |
rfc6092.tcl |
rfc6092_rec_17 |
Section 3.2.3: UDP Filters, REC-17 |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Forward a packet back from the WAN to the same LAN client
step 3. Verify packet is received
For Full-Cone NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is forwarded to the LAN
step 6. Forward a packet using a different IPv6 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv6 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different IPv6 address and same source port
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using a different source port but same IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv6 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using the same source port and IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
As described in Section 5 of [RFC4787], the connection-free semantics
of UDP pose a difficulty for packet filters in trying to recognize
which packets comprise an application flow and which are unsolicited.
Various strategies have been used in IPv4/NAT gateways with differing
effects.
REC-17: If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint-independent filtering"
behavior for UDP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "address-dependent filtering"
behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering
behavior for TCP and other protocols. Filtering behavior SHOULD be
endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-18 |
rfc6092.tcl |
rfc6092_rec_18 |
Section 3.2.3: UDP Filters, REC-18 |
step 1. Send IPv6 UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
step 4. Send IPv6 UDP packet from LAN to WAN
step 5. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
step 6. Verify ICMPv6 Too Big message is received on the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
Application mechanisms may depend on the reception of ICMPv6 error
messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery [RFC1981].
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
UDP headers that match the flow state record.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-19 |
rfc6092.tcl |
rfc6092_rec_19 |
Section 3.2.3: UDP Filters, REC-19 |
step 1. Send IPv6 UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable message
step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since IPv6 firewall state is still present
step 6. Send IPv6 UDP packet from LAN to WAN
step 7. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big message
step 8. Verify ICMPv6 Too Big message is received on the LAN
step 9. Send UDP response from WAN to LAN
step 10. Verify UDP response is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
Application mechanisms may depend on the reception of ICMPv6 error
messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery [RFC1981].
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.3: UDP Filters, REC-20 |
rfc6092.tcl |
rfc6092_rec_20 |
Section 3.2.3: UDP Filters, REC-20 |
step 1. Forward UDP packet from LAN to WAN
step 2. Verify UDP packet in step 1 is forwarded to the WAN
step 3. Forward matching UDP-Lite packet from WAN to LAN
step 4. Verify UDP-Lite packet in step 3 is not forwarded to the
LAN
step 5. Forward UDP-Lite packet from LAN to WAN
step 6. Verify UDP-Lite packet in step 5 is forwarded to the WAN
step 7. Forward matching UDP packet from WAN to LAN
step 8. Verify UDP packet in step 7 is not forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.3: UDP Filters
Application mechanisms may depend on the reception of ICMPv6 error
messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery [RFC1981].
REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
UDP flows, except that the upper-layer transport protocol identifier
for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT
match UDP-Lite state records, and vice versa.
https://tools.ietf.org/html/rfc6092#section-3.2.3
| Test |
Module |
Name |
Synopsis |
Section 3.2.4: IPSec and Internet Key Exchange (IKE), REC-21 |
rfc6092.tcl |
rfc6092_rec_21 |
Section 3.2.4: IPSec and Internet Key Exchange (IKE), REC-21 |
step 1. Forward UDP packet with IPv6 Authentication Header from
LAN to WAN
step 2. Verify UDP packet is forwarded to the WAN
step 3. Forward UDP packet with IPv6 Authentication Header from
WAN to LAN
step 4. Verify UDP packet is forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.2.4: IPSec and Internet Key Exchange (IKE)
The Internet Protocol security (IPsec) suite offers greater
flexibility and better overall security than the simple security of
stateful packet filtering at network perimeters. Therefore,
residential IPv6 gateways need not prohibit IPsec traffic flows.
REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Authentication
Header (AH)" [RFC4302] in their outer IP extension header chain.
https://tools.ietf.org/html/rfc6092#section-3.2.4
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-31 |
rfc6092.tcl |
rfc6092_rec_31 |
Section 3.3.1: TCP Filters, REC-31 |
step 1. Initiate an outbound TCP session from LAN client to WAN
server
step 2. Verify session initiation is successful
step 3. Terminate TCP session from LAN side
step 4. Verify session is terminated successfully
NOTE: This test case only verifies that the normal TCP 3-way
handshake mode is supported.
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
An interior endpoint initiates a TCP flow through a stateful packet
filter by sending a SYN packet. The filter allocates (or reuses) a
filter state record for the flow. The state record defines the
interior and exterior IP addresses and ports used for forwarding all
packets for that flow.
Some peer-to-peer applications use an alternate method of connection
initiation termed "simultaneous-open" ([RFC0793], Figure 8) to
traverse stateful filters. In the simultaneous-open mode of
operation, both peers send SYN packets for the same TCP flow. The
SYN packets cross in the network. Upon receiving the other end's SYN
packet, each end responds with a SYN-ACK packet, which also cross in
the network. The connection is established at each endpoint once the
SYN-ACK packets are received.
To provide stateful packet filtering service for TCP, it is necessary
for a filter to receive, process, and forward all packets for a flow
that conform to valid transitions of the TCP state machine
([RFC0793], Figure 6).
REC-31: All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted inbound
flows. In particular, both the normal TCP 3-way handshake mode of
operation and the simultaneous-open mode of operation MUST be
supported.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-32 |
rfc6092.tcl |
rfc6092_rec_32 |
Section 3.3.1: TCP Filters, REC-32 |
step 1. Configure TCP LAN client and TCP WAN server to use a TCP
window size of 10 bytes
step 2. Configure LAN client and WAN server to be in an
established TCP session
step 3. Transmit 20 bytes of TCP data from LAN client to WAN
server
step 4. Verify WAN server receives 20 bytes of TCP data
step 5. Transmit 20 bytes of TCP data from WAN server to LAN
client
step 6. Verify LAN client receives 20 bytes of TCP data
step 7. Terminate TCP session from LAN side
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
It is possible to reconstruct enough of the state of a TCP flow to
allow forwarding between an interior and exterior node, even when the
filter starts operating after TCP enters the established state. In
this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments.
REC-32: The TCP window invariant MUST NOT be enforced on flows for
which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous-open.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-33 |
rfc6092.tcl |
rfc6092_rec_33 |
Section 3.3.1: TCP Filters, REC-33 |
step 1. Forward a TCP packet from a LAN client to the WAN
step 2. Forward a packet back from the WAN to the same LAN client
step 3. Verify packet is received
For Full-Cone NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is forwarded to the LAN
step 6. Forward a packet using a different IPv6 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv6 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different IPv6 address and same source port
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using a different source port but same IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv6 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using the same source port and IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
A stateful filter can allow an existing state record to be reused by
an externally initiated flow if its security policy permits. Several
different policies are possible, as described in [RFC4787] and
extended in [RFC5382].
REC-33: If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint-independent filtering"
behavior for TCP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "address-dependent filtering"
behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior SHOULD be
endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-34 |
rfc6092.tcl |
rfc6092_rec_34 |
Section 3.3.1: TCP Filters, REC-34 |
step 1. Initiate an unsolicited inbound TCP session from WAN
server to LAN client
step 2. Verify WAN server receives an ICMPv6 Destination
Unreachable message with error code 1
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
If an inbound SYN packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the SYN did
not reach the intended destination. Discarding the packet, on the
other hand, allows applications to perform simultaneous-open more
reliably. A more detailed discussion of this issue can be found in
[RFC5382], but the basic outcome of it is that filters need to wait
on signaling errors until simultaneous-open will not be impaired.
REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited) to any unsolicited inbound
SYN packet after waiting at least 6 seconds without first forwarding
the associated outbound SYN or SYN/ACK from the interior peer.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-35 |
rfc6092.tcl |
rfc6092_rec_35 |
Section 3.3.1: TCP Filters, REC-35 |
step 1. Initiate an outbound TCP session from LAN client to WAN
server
step 2. Verify session initiation is successful
step 3. Allow TCP session to idle for 2 hours
step 4. Transfer TCP data from WAN server to LAN client
step 5. Verify LAN client receives TCP data
step 6. Terminate TCP session from LAN side
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
A TCP filter maintains state associated with in-progress connections
and established flows. Because of this, a filter is susceptible to a
resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long
period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially flow state records for crashed endpoints,
followed by closed flows and partially open flows. A gateway can
check if an endpoint for a session has crashed by sending a TCP keep-
alive packet on behalf of the other endpoint and receiving a TCP RST
packet in response. If the gateway cannot determine whether the
endpoint is active, then the associated state record needs to be
retained until the TCP flow has been idle for some time.
Note: An established TCP flow can stay idle (but live)
indefinitely; hence, there is no fixed value for an idle-timeout
that accommodates all applications. However, a large idle-timeout
motivated by recommendations in [RFC1122] and [RFC4294] can reduce
the chances of abandoning a live flow.
TCP flows can stay in the established phase indefinitely without
exchanging packets. Some end-hosts can be configured to send keep-
alive packets on such idle flows; by default, such packets are sent
every two hours, if enabled [RFC1122]. Consequently, a filter that
waits for slightly over two hours can detect idle flows with keep-
alive packets being sent at the default rate. TCP flows in the
partially open or closing phases, on the other hand, can stay idle
for at most four minutes while waiting for in-flight packets to be
delivered [RFC1122].
The "established flow idle-timeout" for a stateful packet filter is
defined as the minimum time a TCP flow in the established phase must
remain idle before the filter considers the associated state record a
candidate for collection. The "transitory flow idle-timeout" for a
filter is defined as the minimum time a TCP flow in the partially
open or closing phases must remain idle before the filter considers
the associated state record a candidate for collection. TCP flows in
the TIME-WAIT state are not affected by the "transitory flow idle-
timeout" parameter.
REC-35: If a gateway cannot determine whether the endpoints of a TCP
flow are active, then it MAY abandon the state record if it has been
idle for some time. In such cases, the value of the "established
flow idle-timeout" MUST NOT be less than two hours four minutes, as
discussed in [RFC5382]. The value of the "transitory flow idle-
timeout" MUST NOT be less than four minutes. The value of the idle-
timeouts MAY be configurable by the network administrator.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-36 |
rfc6092.tcl |
rfc6092_rec_36 |
Section 3.3.1: TCP Filters, REC-36 |
step 1. Establish TCP connection from LAN to WAN
step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
step 3. Verify ICMPv6 Destination Unreachable message is received on the LAN
step 4. Send an ICMPv6 Packet Too Big message from the WAN for the connection
step 5. Verify ICMPv6 Packet Too Big message is received on the LAN
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
Behavior for handling RST packets or TCP flows in the TIME-WAIT state
is left unspecified. A gateway MAY hold state for a flow in the
TIME-WAIT state to accommodate retransmissions of the last ACK.
However, since the TIME-WAIT state is commonly encountered by
interior endpoints properly closing the TCP flow, holding state for a
closed flow can limit the throughput of flows through a gateway with
limited resources. [RFC1337] discusses hazards associated with
TIME-WAIT assassination.
The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the
gateway abandons a live flow, or abandons a flow in the TIME-WAIT
state before the four-minute TIME-WAIT period expires. The decision
either to discard or to respond with an ICMPv6 "Destination
Unreachable" error code 1 (Communication with destination
administratively prohibited) is left up to the implementation.
Behavior for notifying endpoints when abandoning live flows is left
unspecified. When a gateway abandons a live flow, for example due to
a timeout expiring, the filter MAY send a TCP RST packet to each
endpoint on behalf of the other. Sending a RST notification allows
endpoint applications to recover more quickly; however, notifying
endpoints might not always be possible if, for example, state records
are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct
operation of TCP.
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing
TCP headers that match the flow state record.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.1: TCP Filters, REC-37 |
rfc6092.tcl |
rfc6092_rec_37 |
Section 3.3.1: TCP Filters, REC-37 |
step 1. Establish TCP connection from LAN to WAN
step 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connection
step 3. Send TCP data segment from WAN to LAN for the session
step 4. Verify TCP data segment is received on LAN since IPv6 firewall state is still present
step 5. Send an ICMPv6 Packet Too Big message from the WAN for the connection
step 6. Send TCP data segment from WAN to LAN for the session
step 7. Verify TCP data segment is received on LAN since IPv6 firewall state is still present
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.1: TCP Filters
Behavior for handling RST packets or TCP flows in the TIME-WAIT state
is left unspecified. A gateway MAY hold state for a flow in the
TIME-WAIT state to accommodate retransmissions of the last ACK.
However, since the TIME-WAIT state is commonly encountered by
interior endpoints properly closing the TCP flow, holding state for a
closed flow can limit the throughput of flows through a gateway with
limited resources. [RFC1337] discusses hazards associated with
TIME-WAIT assassination.
The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the
gateway abandons a live flow, or abandons a flow in the TIME-WAIT
state before the four-minute TIME-WAIT period expires. The decision
either to discard or to respond with an ICMPv6 "Destination
Unreachable" error code 1 (Communication with destination
administratively prohibited) is left up to the implementation.
Behavior for notifying endpoints when abandoning live flows is left
unspecified. When a gateway abandons a live flow, for example due to
a timeout expiring, the filter MAY send a TCP RST packet to each
endpoint on behalf of the other. Sending a RST notification allows
endpoint applications to recover more quickly; however, notifying
endpoints might not always be possible if, for example, state records
are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct
operation of TCP.
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow.
https://tools.ietf.org/html/rfc6092#section-3.3.1
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-38 |
rfc6092.tcl |
rfc6092_rec_38 |
Section 3.3.2: SCTP Filters, REC-38 |
step 1. Initiate SCTP association from LAN client to WAN server
step 2. Verify association initiation is successful
step 3. Terminate SCTP association from LAN side
step 4. Verify association is terminated successful
NOTE: This test case only verifies that the normal SCTP
association establishment is supported.
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
can be terminated at multiple network addresses, IPv6 simple security
functions cannot achieve full transparency for SCTP applications. In
multipath traversal scenarios, full transparency requires
coordination between all the packet filter processes in the various
paths between the endpoint network addresses. Such coordination is
not "simple", and it is, therefore, beyond the scope of this
recommendation.
However, some SCTP applications are capable of tolerating the
inherent unipath restriction of IPv6 simple security, even in
multipath traversal scenarios. They expect connection-oriented
filtering behaviors similar to those for TCP, but at the level of
SCTP associations, not stream connections. This section describes
specific recommendations for SCTP filtering for such traversal
scenarios.
An interior endpoint initiates SCTP associations through a stateful
packet filter by sending a packet comprising a single INIT chunk.
The filter allocates (or reuses) a filter state record for the
association. The state record defines the interior and exterior IP
addresses and the observed verification tag used for forwarding
packets in that association.
Some peer-to-peer SCTP applications use an alternate method of
association initiation, termed "simultaneous-open", to traverse
stateful filters. In the simultaneous-open mode of operation, both
peers send INIT chunks at the same time to establish an association.
Upon receiving the other end's INIT chunk, each end responds with an
INIT-ACK packet, which is expected to traverse the same path in
reverse. Because only one SCTP association may exist between any two
network addresses, one of the peers in the simultaneous-open mode of
operation will send an ERROR or ABORT chunk along with the INIT-ACK
chunk. The association is established at each endpoint once an
INIT-ACK chunk without an ERROR or ABORT chunk is received at one
end.
To provide stateful packet filtering service for SCTP, it is
necessary for a filter to receive, process, and forward all packets
for an association that conform to valid transitions of the SCTP
state machine ([RFC4960], Figure 3).
REC-38: All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP
association establishment and the simultaneous-open mode of operation
MUST be supported.
https://tools.ietf.org/html/rfc6092#section-3.3.2
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-39 |
rfc6092.tcl |
rfc6092_rec_39 |
Section 3.3.2: SCTP Filters, REC-39 |
step 1. Initiate an unsolicited inbound SCTP association from WAN
client to LAN server
step 2. Verify WAN client receives ICMPv6 Destination Unreachable
message with error code 1
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
If an inbound INIT packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the INIT
packet did not reach the intended destination. Discarding the
packet, on the other hand, allows applications to perform
simultaneous-open more reliably. Delays in signaling errors can
prevent the impairment of the simultaneous-open mode of operation.
REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited), to any unsolicited inbound
INIT packet after waiting at least 6 seconds without first forwarding
the associated outbound INIT from the interior peer.
https://tools.ietf.org/html/rfc6092#section-3.3.2
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-40, Part A |
rfc6092.tcl |
rfc6092_rec_40a |
Section 3.3.2: SCTP Filters, REC-40, Part A |
step 1. Initiate an outbound SCTP association from LAN client to
WAN server
step 2. Verify association initiation is successful
step 3. Allow association to idle for 2 hours
step 4. Transmit SCTP data from WAN server to LAN client
step 5. Verify LAN client receives SCTP data
step 6. Terminate SCTP association from LAN client
step 7. Verify association is terminated successfully
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long
period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by
closed associations and partially opened associations. A similar
method is an option for SCTP filters in IPv6 gateways. A gateway can
check if an endpoint for an association has crashed by sending
HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the
gateway cannot determine whether the endpoint is active, then the
associated state record needs to be retained until the SCTP
association has been idle for some time.
Note: An established SCTP association can stay idle (but live)
indefinitely; hence, there is no fixed value of an idle-timeout
that accommodates all applications. However, a large idle-timeout
motivated by recommendations in [RFC4294] can reduce the chances
of abandoning a live association.
SCTP associations can stay in the ESTABLISHED state indefinitely
without exchanging packets. Some end-hosts can be configured to send
HEARTBEAT chunks on such idle associations, but [RFC4960] does not
specify (or even suggest) a default time interval. A filter that
waits for slightly over two hours can detect idle associations with
HEARTBEAT packets being sent at the same rate as most hosts use for
TCP keep-alive, which is a reasonably similar system for this
purpose. SCTP associations in the partially open or closing states,
on the other hand, can stay idle for at most four minutes while
waiting for in-flight packets to be delivered (assuming the suggested
SCTP protocol parameter values in Section 15 of [RFC4960]).
The "established association idle-timeout" for a stateful packet
filter is defined as the minimum time an SCTP association in the
established phase must remain idle before the filter considers the
corresponding state record a candidate for collection. The
"transitory association idle-timeout" for a filter is defined as the
minimum time an SCTP association in the partially open or closing
phases must remain idle before the filter considers the corresponding
state record a candidate for collection.
REC-40: If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record if
it has been idle for some time. In such cases, the value of the
"established association idle-timeout" MUST NOT be less than
two hours four minutes.
https://tools.ietf.org/html/rfc6092#section-3.3.2
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-40, Part B |
rfc6092.tcl |
rfc6092_rec_40b |
Section 3.3.2: SCTP Filters, REC-40, Part B |
step 1. Disable SCTP WAN server on port A
step 2. Initiate an outbound SCTP association from LAN client to
WAN server on port A
step 3. Wait 230 seconds
step 4. Enable SCTP WAN server on port A
step 5. Wait 5 seconds
step 6. Verify association initiation from step 2 is successful
step 7. Terminate SCTP association from LAN side
step 8. Verify association is terminated successful
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long
period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by
closed associations and partially opened associations. A similar
method is an option for SCTP filters in IPv6 gateways. A gateway can
check if an endpoint for an association has crashed by sending
HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the
gateway cannot determine whether the endpoint is active, then the
associated state record needs to be retained until the SCTP
association has been idle for some time.
Note: An established SCTP association can stay idle (but live)
indefinitely; hence, there is no fixed value of an idle-timeout
that accommodates all applications. However, a large idle-timeout
motivated by recommendations in [RFC4294] can reduce the chances
of abandoning a live association.
SCTP associations can stay in the ESTABLISHED state indefinitely
without exchanging packets. Some end-hosts can be configured to send
HEARTBEAT chunks on such idle associations, but [RFC4960] does not
specify (or even suggest) a default time interval. A filter that
waits for slightly over two hours can detect idle associations with
HEARTBEAT packets being sent at the same rate as most hosts use for
TCP keep-alive, which is a reasonably similar system for this
purpose. SCTP associations in the partially open or closing states,
on the other hand, can stay idle for at most four minutes while
waiting for in-flight packets to be delivered (assuming the suggested
SCTP protocol parameter values in Section 15 of [RFC4960]).
The "established association idle-timeout" for a stateful packet
filter is defined as the minimum time an SCTP association in the
established phase must remain idle before the filter considers the
corresponding state record a candidate for collection. The
"transitory association idle-timeout" for a filter is defined as the
minimum time an SCTP association in the partially open or closing
phases must remain idle before the filter considers the corresponding
state record a candidate for collection.
REC-40: If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record if
it has been idle for some time. In such cases, the value of the
"established association idle-timeout" MUST NOT be less than
two hours four minutes.
https://tools.ietf.org/html/rfc6092#section-3.3.2
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-41 |
rfc6092.tcl |
rfc6092_rec_41 |
Section 3.3.2: SCTP Filters, REC-41 |
step 1. Initiate an outbound SCTP association from LAN client to
WAN server
step 2. Verify association initiation is successful
step 3. Forward an ICMPv6 Destination Unreachable message from LAN
client to WAN server
step 4. Verify message is received by WAN server
step 5. Forward an ICMPv6 Destination Unreachable message from WAN
server to LAN client
step 6. Verify message is received by LAN client
step 7. Forward an ICMPv6 Packet Too Big message from LAN client
to WAN server
step 8. Verify message is received by WAN server
step 9. Forward an ICMPv6 Packet Too Big message from WAN server
to LAN client
step 10. Verify message is received by LAN client
step 11. Terminate SCTP association from LAN side
step 12. Verify association is terminated successful
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN
ACK packets. However, holding state for a closed association can
limit the throughput of associations traversing a gateway with
limited resources. The discussion in [RFC1337] regarding the hazards
of TIME-WAIT assassination is relevant.
The handling of inbound non-INIT packets for which there is no active
state record is left unspecified. Such packets can be received if
the gateway abandons a live flow, or abandons an association in the
closing states before the transitory association idle-timeout
expires. The decision either to discard or to respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited) is left to the
implementation.
Behavior for notifying endpoints when abandoning live associations is
left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT
notification allows endpoint applications to recover more quickly;
however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption.
Several SCTP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of SCTP packets.
REC-41: If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association state
record.
https://tools.ietf.org/html/rfc6092#section-3.3.2
| Test |
Module |
Name |
Synopsis |
Section 3.3.2: SCTP Filters, REC-42 |
rfc6092.tcl |
rfc6092_rec_42 |
Section 3.3.2: SCTP Filters, REC-42 |
step 1. Initiate an outbound SCTP association from LAN client to WAN
server
step 2. Verify association initiation is successful
step 3. Forward an ICMPv6 Destination Unreachable message from LAN
client to WAN server
step 4. Transmit SCTP data from WAN server to LAN client
step 5. Verify LAN client receives SCTP data
step 6. Verify SCTP association is still established
step 7. Forward an ICMPv6 Destination Unreachable message from WAN
server to LAN client
step 8. Transmit SCTP data from WAN server to LAN client
step 9. Verify LAN client receives SCTP data
step 10. Verify SCTP association is still established
step 11. Forward an ICMPv6 Packet Too Big message from LAN client
to WAN server
step 12. Transmit SCTP data from WAN server to LAN client
step 13. Verify LAN client receives SCTP data
step 14. Verify SCTP association is still established
step 15. Forward an ICMPv6 Packet Too Big message from WAN server
to LAN client
step 16. Transmit SCTP data from WAN server to LAN client
step 17. Verify LAN client receives SCTP data
step 18. Verify SCTP association is still established
step 19. Transmit SCTP data from WAN server to LAN client
step 20. Verify LAN client receives SCTP data
step 21. Verify SCTP association is still established
step 22. Terminate SCTP association from LAN side
step 23. Verify association is terminated successful
References:
IETF RFC 6092 "Simple Security in IPv6 Gateway CPE" Section 3.3.2: SCTP Filters
Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN
ACK packets. However, holding state for a closed association can
limit the throughput of associations traversing a gateway with
limited resources. The discussion in [RFC1337] regarding the hazards
of TIME-WAIT assassination is relevant.
The handling of inbound non-INIT packets for which there is no active
state record is left unspecified. Such packets can be received if
the gateway abandons a live flow, or abandons an association in the
closing states before the transitory association idle-timeout
expires. The decision either to discard or to respond with an ICMPv6
"Destination Unreachable" error code 1 (Communication with
destination administratively prohibited) is left to the
implementation.
Behavior for notifying endpoints when abandoning live associations is
left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT
notification allows endpoint applications to recover more quickly;
however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption.
Several SCTP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of SCTP packets.
REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association.
https://tools.ietf.org/html/rfc6092#section-3.3.2
rip-ng.tcl
RIPng tests for LAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify router sends RIPng update on LAN side |
rip-ng.tcl |
ipv6_ripng_1 |
Verify router sends RIPng update on LAN side |
step 1. Listen for RIPng reply from LAN side IP address of router
step 2. Verify RIPng version
step 3. Verify source address of RIPng reply
NOTE: This test is only run if the 'supportsRIPng' configuration
is set to 'yes'.
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.3: Timers
https://tools.ietf.org/html/rfc2080#section-2.3
| Test |
Module |
Name |
Synopsis |
Verify router learns new RIPng routes from LAN side RIPng router |
rip-ng.tcl |
ipv6_ripng_2 |
Verify router learns new RIPng routes from LAN side RIPng router |
step 1. Start new IPv6 client on LAN interface
step 2. Announce new RIPng route with metric 1 from new IPv6 client
step 3. Forward from original LAN client to IP address within the
new RIPng route range
step 4. Verify the packet is forwarded to the new IPv6 client
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages
https://tools.ietf.org/html/rfc2080#section-2.4.2
| Test |
Module |
Name |
Synopsis |
Verify router responds to RIPng requests on LAN interface |
rip-ng.tcl |
ipv6_ripng_5 |
Verify router responds to RIPng requests on LAN interface |
step 1. Send RIPng Request from new UDP src port to RIPng destination address
step 2. Verify router returns a RIPng response
step 3. Verify the response is sent to the correct UDP port
step 4. Verify the response is sent using unicast IP destination
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.4.1: Request Messages
https://tools.ietf.org/html/rfc2080#section-2.4.1
| Test |
Module |
Name |
Synopsis |
Verify router selects RIPng route with lowest metric |
rip-ng.tcl |
ipv6_ripng_10 |
Verify router selects RIPng route with lowest metric |
step 1. Start 2 new IPv6 clients on LAN interface (R1 and R2)
step 2. Announce new RIPng route with metric 10 from R1
step 3. Announce same RIPng route with metric 9 from R2
step 4. Forward from original LAN client to IP address within the
new RIng route range
step 5. Verify the packet is forwarded to R2
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages
https://tools.ietf.org/html/rfc2080#section-2.4.2
| Test |
Module |
Name |
Synopsis |
Verify router ignores routes with a metric of 16 |
rip-ng.tcl |
ipv6_ripng_12 |
Verify router ignores routes with a metric of 16 |
step 1. Start new IPv6 client on LAN interface
step 2. Announce new RIPng route with metric 16 from new IPv6 client
step 3. Forward from original LAN client to IP address within the
new RIPng route range
step 4. Verify the packet is not forwarded to the new IPv6 client
step 5. Verify the packet is forwarded to WAN side
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages
https://tools.ietf.org/html/rfc2080#section-2.4.2
| Test |
Module |
Name |
Synopsis |
Verify router uses split horizon or poison reverse for learned RIPng routes |
rip-ng.tcl |
ipv6_ripng_20 |
Verify router uses split horizon or poison reverse for learned RIPng routes |
step 1. Start new IPv6 client on LAN interface
step 2. Announce new RIPng route with metric 1 from new IPv6 client
step 3. Wait for new RIPng update
step 4. Verify route is not announced (split horizon) or announced as
unreachable (poison reverse)
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.5.2: Generating Response Messages
https://tools.ietf.org/html/rfc2080#section-2.5.2
| Test |
Module |
Name |
Synopsis |
Verify router announces default route on LAN side |
rip-ng.tcl |
ipv6_ripng_30 |
Verify router announces default route on LAN side |
step 1. Listen for RIPng updates for 1 minute
step 2. Verify default route (/0) is announced as reachable
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.2: Addressing Considerations
https://tools.ietf.org/html/rfc2080#section-2.2
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of RIPng routes supported |
rip-ng.tcl |
ipv6_ripng_100 |
Verify the maximum number of RIPng routes supported |
step 1. Start a new IPv6 client on LAN interface
step 2. Announce new RIPng routes with metric 1 from new IPv6 client
NOTE: The 'ripMaxRoutes' variable in your configuration file
determines the number of RIPng routes that are announced.
step 3. Forward from original LAN client to IP address within the
each new route range
step 4. Verify packets are forwarded for each new route
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.1: Message Format
https://tools.ietf.org/html/rfc2080#section-2.1
| Test |
Module |
Name |
Synopsis |
Verify router learns new RIPng routes from WAN side RIPng router |
rip-ng.tcl |
ipv6_ripng_200 |
Verify router learns new RIPng routes from WAN side RIPng router |
step 1. Announce new RIPng route with metric 1 from WAN side
step 2. Wait for new RIPng update on the LAN
step 3. Verify new route is announced on the LAN
step 4. Forward packet from LAN to new IP destination
step 5. Verify packet is forwarded to WAN side
NOTE: This test is only enabled when testvar ripAcceptWanUpdate
is set to yes. The default is no.
testvar ripAcceptWanUpdate yes
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages
https://tools.ietf.org/html/rfc2080#section-2.4.2
| Test |
Module |
Name |
Synopsis |
Verify router processes Next Hop RTEs in RIPng route list |
rip-ng.tcl |
ipv6_ripng_300 |
Verify router processes Next Hop RTEs in RIPng route list |
step 1. Start 2 new IPv6 clients on LAN interface (R1 and R2)
step 2. Announce new RIPng route with metric 1 from R1 whose next hop is R2.
step 3. Forward from original LAN client to IP address within the
new RIng route range
step 4. Verify the packet is forwarded to R2
References:
IETF RFC 2080 "RIPng for IPv6" Section 2.1.1: Next Hop
https://tools.ietf.org/html/rfc2080#section-2.1.1
mdns-v6.tcl
IPv6 mDNS related test cases
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to IPv6 mDNS query of its hostname |
mdns-v6.tcl |
ipv6_mdns_10 |
Verify DUT responds to IPv6 mDNS query of its hostname |
step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
AAAA record of the DUT's LAN hostname in the top-level
domain 'local'.
step 2. Verify the mDNS query succeeds and the response contains
the DUT's IPv6 LAN address.
NOTE: The DUT's expected LAN hostname is taken from the testvar
lanHostname.
References:
IETF RFC 6762 "Multicast DNS" Section 3: Multicast DNS Names
This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, namely that any fully
qualified name ending in ".local." is link-local, and names within
this domain are meaningful only on the link where they originate.
This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
addresses in the FE80::/10 prefix, which are link-local and
meaningful only on the link where they originate.
https://tools.ietf.org/html/rfc6762#section-3
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to IPv6 mDNS reverse query of its LAN IP |
mdns-v6.tcl |
ipv6_mdns_11 |
Verify DUT responds to IPv6 mDNS reverse query of its LAN IP |
step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
reverse mapping of the DUT's IPv6 link-local address.
step 2. Verify the mDNS query succeeds and the response contains
the DUT's IPv6 LAN hostname in the top-level domain
'local'.
NOTE: The DUT's expected LAN hostname is taken from the testvar
lanHostname.
References:
IETF RFC 6762 "Multicast DNS"
https://tools.ietf.org/html/rfc6762
| Test |
Module |
Name |
Synopsis |
Verify DUT returns DNS-Service Discovery records for its web server over IPv6 |
mdns-v6.tcl |
ipv6_mdns_12 |
Verify DUT returns DNS-Service Discovery records for its web server over IPv6 |
step 1. Initiate a one-shot IPv6 mDNS query from the LAN for the
DUT's _services._dns-sd._udp.local PTR record.
step 2. Verify that the mDNS query succeeds and the response
contains the _http._tcp.local domain.
step 3. Initiate a one-shot IPv6 mDNS query from the LAN for the
DUT's _http._tcp.local PTR record.
step 4. Verify that mDNS query succeeds.
step 5. Initiate a one-shot IPv6 mDNS query from the LAN for the
SRV record of the resource returned in step 4.
step 6. Verify that the mDNS query succeeds and the response
contains the DUT's management port and the domain
LANHOSTNAME.local.
step 7. Initiate a one-shot IPv6 mDNS query from the LAN for the
AAAA record of LANHOSTNAME.local.
step 8. Verify that the mDNS query succeeds and the response
contains the DUT's IPv6 LAN address.
step 9. Initiate an HTTP GET over IPv6 of the URL
http://LANHOSTNAME:dutMgmtPort from the LAN.
step 10. Verify that the HTTP GET succeeds.
NOTE: The value of LANHOSTNAME is taken from the value of the
lanHostname testvar.
NOTE: The value of the DUT's management port is taken from the
default insecure management port defined as the first port
in the value of testvar dutMgmtPort. Please read the
documentation for dutMgmtPort for more information about the
default insecure management port concept and its usage.
References:
IETF RFC 6762 "Multicast DNS" Section 3: Multicast DNS Names
This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, namely that any fully
qualified name ending in ".local." is link-local, and names within
this domain are meaningful only on the link where they originate.
This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
addresses in the FE80::/10 prefix, which are link-local and
meaningful only on the link where they originate.
https://tools.ietf.org/html/rfc6762#section-3
IETF RFC 6763 "DNS-Based Service Discovery"
https://tools.ietf.org/html/rfc6763
| Test |
Module |
Name |
Synopsis |
Verify DUT does not forward IPv6 LAN mDNS query onto the WAN |
mdns-v6.tcl |
ipv6_mdns_13 |
Verify DUT does not forward IPv6 LAN mDNS query onto the WAN |
step 1. Initiate a one-shot mDNS query from the LAN destined for
IPv6 link-local multicast address ff02::fb.
step 2. Verify that the mDNS query is not forwarded on the WAN.
References:
IETF RFC 3513 "Internet Protocol Version 6 (IPv6) Addressing Architecture" Section 2.7: Multicast Addresses
Routers must not forward any multicast packets beyond of the scope
indicated by the scop field in the destination multicast address.
https://tools.ietf.org/html/rfc3513#section-2.7
http-v6.tcl
IPv6 HTTP related test cases
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.0 GET connections |
http-v6.tcl |
ipv6_http_100 |
Verify IPv6 HTTP/1.0 GET connections |
step 1. Send an IPv6 HTTP/1.0 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.0 POST connections |
http-v6.tcl |
ipv6_http_101 |
Verify IPv6 HTTP/1.0 POST connections |
step 1. Send an IPv6 HTTP/1.0 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.0 HEAD connections |
http-v6.tcl |
ipv6_http_102 |
Verify IPv6 HTTP/1.0 HEAD connections |
step 1. Send an IPv6 HTTP/1.0 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.0 GET connections with large number of headers |
http-v6.tcl |
ipv6_http_103 |
Verify IPv6 HTTP/1.0 GET connections with large number of headers |
step 1. Send an IPv6 HTTP/1.0 GET request to the server with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 GET connections |
http-v6.tcl |
ipv6_http_200 |
Verify IPv6 HTTP/1.1 GET connections |
step 1. Send an IPv6 HTTP/1.1 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 POST connections |
http-v6.tcl |
ipv6_http_201 |
Verify IPv6 HTTP/1.1 POST connections |
step 1. Send an IPv6 HTTP/1.1 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 HEAD connections |
http-v6.tcl |
ipv6_http_202 |
Verify IPv6 HTTP/1.1 HEAD connections |
step 1. Send an IPv6 HTTP/1.1 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 PUT connections |
http-v6.tcl |
ipv6_http_203 |
Verify IPv6 HTTP/1.1 PUT connections |
step 1. Send an IPv6 HTTP/1.1 PUT request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 OPTIONS connections |
http-v6.tcl |
ipv6_http_204 |
Verify IPv6 HTTP/1.1 OPTIONS connections |
step 1. Send an IPv6 HTTP/1.1 OPTIONS request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 DELETE connections |
http-v6.tcl |
ipv6_http_205 |
Verify IPv6 HTTP/1.1 DELETE connections |
step 1. Send an IPv6 HTTP/1.1 DELETE request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 GET connections with large number of headers |
http-v6.tcl |
ipv6_http_206 |
Verify IPv6 HTTP/1.1 GET connections with large number of headers |
step 1. Send an IPv6 HTTP/1.1 GET request to the server with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 GET connections with chunked encoding |
http-v6.tcl |
ipv6_http_250 |
Verify IPv6 HTTP/1.1 GET connections with chunked encoding |
step 1. Send an IPv6 HTTP/1.1 GET request to server
step 2. Verify HTTP response with chunked encoding is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 proxy idle timeout |
http-v6.tcl |
ipv6_http_260 |
Verify IPv6 HTTP/1.1 proxy idle timeout |
step 1. Configure HTTP server to delay sending responses by the
time period specified by httpProxyIdleTimeout.
step 2. Send an IPv6 HTTP/1.1 GET request to server
step 3. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 5.5: Timeouts
https://tools.ietf.org/html/rfc6202#section-5.5
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 WebSocket Ping message |
http-v6.tcl |
ipv6_http_300 |
Verify IPv6 HTTP/1.1 WebSocket Ping message |
step 1. Send an IPv6 HTTP/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket Ping opcode (0x9)
step 4. Verify server side returns WebSocket Pong opcode (0xA)
step 5. Close the WebSocket server
References:
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTP/1.1 WebSocket Text message |
http-v6.tcl |
ipv6_http_301 |
Verify IPv6 HTTP/1.1 WebSocket Text message |
step 1. Send an IPv6 HTTP/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket data message with text
step 4. Verify server side echos back the same text data
step 5. Close the WebSocket server
References:
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
https-v6.tcl
IPv6 HTTPS related test cases
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.0 GET connections |
https-v6.tcl |
ipv6_https_100 |
Verify IPv6 HTTPS/1.0 GET connections |
step 1. Send an IPv6 HTTPS/1.0 GET request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.0 POST connections |
https-v6.tcl |
ipv6_https_101 |
Verify IPv6 HTTPS/1.0 POST connections |
step 1. Send an IPv6 HTTPS/1.0 POST request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.0 HEAD connections |
https-v6.tcl |
ipv6_https_102 |
Verify IPv6 HTTPS/1.0 HEAD connections |
step 1. Send an IPv6 HTTPS/1.0 HEAD request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.0 GET connections with large number of headers |
https-v6.tcl |
ipv6_https_103 |
Verify IPv6 HTTPS/1.0 GET connections with large number of headers |
step 1. Send a IPv6 HTTPS/1.0 GET request to the server with the maximum allowed headers
step 2. Verify the HTTPS response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 GET connections |
https-v6.tcl |
ipv6_https_200 |
Verify IPv6 HTTPS/1.1 GET connections |
step 1. Send an IPv6 HTTPS/1.1 GET request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 POST connections |
https-v6.tcl |
ipv6_https_201 |
Verify IPv6 HTTPS/1.1 POST connections |
step 1. Send an IPv6 HTTPS/1.1 POST request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 HEAD connections |
https-v6.tcl |
ipv6_https_202 |
Verify IPv6 HTTPS/1.1 HEAD connections |
step 1. Send an IPv6 HTTPS/1.1 HEAD request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 PUT connections |
https-v6.tcl |
ipv6_https_203 |
Verify IPv6 HTTPS/1.1 PUT connections |
step 1. Send an IPv6 HTTPS/1.1 PUT request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 OPTIONS connections |
https-v6.tcl |
ipv6_https_204 |
Verify IPv6 HTTPS/1.1 OPTIONS connections |
step 1. Send an IPv6 HTTPS/1.1 OPTIONS request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 DELETE connections |
https-v6.tcl |
ipv6_https_205 |
Verify IPv6 HTTPS/1.1 DELETE connections |
step 1. Send an IPv6 HTTPS/1.1 DELETE request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 GET connections with large number of headers |
https-v6.tcl |
ipv6_https_206 |
Verify IPv6 HTTPS/1.1 GET connections with large number of headers |
step 1. Send an IPv6 HTTPS/1.1 GET request to the server with the maximum allowed headers
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 GET connections with chunked encoding |
https-v6.tcl |
ipv6_https_250 |
Verify IPv6 HTTPS/1.1 GET connections with chunked encoding |
step 1. Send an IPv6 HTTPS/1.1 GET request to server
step 2. Verify HTTPS response with chunked encoding is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 WebSocket Ping message |
https-v6.tcl |
ipv6_https_300 |
Verify IPv6 HTTPS/1.1 WebSocket Ping message |
step 1. Send an IPv6 HTTPS/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket Ping opcode (0x9)
step 4. Verify server side returns WebSocket Pong opcode (0xA)
step 5. Close the WebSocket server
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
| Test |
Module |
Name |
Synopsis |
Verify IPv6 HTTPS/1.1 WebSocket Text message |
https-v6.tcl |
ipv6_https_301 |
Verify IPv6 HTTPS/1.1 WebSocket Text message |
step 1. Send an IPv6 HTTPS/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket data message with text
step 4. Verify server side echos back the same text data
step 5. Close the WebSocket server
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
http2-v6.tcl
IPv6 HTTP/2 related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections |
http2-v6.tcl |
ipv6_http2_100 |
Verify HTTP/2 GET connections |
step 1. Send an HTTP/2 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 POST connections |
http2-v6.tcl |
ipv6_http2_101 |
Verify HTTP/2 POST connections |
step 1. Send an HTTP/2 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 HEAD connections |
http2-v6.tcl |
ipv6_http2_102 |
Verify HTTP/2 HEAD connections |
step 1. Send an HTTP/2 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 PUT connections |
http2-v6.tcl |
ipv6_http2_103 |
Verify HTTP/2 PUT connections |
step 1. Send an HTTP/2 PUT request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 OPTIONS connections |
http2-v6.tcl |
ipv6_http2_104 |
Verify HTTP/2 OPTIONS connections |
step 1. Send an HTTP/2 OPTIONS request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 DELETE connections |
http2-v6.tcl |
ipv6_http2_105 |
Verify HTTP/2 DELETE connections |
step 1. Send an HTTP/2 DELETE request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections with large number of headers |
http2-v6.tcl |
ipv6_http2_106 |
Verify HTTP/2 GET connections with large number of headers |
step 1. Send an HTTP/2 GET request to the server with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
http2-tls-v6.tcl
IPv6 HTTP/2 over TLS related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_100 |
Verify HTTP/2 GET connections over TLS |
step 1. Send an HTTP/2 GET request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 POST connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_101 |
Verify HTTP/2 POST connections over TLS |
step 1. Send an HTTP/2 POST request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 HEAD connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_102 |
Verify HTTP/2 HEAD connections over TLS |
step 1. Send an HTTP/2 HEAD request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 PUT connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_103 |
Verify HTTP/2 PUT connections over TLS |
step 1. Send an HTTP/2 PUT request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 OPTIONS connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_104 |
Verify HTTP/2 OPTIONS connections over TLS |
step 1. Send an HTTP/2 OPTIONS request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 DELETE connections over TLS |
http2-tls-v6.tcl |
ipv6_http2_tls_105 |
Verify HTTP/2 DELETE connections over TLS |
step 1. Send an HTTP/2 DELETE request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections over TLS with large number of headers |
http2-tls-v6.tcl |
ipv6_http2_tls_106 |
Verify HTTP/2 GET connections over TLS with large number of headers |
step 1. Send an HTTP/2 GET request to the server over TLS with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
upnp-v6.tcl
IPv6 UPnP tests for routers that support IGDv1/IGDv2 devices
| Test |
Module |
Name |
Synopsis |
Verify UPnP router responds to SSDP Discovery Requests on LAN (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_1 |
Verify UPnP router responds to SSDP Discovery Requests on LAN (IPv6) |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify UPnP router does not respond to SSDP Discovery Requests on WAN (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_2 |
Verify UPnP router does not respond to SSDP Discovery Requests on WAN (IPv6) |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request on WAN side of router
step 3. Wait up to 5 seconds for all responses sent
step 4. Verify no responses are received
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify UPnP router supports discovery of required IGD devices and services (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_3 |
Verify UPnP router supports discovery of required IGD devices and services (IPv6) |
step 1. Build a M-SEARCH request for search for each required device/service
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
Required device and service URNs:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
urn:schemas-upnp-org:device:WANDevice:1
urn:schemas-upnp-org:device:WANConnectionDevice:1
urn:schemas-upnp-org:device:LANDevice:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
urn:schemas-upnp-org:service:WANIPConnection:1 (not required for PPP)
NOTE: Support for UPnP LANDevice:1 template is now configurable. If
the router under test does not support the LANDevice:1
template, the 'upnpLANDevice' testvar should be configured to
no. If LANDevice is supported, the testvar should be configured
to yes.
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
WANIPConnection:1 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf
WANIPConnection:2 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
| Test |
Module |
Name |
Synopsis |
Verify UPnP router does not respond to SSDP Discovery Requests without MX header (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_4 |
Verify UPnP router does not respond to SSDP Discovery Requests without MX header (IPv6) |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
that does not include an MX header
step 2. Send M-SEARCH request on LAN side of router
step 3. Wait up to 5 seconds for all responses sent
step 4. Verify no responses are received
References:
UPnP Device Architecture 1.1 Section 1.3.3: Search response
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1.3.3
| Test |
Module |
Name |
Synopsis |
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_5 |
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN (IPv6) |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send a unicast M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify required headers of M-SEARCH responses on LAN (IPv6) |
upnp-v6.tcl |
ipv6_ssdp_6 |
Verify required headers of M-SEARCH responses on LAN (IPv6) |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify XML description of IGD root device can be parsed (IPv6) |
upnp-v6.tcl |
ipv6_upnp_10 |
Verify XML description of IGD root device can be parsed (IPv6) |
step 1. Find the description URL for the root device using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required root device:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML descriptions cannot be loaded from the WAN side of router (IPv6) |
upnp-v6.tcl |
ipv6_upnp_12 |
Verify XML descriptions cannot be loaded from the WAN side of router (IPv6) |
step 1. Find the description URL for the root device using SSDP on LAN
step 2. Send HTTP GET from the WAN side to load description URL
step 3. Send HTTP GET using router's WAN side public IP and private IP
step 4. Verify description cannot be loaded using HTTP
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IPv6) |
upnp-v6.tcl |
ipv6_upnp_20 |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IPv6) |
step 1. Find the description URL for the WANIPConnection or
WANPPPConnection service using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required service name:
urn:schemas-upnp-org:service:WANIPConnection:1
urn:schemas-upnp-org:service:WANPPPConnection:1
NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
test case to use the WANPPPConnection service. Otherwise, the
router uses the WANIPConnection service.
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify router responds to UPnP Query for ConnectionStatus (IPv6) |
upnp-v6.tcl |
ipv6_upnp_25 |
Verify router responds to UPnP Query for ConnectionStatus (IPv6) |
step 1. Find Control URL for WANIPConnection service
step 2. Send UPnP Query for ConnectionStatus via SOAP POST
step 3. Verify ConnectionStatus variable is returned in SOAP response
NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
This test should be skipped if the device does not support the
QueryStateVariable action.
References:
UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IPv6) |
upnp-v6.tcl |
ipv6_upnp_30 |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetExternalIPAddress
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify IP address returned in the NewExternalIPAddress
attribute is the correct WAN IP address
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.18: GetExternalIPAddress
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IPv6) |
upnp-v6.tcl |
ipv6_upnp_31 |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify returned ConnectionStatus is in the 'Connected' state
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IPv6) |
upnp-v6.tcl |
ipv6_upnp_32 |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Save the current Uptime
step 5. Wait 10 seconds
step 6. Send UPnP Action for GetStatusInfo
step 7. Verify Action succeeds with HTTP return code 200
step 8. Verify Uptime has increased by at least 10 seconds
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IPv6) |
upnp-v6.tcl |
ipv6_upnp_35 |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IPv6) |
upnp-v6.tcl |
ipv6_upnp_36 |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection from specific IP address (A)
to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd TCP connection is blocked
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
from specific ip address (A)
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IPv6) |
upnp-v6.tcl |
ipv6_upnp_40 |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address on the WAN side
step 7. Verify 2nd UDP connection is established
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IPv6) |
upnp-v6.tcl |
ipv6_upnp_41 |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection from specific IP address (A)
to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd UDP connection is blocked
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
from specific ip address (A)
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Verify UPnP Router rejects new port mappings that conflict (IPv6) |
upnp-v6.tcl |
ipv6_upnp_45 |
Verify UPnP Router rejects new port mappings that conflict (IPv6) |
step 1. Start second DHCP client on LAN interface
step 2. Find Control URL for WANIPConnection or WANPPPConnection service
step 3. Send UPnP Action for AddPortMapping from the first DHCP client
step 4. Verify Action returns HTTP 200 status code
step 5. Send 2nd UPnP Action for AddPortMapping from the second DHCP client
using the same external port number and protocol
step 6. Verify AddPortMapping Action fails
step 7. Delete port mapping using DeletePortMapping Action
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
| Test |
Module |
Name |
Synopsis |
Verify dynamic UPnP port mapping is deleted when lease expires (IPv6) |
upnp-v6.tcl |
ipv6_upnp_50 |
Verify dynamic UPnP port mapping is deleted when lease expires (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 45 seconds for lease to be deleted
step 8. Initiate inbound TCP connection to new port mapping
step 9. Verify TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Maximum number of UPnP TCP dynamic port mappings (IPv6) |
upnp-v6.tcl |
ipv6_upnp_100 |
Maximum number of UPnP TCP dynamic port mappings (IPv6) |
step 1. Determine the maximum number of UPnP TCP port mappings
NOTE: This is configured in your configuration file using the
the testvar 'upnpMaxTcpMappings'.
step 2. Create a unique port mapping using the AddPortMapping Action
up to the maximum number supported
step 3. For each mapping, establish an inbound TCP connection
step 4. Verify each TCP connection can be established
step 5. Delete each port mapping using the DeletePortMapping Action
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IPv6) |
upnp-v6.tcl |
ipv6_upnp_200 |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe to events with infinite subscription time (IPv6) |
upnp-v6.tcl |
ipv6_upnp_201 |
Verify UPnP clients can subscribe to events with infinite subscription time (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IPv6) |
upnp-v6.tcl |
ipv6_upnp_202 |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send SUBSCRIBE renewal for NOTIFY events
step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
step 7. Send UNSUBSCRIBE for eventSubURL
step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IPv6) |
upnp-v6.tcl |
ipv6_upnp_203 |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. Wait for NOTIFY event with new ConnectionStatus
step 8. Verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. Wait for NOTIFY event with new ConnectionStatus
step 11. Verify ConnectionStatus is 'Connected'
step 12. Send UNSUBSCRIBE for eventSubURL
step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: This test is not supported when the wanMode is static.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IPv6) |
upnp-v6.tcl |
ipv6_upnp_204 |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ExternalIPAddress matches current assigned WAN IP
step 6. Bring down WAN link
step 7. Bring up WAN link with new external IP address
step 8. Wait for NOTIFY event with new ExternalIPAddress
step 9. Verify ExternalIPAddress is new IP address
step 10. Bring down WAN link
step 11. Bring up WAN link with new original IP address
step 12. Wait for NOTIFY event with new ExternalIPAddress
step 13. Verify ExternalIPAddress is original IP address
step 14. Send UNSUBSCRIBE for eventSubURL
step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router stops sending NOTIFY events when subscription expires (IPv6) |
upnp-v6.tcl |
ipv6_upnp_210 |
Verify router stops sending NOTIFY events when subscription expires (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Wait minimum subscriber timeout seconds for subscription to expire
step 7. Bring down WAN link
step 8. Wait for NOTIFY event
step 9. Verify NOTIFY event is not received
step 10. Bring up WAN link
step 11. Wait for NOTIFY event
step 12. Verify NOTIFY event is not received
step 13. Do not UNSUBSCRIBE since subscription should be expired
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of UPnP event subscriptions that can be created (IPv6) |
upnp-v6.tcl |
ipv6_upnp_220 |
Verify the maximum number of UPnP event subscriptions that can be created (IPv6) |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. For each event client, send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. For each event client, wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
step 8. For each event client, verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
step 11. For each event client, verify ConnectionStatus is 'Connected'
step 12. For each event client, send UNSUBSCRIBE for eventSubURL
step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: The number of UPnP subscribers can be configured using the testvar
upnpMaxSubClients. If not configured, the default is 10 subscribers.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
upnp-v6.tcl |
ipv6_upnp_400 |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for SetConnectionType with string format
step 3. Verify Action does not return HTTP 200 status code
step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit
References:
Broadcom UPnP Remote Preauth Code Execution Vulnerability
https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/
From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)
https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt
| Test |
Module |
Name |
Synopsis |
Verify UPnP router supports discovery of required IGD devices and services (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_ssdp_igd2_3 |
Verify UPnP router supports discovery of required IGD devices and services (IGD2,IPv6) |
step 1. Build a M-SEARCH request for search for each required device/service
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
Required device and service URNs:
urn:schemas-upnp-org:device:InternetGatewayDevice:2
urn:schemas-upnp-org:device:WANDevice:2
urn:schemas-upnp-org:device:WANConnectionDevice:2
urn:schemas-upnp-org:device:LANDevice:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
urn:schemas-upnp-org:service:WANIPConnection:2 (not required for PPP)
NOTE: Support for UPnP LANDevice:1 template is now configurable. If
the router under test does not support the LANDevice:1
template, the 'upnpLANDevice' testvar should be configured to
no. If LANDevice is supported, the testvar should be configured
to yes.
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML description of IGD root device can be parsed (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_10 |
Verify XML description of IGD root device can be parsed (IGD2,IPv6) |
step 1. Find the description URL for the root device using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required root device:
urn:schemas-upnp-org:device:InternetGatewayDevice:2
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_12 |
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2,IPv6) |
step 1. Find the description URL for the root device using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required root device:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_20 |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2,IPv6) |
step 1. Find the description URL for the WANIPConnection:2 or
WANPPPConnection:1 service using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required service name:
urn:schemas-upnp-org:service:WANIPConnection:2
urn:schemas-upnp-org:service:WANPPPConnection:1
NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
test case to use the WANPPPConnection service. Otherwise, the
router uses the WANIPConnection service.
References:
WANIPConnection:2 Service Template Version 2.00
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
WANIPConnection:2 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
| Test |
Module |
Name |
Synopsis |
Verify router responds to UPnP Query for ConnectionStatus (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_25 |
Verify router responds to UPnP Query for ConnectionStatus (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 service
step 2. Send UPnP Query for ConnectionStatus via SOAP POST
step 3. Verify ConnectionStatus variable is returned in SOAP response
NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
This test should be skipped if the device does not support the
QueryStateVariable action.
References:
UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_30 |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetExternalIPAddress
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify IP address returned in the NewExternalIPAddress
attribute is the correct WAN IP address
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.20: GetExternalIPAddress
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.20
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_31 |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify returned ConnectionStatus is in the 'Connected' state
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_32 |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Save the current Uptime
step 5. Wait 10 seconds
step 6. Send UPnP Action for GetStatusInfo
step 7. Verify Action succeeds with HTTP return code 200
step 8. Verify Uptime has increased by at least 10 seconds
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_35 |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_36 |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection from specific IP address (A)
to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd TCP connection is blocked
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
from specific ip address (A)
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_40 |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address on the WAN side
step 7. Verify 2nd UDP connection is established
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_41 |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection from specific IP address (A)
to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd UDP connection is blocked
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
from specific ip address (A)
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP Router rejects new port mappings that conflict (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_45 |
Verify UPnP Router rejects new port mappings that conflict (IGD2,IPv6) |
step 1. Start second client on LAN interface
step 2. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 3. Send UPnP Action for AddPortMapping from the first DHCP client
step 4. Verify Action returns HTTP 200 status code
step 5. Send 2nd UPnP Action for AddPortMapping from the second client
using the same external port number and protocol
step 6. Verify AddPortMapping Action fails
step 7. Delete port mapping using DeletePortMapping Action
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
| Test |
Module |
Name |
Synopsis |
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_50 |
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 45 seconds for lease to be deleted
step 8. Initiate inbound TCP connection to new port mapping
step 9. Verify TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
| Test |
Module |
Name |
Synopsis |
Maximum number of UPnP TCP dynamic port mappings (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_100 |
Maximum number of UPnP TCP dynamic port mappings (IGD2,IPv6) |
step 1. Determine the maximum number of UPnP TCP port mappings
NOTE: This is configured in your configuration file using the
the testvar 'upnpMaxTcpMappings'.
step 2. Create a unique port mapping using the AddPortMapping Action
up to the maximum number supported
step 3. For each mapping, establish an inbound TCP connection
step 4. Verify each TCP connection can be established
step 5. Delete each port mapping using the DeletePortMapping Action
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_200 |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_201 |
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_202 |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send SUBSCRIBE renewal for NOTIFY events
step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
step 7. Send UNSUBSCRIBE for eventSubURL
step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_203 |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. Wait for NOTIFY event with new ConnectionStatus
step 8. Verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. Wait for NOTIFY event with new ConnectionStatus
step 11. Verify ConnectionStatus is 'Connected'
step 12. Send UNSUBSCRIBE for eventSubURL
step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: This test is not supported when the wanMode is static.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_204 |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ExternalIPAddress matches current assigned WAN IP
step 6. Bring down WAN link
step 7. Bring up WAN link with new external IP address
step 8. Wait for NOTIFY event with new ExternalIPAddress
step 9. Verify ExternalIPAddress is new IP address
step 10. Bring down WAN link
step 11. Bring up WAN link with new original IP address
step 12. Wait for NOTIFY event with new ExternalIPAddress
step 13. Verify ExternalIPAddress is original IP address
step 14. Send UNSUBSCRIBE for eventSubURL
step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router stops sending NOTIFY events when subscription expires (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_210 |
Verify router stops sending NOTIFY events when subscription expires (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Wait minimum subscriber timeout seconds for subscription to expire
step 7. Bring down WAN link
step 8. Wait for NOTIFY event
step 9. Verify NOTIFY event is not received
step 10. Bring up WAN link
step 11. Wait for NOTIFY event
step 12. Verify NOTIFY event is not received
step 13. Do not UNSUBSCRIBE since subscription should be expired
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of UPnP event subscriptions that can be created (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_220 |
Verify the maximum number of UPnP event subscriptions that can be created (IGD2,IPv6) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. For each event client, send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. For each event client, wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
step 8. For each event client, verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
step 11. For each event client, verify ConnectionStatus is 'Connected'
step 12. For each event client, send UNSUBSCRIBE for eventSubURL
step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: The number of UPnP subscribers can be configured using the testvar
upnpMaxSubClients. If not configured, the default is 10 subscribers.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router responds to UPnP GetFirewallStatus action (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_230 |
Verify router responds to UPnP GetFirewallStatus action (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for GetFirewallStatus
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify FirewallEnabled and InboundPinholeAllowed attributes
are returned
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.1: GetFirewallStatus
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.1
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for wildcard IPv6 source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_300 |
Add/delete dynamic UPnP TCP port mapping for wildcard IPv6 source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with wildcard
for RemoteHost ("") and LeaseTime of 3600
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePinhole Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for specific IPv6 source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_301 |
Add/delete dynamic UPnP TCP port mapping for specific IPv6 source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with specific IP address (A)
for RemoteHost and LeaseTime of 3600
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection from specific IP address (A)
to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd TCP connection is blocked
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePinhole Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
from specific ip address (A)
step 12. Verify inbound TCP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP port mapping for wildcard IPv6 source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_302 |
Add/delete dynamic UPnP port mapping for wildcard IPv6 source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with wildcard
for RemoteHost ("") and LeaseTime of 3600
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePinhole Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP port mapping for specific IPv6 source address (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_303 |
Add/delete dynamic UPnP port mapping for specific IPv6 source address (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with specific IP address (A)
for RemoteHost, Protocol UDP and LeaseTime of 3600
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound UDP connection from specific IP address (A)
to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd UDP connection is blocked
step 8. Delete port mapping using DeletePinhole Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
from specific ip address (A)
step 11. Verify inbound UDP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Verify IPv6 dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_304 |
Verify IPv6 dynamic UPnP port mapping is deleted when lease expires (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with lease of 30 seconds
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 45 seconds for lease to be deleted
step 8. Initiate inbound TCP connection to new port mapping
step 9. Verify TCP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
| Test |
Module |
Name |
Synopsis |
Maximum number of UPnP IPv6 TCP dynamic port mappings (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_305 |
Maximum number of UPnP IPv6 TCP dynamic port mappings (IGD2,IPv6) |
step 1. Determine the maximum number of UPnP TCP port mappings
NOTE: This is configured in your configuration file using the
the testvar 'upnpMaxTcpMappings'.
step 2. Create a unique port mapping using the AddPinhole Action
up to the maximum number supported
step 3. For each mapping, establish an inbound TCP connection
step 4. Verify each TCP connection can be established
step 5. Delete each port mapping using the DeletePinhole Action
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Update lease time for UPnP TCP port mapping (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_306 |
Update lease time for UPnP TCP port mapping (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with wildcard for
RemoteHost ("") and LeaseTime of 30
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection to new port mapping from WAN side
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 20 seconds
step 8. Send UPnP Action for UpdatePinhole with UniqueID from step
3 and NewLeaseTime of 120
step 9. Verify Action returns HTTP 200 status code
step 10. Wait 20 seconds
step 11. Initiate inbound TCP connection to port mapping from WAN side
step 12. Verify TCP connection is established
step 13. Close TCP connection
step 14. Delete port mapping using DeletePinhole Action
step 15. Wait 5 seconds for port mapping to be deleted
step 16. Initiate inbound TCP connection for port mapping from WAN side
step 17. Verify inbound TCP connection is blocked
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.3: AddPinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.3
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.5: DeletePinhole
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.5
| Test |
Module |
Name |
Synopsis |
Verify GetPinholePackets action returns increasing packet count (IGD2,IPv6) |
upnp-v6.tcl |
ipv6_upnp_igd2_307 |
Verify GetPinholePackets action returns increasing packet count (IGD2,IPv6) |
step 1. Find Control URL for WANIPv6FirewallControl service
step 2. Send UPnP Action for AddPinhole with wildcard for
RemoteHost ("") and LeaseTime of 3600
step 3. Verify Action returns HTTP 200 status code with UniqueID parameter
step 4. Initiate inbound TCP connection to new port mapping from WAN side
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Send UPnP Action for GetPinholePackets with UniqueID from step 3
step 8. Verify Action returns HTTP 200 status code with non-zero PinholePackets parameter
step 9. Initiate inbound TCP connection to port mapping from WAN side
step 10. Verify TCP connection is established
step 11. Close TCP connection
step 12. Send UPnP Action for GetPinholePackets with UniqueID from step 3
step 13. Verify Action returns HTTP 200 status code with a
PinholePackets parameter greater than that from step 9
step 14. Delete port mapping using DeletePinhole Action
References:
WANIPv6FirewallControl:1 Service Template Version 1.00 Section 2.6.6: GetPinholePackets
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf2.6.6
| Test |
Module |
Name |
Synopsis |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
upnp-v6.tcl |
ipv6_upnp_igd2_400 |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for SetConnectionType with string format
step 3. Verify Action does not return HTTP 200 status code
step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit
References:
Broadcom UPnP Remote Preauth Code Execution Vulnerability
https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/
From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)
https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt
ipv6-mss.tcl
IPv6 MSS tests for routers that support IPv6 TCP MSS clamping
| Test |
Module |
Name |
Synopsis |
Verify basic MSS Clamping for TCP sessions |
ipv6-mss.tcl |
ipv6_mss_100 |
Verify basic MSS Clamping for TCP sessions |
step 1. Set the TCP MSS size to 1440
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN matches
the expected MSS size
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
NOTE: The expected MSS size for MSS clamping can be configured
using the testvar 'ipv6MssClampingValue'. If the inbound direction is
different than the outbound direction for MSS clamping, the inbound
direction can be adjusted using the testvar ipv6MssClampingInValue.
Example:
testvar ipv6MssClampingValue 1452
Example with different values per direction:
testvar ipv6MssClampingValue 1452
testvar ipv6MssClampingInValue 1440
NOTE: The TCP port used for the MSS clamping test can be changed
using the testvar ipv6MssClampingTestPort.
Example:
testvar ipv6MssClampingTestPort 8096
| Test |
Module |
Name |
Synopsis |
Verify MSS Clamping with TCP options from different clients |
ipv6-mss.tcl |
ipv6_mss_110 |
Verify MSS Clamping with TCP options from different clients |
step 1. Set the TCP options to resemble a Windows TCP client
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN matches
the expected MSS size
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
step 8. Repeat testing using TCP options for a Linux TCP client
step 9. Repeat testing using TCP options for a Mac OS X TCP client
NOTE: The expected MSS size for MSS clamping can be configured
using the testvar 'ipv6MssClampingValue'. If the inbound direction is
different than the outbound direction for MSS clamping, the inbound
direction can be adjusted using the testvar ipv6MssClampingInValue.
Example:
testvar ipv6MssClampingValue 1452
Example with different values per direction:
testvar ipv6MssClampingValue 1452
testvar ipv6MssClampingInValue 1440
NOTE: The TCP port used for the MSS clamping test can be changed
using the testvar ipv6MssClampingTestPort.
Example:
testvar ipv6MssClampingTestPort 8096
| Test |
Module |
Name |
Synopsis |
Verify MSS Clamping does not modify smaller MSS values |
ipv6-mss.tcl |
ipv6_mss_120 |
Verify MSS Clamping does not modify smaller MSS values |
step 1. Set the TCP MSS size to 512
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN is stil 512
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
NOTE: In order to pass this test, the router's expected MSS Clamping value
must be greater than 512. When the router detects a MSS value smaller than its
own MSS clamping value, it should leave the MSS unchanged. The expected MSS
size for MSS clamping can be configured using the testvar 'ipv6MssClampingValue'.
Example:
testvar ipv6MssClampingValue 1452
NOTE: The TCP port used for the MSS clamping test can be changed
using the testvar ipv6MssClampingTestPort.
Example:
testvar ipv6MssClampingTestPort 8096
mape.tcl
MAP-E / LW4o6 tests for mapping IPv4 to IPv6
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates outbound packets to destinations outside the MAP domain |
mape.tcl |
mape_1 |
Verify MAP-E / LW4o6 CE translates outbound packets to destinations outside the MAP domain |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 destination address is the BR address
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 5.4: Destinations outside of the MAP Domain
https://tools.ietf.org/html/rfc7597#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates inbound packets from destinations outside the MAP domain |
mape.tcl |
mape_2 |
Verify MAP-E / LW4o6 CE translates inbound packets from destinations outside the MAP domain |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 destination address is the BR address
step 4. Send a return UDP packet back to the CE's WAN side source port
step 5. Verify that the return UDP packet is received on the LAN
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 5.4: Destinations outside of the MAP Domain
https://tools.ietf.org/html/rfc7597#section-5.4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port inside the PSID set |
mape.tcl |
mape_10 |
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port inside the PSID set |
step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
the WAN using a source port inside the PSID set
step 2. Verify that the connection is established
step 3. Send an HTTP GET request to server
step 4. Verify that an HTTP response is received
step 5. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 6. Verify that the TCP source port has been translated to a port
contained inside the PSID set
step 7. Close the TCP connection from LAN side
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture
For packets outbound from the private IPv4 network, the CE NAPT
MUST translate transport identifiers (e.g., TCP and UDP port
numbers) so that they fall within the CE's assigned port range.
https://tools.ietf.org/html/rfc7597#section-4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port outside the PSID set |
mape.tcl |
mape_11 |
Verify MAP-E / LW4o6 CE translates outbound TCP connections with source port outside the PSID set |
step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
the WAN using a source port outside the PSID set
step 2. Verify that the connection is established
step 3. Send an HTTP GET request to server
step 4. Verify that an HTTP response is received
step 5. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 6. Verify that the TCP source port has been translated to a port
contained inside the PSID set
step 7. Close the TCP connection from LAN side
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture
For packets outbound from the private IPv4 network, the CE NAPT
MUST translate transport identifiers (e.g., TCP and UDP port
numbers) so that they fall within the CE's assigned port range.
https://tools.ietf.org/html/rfc7597#section-4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port inside the PSID set |
mape.tcl |
mape_12 |
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port inside the PSID set |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source port inside the PSID set
step 2. Verify that the UDP packet is received on the WAN
step 3. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 4. Verify that the UDP source port has been translated to a port
contained inside the PSID set
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture
For packets outbound from the private IPv4 network, the CE NAPT
MUST translate transport identifiers (e.g., TCP and UDP port
numbers) so that they fall within the CE's assigned port range.
https://tools.ietf.org/html/rfc7597#section-4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port outside the PSID set |
mape.tcl |
mape_13 |
Verify MAP-E / LW4o6 CE translates outbound UDP connections with source port outside the PSID set |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source port outside the PSID set
step 2. Verify that the UDP packet is received on the WAN
step 3. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 4. Verify that the UDP source port has been translated to a port
contained inside the PSID set
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 4: Architecture
For packets outbound from the private IPv4 network, the CE NAPT
MUST translate transport identifiers (e.g., TCP and UDP port
numbers) so that they fall within the CE's assigned port range.
https://tools.ietf.org/html/rfc7597#section-4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE does not translate packets with bad source address |
mape.tcl |
mape_14 |
Verify MAP-E / LW4o6 CE does not translate packets with bad source address |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source address of 0.0.0.0
step 2. Verify that the UDP packet is not received on the WAN
step 3. Repeat steps 1 and 2 using source addresses of 127.0.0.1 and
224.0.0.1
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8: Forwarding Considerations
For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the
LAN performs NAT44 functions first and creates appropriate NAT44
bindings. The resulting IPv4 packets MUST contain the source IPv4
address and source transport identifiers specified by the MAP
provisioning parameters. The IPv4 packet is forwarded using the CE's
MAP forwarding function. The IPv6 source and destination addresses
MUST then be derived as per Section 5 of this document.
https://tools.ietf.org/html/rfc7597#section-8
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE sets IPv6 Hop Limit to correct value when translating packets |
mape.tcl |
mape_20 |
Verify MAP-E / LW4o6 CE sets IPv6 Hop Limit to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify the IPv6 Hop Limit is set to mapTunnelHopLimit
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.3: IPv6 Tunnel Hop Limit
The tunnel hop limit is copied into the hop limit field of the tunnel
IPv6 header of each packet encapsulated by the tunnel entry-point
node.
https://tools.ietf.org/html/rfc2473#section-6.3
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE sets IPv6 Traffic Class to correct value when translating packets |
mape.tcl |
mape_21 |
Verify MAP-E / LW4o6 CE sets IPv6 Traffic Class to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Traffic Class is either set to mapTunnelTrafficClass
NOTE: If the Traffic Class field is expected to be copied from the
original header, the testvar mapTunnelTrafficClass should be set
to the value "auto".
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.4: IPv6 Tunnel Hop Limit
The IPv6 Tunnel Packet Traffic Class indicates the value that a
tunnel entry-point node sets in the Traffic Class field of a tunnel
header. The default value is zero. The configured Packet Traffic
Class can also indicate whether the value of the Traffic Class field
in the tunnel header is copied from the original header, or it is set
to the pre-configured value.
https://tools.ietf.org/html/rfc2473#section-6.4
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE sets IPv6 Flow Label to correct value when translating packets |
mape.tcl |
mape_22 |
Verify MAP-E / LW4o6 CE sets IPv6 Flow Label to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Flow Label is set to mapTunnelFlowLabel
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 6.5: IPv6 Tunnel Flow Label
The IPv6 Tunnel Flow Label indicates the value that a tunnel entry-
point node sets in the flow label of a tunnel header. The default
value is zero.
https://tools.ietf.org/html/rfc2473#section-6.5
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE sets IPv6 Next Header to correct value when translating packets |
mape.tcl |
mape_23 |
Verify MAP-E / LW4o6 CE sets IPv6 Next Header to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Next Header is set to 4 (IP-IP).
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 5: Tunnel IPv6 Header
Next Header:
The next header value according to [IPv6-Spec] from the
Assigned Numbers RFC [RFC-1700 or its successors].
https://tools.ietf.org/html/rfc2473#section-5
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE fragments large outbound packets with either IPv4 or IPv6 |
mape.tcl |
mape_30 |
Verify MAP-E / LW4o6 CE fragments large outbound packets with either IPv4 or IPv6 |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Reassemble either IPv4 or IPv6 and verify original packet
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation
https://tools.ietf.org/html/rfc2473#section-7.2
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain
https://tools.ietf.org/html/rfc7597#section-8.3.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 |
mape.tcl |
mape_31 |
Verify MAP-E / LW4o6 CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation with DF=1
step 2. Verify that the MAP-E CE sends an ICMPv4 Destination Unreachable
step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'
References:
IETF RFC 2473 "Generic Packet Tunneling in IPv6 Specification" Section 7.2: IPv4 Tunnel Packet Fragmentation
(a) if in the original IPv4 packet header the Don't Fragment -
DF - bit flag is SET, the entry-point node discards the
packet and returns an ICMP message. The ICMP message has
the type = "unreachable", the code = "packet too big", and
the recommended MTU size field set to the size of the
tunnel MTU - see sections 6.7 and 8.3.
https://tools.ietf.org/html/rfc2473#section-7.2
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: Fragmentation and Path MTU Discovery
https://tools.ietf.org/html/rfc7597#section-8.3
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments originating from LAN |
mape.tcl |
mape_32 |
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments originating from LAN |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
does not need IPv6 fragmentation
step 2. Send the IPv4 packet on the LAN as two IPv4 fragments
step 3. Verify that the packet is received as an IPv6 packet on the WAN
NOTE: A MAP CE may choose to assemble outgoing IPv4 fragments before applying
NAT44.
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: Fragmentation and Path MTU Discovery
https://tools.ietf.org/html/rfc7597#section-8.3
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments which require IPv6 fragmentation |
mape.tcl |
mape_33 |
Verify MAP-E / LW4o6 CE properly handles outbound IPv4 fragments which require IPv6 fragmentation |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Reassemble either IPv4 or IPv6 and verify original packet
step 4. Repeat for total LAN IPv4 packet sizes from 1490 to 1500
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain
Encapsulating an IPv4 packet to carry it across the MAP domain will
increase its size (typically by 40 bytes). It is strongly
recommended that the MTU in the MAP domain be well managed and that
the IPv6 MTU on the CE WAN-side interface be set so that no
fragmentation occurs within the boundary of the MAP domain.
For an IPv4 packet entering a MAP domain, fragmentation is performed
as described in Section 7.2 of [RFC2473].
https://tools.ietf.org/html/rfc7597#section-8.3.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly handles incoming IPv6 fragments from BR |
mape.tcl |
mape_34 |
Verify MAP-E / LW4o6 CE properly handles incoming IPv6 fragments from BR |
step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
connection
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Send multiple IPv6 fragmented packets from BR to WAN side of CPE
with total UDP length of 2490
step 4. Verify CPE is able to reassemble IPv6 and forward original IPv4
packets to LAN
step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
2491 to 2500
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain
https://tools.ietf.org/html/rfc7597#section-8.3.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly handles incoming IPv4 fragments from BR |
mape.tcl |
mape_35 |
Verify MAP-E / LW4o6 CE properly handles incoming IPv4 fragments from BR |
step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
connection
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Send multiple IPv4 fragmented packets from BR to WAN side of CPE
with total UDP length of 2490
step 4. Verify CPE is able to receive IPv6 and forward original IPv4
packets to LAN
step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
2491 to 2500
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3.1: Fragmentation in the MAP Domain
https://tools.ietf.org/html/rfc7597#section-8.3.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly rewrites ICMPv4 Identifier field |
mape.tcl |
mape_40 |
Verify MAP-E / LW4o6 CE properly rewrites ICMPv4 Identifier field |
step 1. Send an ICMPv4 packet from the LAN to a destination outside the MAP
domain on the WAN
step 2. Verify that an ICMPv4 packet is received as an IPv6 packet on the WAN
step 3. Verify that the ICMPv4 Identifier field has been rewritten
to a value contained with the PSID set
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.2: ICMP
If a MAP CE receives an ICMP message having the ICMP Identifier field
in the ICMP header, the NAT44 in the MAP CE MUST rewrite this field
to a specific value assigned from the port set. BRs and other CEs
must handle this field in a way similar to the handling of a port
number in the TCP/UDP header upon receiving the ICMP message with the
ICMP Identifier field.
https://tools.ietf.org/html/rfc7597#section-8.2
| Test |
Module |
Name |
Synopsis |
Verify MAP-E / LW4o6 CE properly handles ICMPv4 error messages |
mape.tcl |
mape_41 |
Verify MAP-E / LW4o6 CE properly handles ICMPv4 error messages |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Send ICMPv6 Destination Unreachable packet with original IPv4 packet as data
step 4. Verify that the LAN client receives an ICMPv4 Port
Unreachable packet with code 3 (Port unreachable)
References:
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.1: Tunnel ICMP Messages
https://tools.ietf.org/html/rfc7597#section-8.1
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.2: ICMP
If a MAP node receives an ICMP error message without the ICMP
Identifier field for errors that are detected inside an IPv6 tunnel,
a node should relay the ICMP error message to the original source.
This behavior SHOULD be implemented in accordance with Section 8 of
[RFC2473].
https://tools.ietf.org/html/rfc7597#section-8.2
IETF RFC 7597 "Mapping of Address and Port with Encapsulation (MAP-E)" Section 8.3: ICMP Messages for IPv4 Original Packets
https://tools.ietf.org/html/rfc7597#section-8.3
mapt.tcl
MAP-T tests for mapping IPv4 to IPv6
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates outbound packets to destinations outside the MAP domain |
mapt.tcl |
mapt_1 |
Verify MAP-T CE translates outbound packets to destinations outside the MAP domain |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 destination address is translated using the DMR
prefix
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 5.1: Destinations outside of the MAP Domain
https://tools.ietf.org/html/rfc7599#section-5.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates inbound packets from destinations outside the MAP domain |
mapt.tcl |
mapt_2 |
Verify MAP-T CE translates inbound packets from destinations outside the MAP domain |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 destination address is translated using the DMR
prefix
step 4. Send a return UDP packet back to the CE's WAN side source port
step 5. Verify that the return UDP packet is received on the LAN
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 5.1: Destinations outside of the MAP Domain
https://tools.ietf.org/html/rfc7599#section-5.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates outbound TCP connections with source port inside the PSID set |
mapt.tcl |
mapt_10 |
Verify MAP-T CE translates outbound TCP connections with source port inside the PSID set |
step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
the WAN using a source port inside the PSID set
step 2. Verify that the connection is established
step 3. Send an HTTP GET request to server
step 4. Verify that an HTTP response is received
step 5. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 6. Verify that the TCP source port has been translated to a port
contained inside the PSID set
step 7. Close the TCP connection from LAN side
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
and create any necessary NAPT44 bindings. The source address and
source port range of packets resulting from the NAPT44 processing
MUST correspond to the source IPv4 address and source transport port
range assigned to the CE by means of the MAP Basic Mapping Rule
(BMR).
https://tools.ietf.org/html/rfc7599#section-8.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates outbound TCP connections with source port outside the PSID set |
mapt.tcl |
mapt_11 |
Verify MAP-T CE translates outbound TCP connections with source port outside the PSID set |
step 1. Initiate an IPv4 TCP connection from the LAN to an HTTP server on
the WAN using a source port outside the PSID set
step 2. Verify that the connection is established
step 3. Send an HTTP GET request to server
step 4. Verify that an HTTP response is received
step 5. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 6. Verify that the TCP source port has been translated to a port
contained inside the PSID set
step 7. Close the TCP connection from LAN side
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
and create any necessary NAPT44 bindings. The source address and
source port range of packets resulting from the NAPT44 processing
MUST correspond to the source IPv4 address and source transport port
range assigned to the CE by means of the MAP Basic Mapping Rule
(BMR).
https://tools.ietf.org/html/rfc7599#section-8.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates outbound UDP connections with source port inside the PSID set |
mapt.tcl |
mapt_12 |
Verify MAP-T CE translates outbound UDP connections with source port inside the PSID set |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source port inside the PSID set
step 2. Verify that the UDP packet is received on the WAN
step 3. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 4. Verify that the UDP source port has been translated to a port
contained inside the PSID set
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
and create any necessary NAPT44 bindings. The source address and
source port range of packets resulting from the NAPT44 processing
MUST correspond to the source IPv4 address and source transport port
range assigned to the CE by means of the MAP Basic Mapping Rule
(BMR).
https://tools.ietf.org/html/rfc7599#section-8.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates outbound UDP connections with source port outside the PSID set |
mapt.tcl |
mapt_13 |
Verify MAP-T CE translates outbound UDP connections with source port outside the PSID set |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source port outside the PSID set
step 2. Verify that the UDP packet is received on the WAN
step 3. Verify that the IPv4 source address on the WAN side is the expected
NAT address
step 4. Verify that the UDP source port has been translated to a port
contained inside the PSID set
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 8.1: IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
and create any necessary NAPT44 bindings. The source address and
source port range of packets resulting from the NAPT44 processing
MUST correspond to the source IPv4 address and source transport port
range assigned to the CE by means of the MAP Basic Mapping Rule
(BMR).
https://tools.ietf.org/html/rfc7599#section-8.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE does not translate packets with bad source address |
mapt.tcl |
mapt_14 |
Verify MAP-T CE does not translate packets with bad source address |
step 1. Send an IPv4 UDP packet from the LAN to a destination on the WAN
using a source address of 0.0.0.0
step 2. Verify that the UDP packet is not received on the WAN
step 3. Repeat steps 1 and 2 using source addresses of 127.0.0.1 and
224.0.0.1
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
If the translator gets an illegal source address (e.g., 0.0.0.0,
127.0.0.1, etc.), the translator SHOULD silently drop the packet
(as discussed in Section 5.3.7 of [RFC1812]).
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE sets IPv6 Hop Limit to correct value when translating packets |
mapt.tcl |
mapt_20 |
Verify MAP-T CE sets IPv6 Hop Limit to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Hop Limit is based on the IPv4 TTL
step 4. Verify the IPv6 Hop Limit is decremented by at least the
number specified by the testvar IPv4HopCount
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
Hop Limit: The hop limit is derived from the TTL value in the IPv4
header. Since the translator is a router, as part of forwarding
the packet it needs to decrement either the IPv4 TTL (before the
translation) or the IPv6 Hop Limit (after the translation). As
part of decrementing the TTL or Hop Limit, the translator (as any
router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or
ICMPv6 "Hop Limit Exceeded" error.
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE sets IPv6 Traffic Class to correct value when translating packets |
mapt.tcl |
mapt_21 |
Verify MAP-T CE sets IPv6 Traffic Class to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Traffic Class is either set to all zeros if the
testvar mapTosTranslate is set to **no**, or copied from the IPv4
TOS if the testvar mapTosTranslate is set to **yes**
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
Traffic Class: By default, copied from the IP Type Of Service (TOS)
octet. According to [RFC2474], the semantics of the bits are
identical in IPv4 and IPv6. However, in some IPv4 environments
these fields might be used with the old semantics of "Type Of
Service and Precedence". An implementation of a translator SHOULD
support an administratively configurable option to ignore the IPv4
TOS and always set the IPv6 traffic class (TC) to zero. In
addition, if the translator is at an administrative boundary, the
filtering and update considerations of [RFC2475] may be
applicable.
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE sets IPv6 Flow Label to correct value when translating packets |
mapt.tcl |
mapt_22 |
Verify MAP-T CE sets IPv6 Flow Label to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Flow Label is set to 0 (all zero bits)
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE sets IPv6 Next Header to correct value when translating packets |
mapt.tcl |
mapt_23 |
Verify MAP-T CE sets IPv6 Next Header to correct value when translating packets |
step 1. Send an IPv4 UDP packet from the LAN to a destination outside the
MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 Next Header is set to 17 (UDP) or
that the packet contains a Fragmentation Header with a
Next Header value of 17 (UDP).
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4: Translating from IPv4 to IPv6
When the IPv4 sender does not set the DF bit, the translator SHOULD always
include an IPv6 Fragment Header to indicate that the sender allows
fragmentation. The translator MAY provide a configuration function that
allows the translator not to include the Fragment Header for the
non-fragmented IPv6 packets.
https://tools.ietf.org/html/rfc6145#section-4
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58);
otherwise, the protocol field MUST be copied from the IPv4 header.
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE ignores IPv4 options when translating packets |
mapt.tcl |
mapt_24 |
Verify MAP-T CE ignores IPv4 options when translating packets |
step 1. Send an IPv4 UDP packet with the router alert option from the LAN to
a destination outside the MAP domain on the WAN
step 2. Verify that the UDP packet is received as an IPv6 packet on the WAN
step 3. Verify that the IPv6 destination address is translated using the DMR
prefix
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
If any IPv4 options are present in the IPv4 packet, they MUST be
ignored and the packet translated normally; there is no attempt to
translate the options.
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE fragments large outbound packets with either IPv4 or IPv6 |
mapt.tcl |
mapt_30 |
Verify MAP-T CE fragments large outbound packets with either IPv4 or IPv6 |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Reassemble either IPv4 or IPv6 and verify original packet
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10: Fragmentation and Path MTU Discovery
https://tools.ietf.org/html/rfc7599#section-10
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 |
mapt.tcl |
mapt_31 |
Verify MAP-T CE generates ICMPv4 Destination Unreachable if packet needs fragmentation and DF=1 |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation with DF=1
step 2. Verify that the MAP-T CE sends an ICMPv4 Destination Unreachable
step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'
References:
IETF RFC 1191 "Path MTU Discovery" Section 2: Protocol overview
(DF) bit in the IP header to dynamically discover the PMTU of a path.
The basic idea is that a source host initially assumes that the PMTU
of a path is the (known) MTU of its first hop, and sends all
datagrams on that path with the DF bit set. If any of the datagrams
are too large to be forwarded without fragmentation by some router
along the path, that router will discard them and return ICMP
Destination Unreachable messages with a code meaning "fragmentation
needed and DF set" [7]. Upon receipt of such a message (henceforth
called a "Datagram Too Big" message), the source host reduces its
assumed PMTU for the path.
https://tools.ietf.org/html/rfc1191#section-2
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10: Fragmentation and Path MTU Discovery
https://tools.ietf.org/html/rfc7599#section-10
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE properly handles outbound IPv4 fragments originating from LAN |
mapt.tcl |
mapt_32 |
Verify MAP-T CE properly handles outbound IPv4 fragments originating from LAN |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
does not need IPv6 fragmentation
step 2. Send the IPv4 packet on the LAN as two IPv4 fragments
step 3. Verify that the packet is received as an IPv6 packet on the WAN
NOTE: A MAP CE may choose to assemble outgoing IPv4 fragments before applying
NAT44.
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.3: Sending IPv4 Fragments to the Outside
https://tools.ietf.org/html/rfc7599#section-10.3
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE properly handles outbound IPv4 fragments which require IPv6 fragmentation |
mapt.tcl |
mapt_33 |
Verify MAP-T CE properly handles outbound IPv4 fragments which require IPv6 fragmentation |
step 1. Send an IPv4 UDP packet from the LAN to the WAN using a size that
requires IPv4 or IPv6 fragmentation
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Reassemble either IPv4 or IPv6 and verify original packet
step 4. Repeat for total LAN IPv4 packet sizes from 1490 to 1500
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.1: Fragmentation in the MAP Domain
Translating an IPv4 packet to carry it across the MAP domain will
increase its size (typically by 20 bytes). The MTU in the MAP domain
should be well managed, and the IPv6 MTU on the CE WAN-side interface
SHOULD be configured so that no fragmentation occurs within the
boundary of the MAP domain.
Fragmentation in MAP-T domains SHOULD be handled as described in
Sections 4 and 5 of [RFC6145].
https://tools.ietf.org/html/rfc7599#section-10.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE properly handles incoming IPv6 fragments from BR |
mapt.tcl |
mapt_34 |
Verify MAP-T CE properly handles incoming IPv6 fragments from BR |
step 1. Send an IPv4 UDP packet from the LAN to the WAN to establish a NAT
connection
step 2. Verify that the packet is received as an IPv6 packet on the WAN
step 3. Send multiple IPv6 fragmented packets from BR to WAN side of CPE
with total UDP length of 2490
step 4. Verify CPE is able to reassemble IPv6 and forward original IPv4
packets to LAN
step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
2491 to 2500
References:
IETF RFC 7599 "Mapping of Address and Port using Translation (MAP-T)" Section 10.1: Fragmentation in the MAP Domain
https://tools.ietf.org/html/rfc7599#section-10.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE properly translates ICMPv4 packets |
mapt.tcl |
mapt_40 |
Verify MAP-T CE properly translates ICMPv4 packets |
step 1. Send an ICMPv4 packet from the LAN to a destination outside the MAP
domain on the WAN
step 2. Verify that an ICMPv6 packet is received on the WAN
step 3. Verify the IPv6 source and destination addresses of the translated
packet
step 4. Verify that the IPv6 Next Header field is set to 58 (ICMPv6) in the
translated packet or that the packet contains a Fragmentation Header
with a Next Header value of 58 (ICMPv6).
References:
RFC 6145 Section 4: "Translating from IPv4 to IPv6"
When the IPv4 sender does not set the DF bit, the translator SHOULD always
include an IPv6 Fragment Header to indicate that the sender allows
fragmentation. The translator MAY provide a configuration function that
allows the translator not to include the Fragment Header for the
non-fragmented IPv6 packets.
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.1: Translating IPv4 Headers into IPv6 Headers
Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58);
otherwise, the protocol field MUST be copied from the IPv4 header.
https://tools.ietf.org/html/rfc6145#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE drops unsupported ICMPv4 message types |
mapt.tcl |
mapt_41 |
Verify MAP-T CE drops unsupported ICMPv4 message types |
step 1. Send an ICMPv4 packet of type 9 from the LAN to a destination
outside the MAP domain on the WAN
step 2. Verify that no ICMPv6 packets are received on the WAN
step 3. Repeat steps 1 and 2 for ICMPv4 packets of type 10, 13, 14, 15, 16,
17, 18, and 255
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.2: Translating ICMPv4 Headers into ICMPv6 Headers
Section 4.2 lists several ICMPv4 message types that should be silently
dropped by the MAP-T CE.
https://tools.ietf.org/html/rfc6145#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify MAP-T CE translates ICMPv4 Destination Unreachable codes into ICMPv6 |
mapt.tcl |
mapt_42 |
Verify MAP-T CE translates ICMPv4 Destination Unreachable codes into ICMPv6 |
step 1. Send an IPv4 UDP packet from LAN to WAN
step 2. Verify IPv4 UDP packet is received on WAN side
step 3. Send an IPv4 UDP packet from WAN to LAN
step 4. Verify IPv4 UDP packet is received on LAN side
step 5. Send an ICMPv4 Destination Unreachable packet with a Code of 0 from
the LAN to a destination outside the MAP domain on the WAN
step 6. Verify that an ICMPv6 packet is received on the WAN
step 7. Verify that the ICMPv6 code is translated according to the rules
defined in Section 4.2 of RFC 6145
step 8. Repeat steps 1 through 7 for ICMPv4 unreachable packets with codes
of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, and 16
References:
IETF RFC 6145 "IP/ICMP Translation Algorithm" Section 4.2: Translating ICMPv4 Headers into ICMPv6 Headers
https://tools.ietf.org/html/rfc6145#section-4.2
ipsec-esp-v6.tcl
IPv6 IPSEC ESP tests for IPSEC based VPNs
| Test |
Module |
Name |
Synopsis |
Verify the ESP header sequence number increases with each new IPv6 IPSEC ESP packet |
ipsec-esp-v6.tcl |
ipv6_esp_1 |
Verify the ESP header sequence number increases with each new IPv6 IPSEC ESP packet |
step 1. Initiate 100 outbound ICMP Echo Requests to the remote VPN host
step 2. Outbound traffic should be sent through IPSEC tunnel
step 3. Verify the sequence number in the IPSEC ESP header increments by 1
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 2.2: Sequence Number
https://tools.ietf.org/html/rfc2406#section-2.2
| Test |
Module |
Name |
Synopsis |
Verify manual IPv6 IPSEC keys continue to work after ESP sequence number wraps |
ipsec-esp-v6.tcl |
ipv6_esp_3 |
Verify manual IPv6 IPSEC keys continue to work after ESP sequence number wraps |
step 1. Set the current sequence number for the outbound SA to 0xfffffffe
step 2. Initiate 10 outbound ICMP Echo Requests to the remote VPN host
step 3. Outbound traffic should be sent through IPSEC tunnel
step 4. Verify all packets are received as IPSEC ESP sequence number wraps
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements
https://tools.ietf.org/html/rfc2406#section-5
| Test |
Module |
Name |
Synopsis |
Verify no anti-relay techniques are used with manual IPv6 IPSEC keys |
ipsec-esp-v6.tcl |
ipv6_esp_5 |
Verify no anti-relay techniques are used with manual IPv6 IPSEC keys |
step 1. Initiate 10 outbound ICMP Echo Requests to the remote host
step 2. Before each packet is sent, reset the ESP sequence number
to 11221122 so that all outbound packets have the same
sequence number.
step 3. Outbound traffic should be sent through IPSEC tunnel
step 4. Verify all packets are sent and received with no errors
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements
https://tools.ietf.org/html/rfc2406#section-5
| Test |
Module |
Name |
Synopsis |
Verify inner IPv6 Hop Limit is decremented for IPSEC tunneled packet |
ipsec-esp-v6.tcl |
ipv6_esp_8 |
Verify inner IPv6 Hop Limit is decremented for IPSEC tunneled packet |
step 1. Forward an IPv6 packet from a LAN client to the WAN
step 2. Verify the Hop Limit of the tunneled packet is decremented by 1
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.1.2: Header Construction for Tunnel Mode
https://tools.ietf.org/html/rfc2401#section-5.1.2
| Test |
Module |
Name |
Synopsis |
Verify IPv6 packets with wrong ESP authentication are dropped |
ipsec-esp-v6.tcl |
ipv6_esp_10 |
Verify IPv6 packets with wrong ESP authentication are dropped |
step 1. Initiate an outbound ICMP Echo Request to a WAN destination
step 2. Verify ICMP Echo Reply is received
step 3. Configure outbound SA with invalid authentication key
step 4. Repeat outbound ICMP Echo Request
step 5. Verify return ICMP Echo Reply is dropped
step 6. Reconfigure original ESP authentication key
step 7. Verify outbound ICMP Echo Request now succeeds
NOTE: This test is only run when the configured IPSEC tunnel has
authentication enabled.
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.4.5: Packet Decryption
https://tools.ietf.org/html/rfc2406#section-3.4.5
| Test |
Module |
Name |
Synopsis |
Verify Incoming IPv6 fragments for ESP tunnel are reassembled |
ipsec-esp-v6.tcl |
ipv6_esp_20 |
Verify Incoming IPv6 fragments for ESP tunnel are reassembled |
step 1. Send a 5000 byte UDP packet from the LAN to the WAN
step 2. Send a return 5000 byte UDP packet from the WAN to the LAN
over the IPSEC tunnel. The IPSEC packet will be fragmented
based on the MTU size.
step 3. Verify router reassembled all IP fragments and forwards UDP
packet to the LAN host
References:
IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly
https://tools.ietf.org/html/rfc791#section-3.2
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.2: Processing Inbound IP Traffic
https://tools.ietf.org/html/rfc2401#section-5.2
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location
https://tools.ietf.org/html/rfc2406#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify out-of-order IPv6 fragments for ESP tunnel are reassembled |
ipsec-esp-v6.tcl |
ipv6_esp_21 |
Verify out-of-order IPv6 fragments for ESP tunnel are reassembled |
step 1. Send a 5000 byte UDP packet from the LAN to the WAN
step 2. Send a return 5000 byte UDP packet from the WAN to the LAN
over the IPSEC tunnel using out of order IPv6 fragments
step 3. Verify router reassembled all out-of-order IPv6 fragments
and forwards UDP packet to the LAN host
References:
IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly
https://tools.ietf.org/html/rfc791#section-3.2
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location
https://tools.ietf.org/html/rfc2406#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify router supports PMTU discovery for packets sent over IPSEC tunnel |
ipsec-esp-v6.tcl |
ipv6_esp_100 |
Verify router supports PMTU discovery for packets sent over IPSEC tunnel |
step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
remoteVpn host over the IPSEC tunnel
step 2. Check for an ICMP Destination Unreachable packet with code = 4
step 3. Repeat process two more times until until an ICMP Destination
Unreachable is received, or all 3 packets are sent
step 4. If an ICMP Destination Unreachable was sent, verify the
the code value is 4 and verify MTU value in the ICMP header
step 5. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMP Destination Unreachable is sent
step 6. When a packet size is found that does not generate an
ICMP Destination Unreachable, verify packets can be forwarded over
IPSEC tunnel using this packet size
step 7. Verify the final MTU size is the same as the MTU size
reported in the ICMP Destination Unreachable packet
NOTE: Some devices rate limit the number of ICMP packets that may be
sent. This test will sent 3 UDP packets over a 15 second window
in order to generate an ICMP unreachable packet. If your device
uses rate limiting on ICMP packets, it must allow at least 1
ICMP packet every 10 seconds.
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing
https://tools.ietf.org/html/rfc2401#section-6.1
IETF RFC 1191 "Path MTU Discovery"
https://tools.ietf.org/html/rfc1191
| Test |
Module |
Name |
Synopsis |
Verify return IPv6 traffic that does not use IPSEC/ESP is dropped |
ipsec-esp-v6.tcl |
ipv6_esp_200 |
Verify return IPv6 traffic that does not use IPSEC/ESP is dropped |
step 1. Forward UDP packet from LAN to remote VPN host
step 2. Verify packet is forwarded over IPSEC tunnel to remote VPN host
step 3. Send a return UDP packet from the remote VPN host without
encapsulating the packet with an ESP header
step 4. Verify the packet is not forwarded back to the LAN
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 4.4.1: The Security Policy Database (SPD)
https://tools.ietf.org/html/rfc2401#section-4.4.1
| Test |
Module |
Name |
Synopsis |
Verify all configured IPv6 IPSEC tunnels are operational |
ipsec-esp-v6.tcl |
ipv6_esp_400 |
Verify all configured IPv6 IPSEC tunnels are operational |
step 1. Configure SAs for all IPSEC tunnels defined in the configuration file
step 2. For each tunnel, verify a TCP connection can be established
from the LAN host to a remote host over the IPSEC tunnel
step 3. Close all TCP connections
ipsecpt-v6.tcl
IPv6 IPSEC based VPN pass through from the LAN to the WAN
| Test |
Module |
Name |
Synopsis |
Verify IPv6 IKE packets pass through router on UDP port 500 |
ipsecpt-v6.tcl |
ipv6_ipsecpt_1 |
Verify IPv6 IKE packets pass through router on UDP port 500 |
step 1. Send an IPSEC packet from LAN to WAN
step 2. Verify the packet is received on the WAN
step 3. Send an IPSEC packet from WAN to LAN
step 4. Verify the packet is received on the LAN
| Test |
Module |
Name |
Synopsis |
Verify tunnel mode IPv6 IPSEC packets pass through router |
ipsecpt-v6.tcl |
ipv6_ipsecpt_2 |
Verify tunnel mode IPv6 IPSEC packets pass through router |
step 1. Send a tunnel mode IPSEC packet from LAN to WAN
step 2. Verify the packet is received on the WAN
step 3. Send a tunnel mode IPSEC packet from WAN to LAN
step 4. Verify the packet is received on the LAN
Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Fragmented tunnel mode IPv6 IPSEC packets are forwarded between LAN and WAN |
ipsecpt-v6.tcl |
ipv6_ipsecpt_3 |
Fragmented tunnel mode IPv6 IPSEC packets are forwarded between LAN and WAN |
step 1. Send a large, fragmented tunnel mode IPSEC packet from LAN to WAN
step 2. Verify the packet is received on the WAN
step 3. Send a large, fragmented tunnel mode IPSEC packet from WAN to LAN
step 4. Verify the packet is received on the LAN
Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of IPv6 IPSEC connections for a single LAN host |
ipsecpt-v6.tcl |
ipv6_ipsecpt_100 |
Verify the maximum number of IPv6 IPSEC connections for a single LAN host |
step 1. Send a tunnel mode IPSEC packet from LAN to unique WAN IP address
step 2. Verify the packet is received on the WAN
step 3. Send a tunnel mode IPSEC packet from WAN to LAN
step 4. Verify the packet is received on the LAN
step 5. Repeat steps 1 through 4 N times, where N is specified by the
ipsecMaxTunnels testvar
Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 IPSEC connections with multiple LAN clients using same VPN server |
ipsecpt-v6.tcl |
ipv6_ipsecpt_110 |
Verify IPv6 IPSEC connections with multiple LAN clients using same VPN server |
step 1. Start new IPv6 client on the LAN (named vpn2)
step 2. Send an IPSEC packet from the primary LAN stack to the VPN server on
WAN
step 3. Send an IPSEC packet LAN client vpn2 to the VPN server on WAN
step 4. Verify both packets are received by the VPN server
step 5. Send a return IPSEC packet to each LAN client using unique SPI
step 6. Verify each LAN client receives IPSEC packet with correct SPI
Note: Tunnel mode IPSEC packets are sent as IPv6 protocol 50 (ESP).
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
Note: Each LAN client sends a IPSEC packet to the same VPN server using
unique SPI values in the ESP header. IPSEC packets sent back from the
WAN use the SPI value.
| Test |
Module |
Name |
Synopsis |
Verify IPv6 IKE with multiple LAN clients using same VPN server |
ipsecpt-v6.tcl |
ipv6_ipsecpt_120 |
Verify IPv6 IKE with multiple LAN clients using same VPN server |
step 1. Start new IPv6 client on the LAN (named vpn2)
step 2. Send an IPSEC IKE packet from the primary LAN stack to the VPN
server on WAN
step 3. Send an IPSEC IKE packet LAN client vpn2 to the VPN server on WAN
step 4. Verify both packets are received by the VPN server
step 5. Send return IKE packet to each LAN client
step 6. Verify each LAN client receives correct IKE packet
Note: Each LAN client uses a unique ISAKMP cookie for the initiator and
responder cookies. There are two common techniques used to multiplex
multiple IKE connections all originating from port 500. Some routers
will change the IKE source port to another UDP port. This solution
does not work for all VPN servers which may not accept IKE traffic if
the UDP source port is not 500. Other routers will track the initiator
and responder cookies in the ISAKMP messages in order to demultiplex
incoming IKE packets. This test will succeed if either technique is
used.
