IPv6
basic-v6 (16)
Basic IPv6 extension header processing tests
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
Reference:
IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6
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
Reference:
IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6
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
Reference:
IETF RFC2460 Section 4:
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.
IETF RFC4443 Section 3.4:
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.
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
Reference:
IETF RFC2460 Section 4:
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.
IETF RFC4443 Section 3.4:
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.
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
Reference:
IETF RFC2460 Section 4.7:
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.
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.
Reference:
IETF RFC2460 Section 4.7:
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.
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 7 (0x07). Option Type 7 contains high order bits of
00.
Hop-by-Hop Options Header:
Next Header = 0x3a (ICMP)
Length = 0x00 (8 bytes)
Option Type = 0x07 (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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
IETF RFC2460 Section 4.3:
The Hop-by-Hop Options header is used to carry optional information
that must be examined by every node along a packet's delivery path.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
IETF RFC2460 Section 4.3:
The Hop-by-Hop Options header is used to carry optional information
that must be examined by every node along a packet's delivery path.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
IETF RFC2460 Section 4.3:
The Hop-by-Hop Options header is used to carry optional information
that must be examined by every node along a packet's delivery path.
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 nodes 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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
IETF RFC2460 Section 4.3:
The Hop-by-Hop Options header is used to carry optional information
that must be examined by every node along a packet's delivery path.
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 nodes 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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.2:
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.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC5095 Section 3:
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.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC5095 Section 3:
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.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.4:
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.
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 Phase-1/Phase-2 Test Specification Core Protocols
http://ipv6ready.org/docs/Core_Conformance_Latest.pdf
IETF RFC2460 Section 4.4:
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 1, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
frag-v6 (3)
IPv6 fragmentation tests
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
Reference:
IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6
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
Reference:
IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6
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
Reference:
IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6
ndp (13)
Neighbor Discovery Protocol and Router Advertisement tests for IPv6 devices
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
NOTE: The testvar ipv6RAInterval will control how long this test waits for a
Router Advertisement.
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
ipv6_ndp_13
Verify DUT responds to DAD-style Neighbor Solicitations
step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's link-local address
step 2. Wait for a Neighbor Advertisement from the DUT
step 3. Verify source, destination, and contents of Neighbor Advertisement
Reference: IETF RFC 2462 - IPv6 Stateless Address Autoconfiguration
Section 5.4 Duplicate Address Detection
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
Section 8 Redirect Function
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.
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
Section 4.2 "Router Advertisement Message Format"
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
Section 4.6.2 "Prefix Information"
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.
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
Reference: IETF RFC 6106 - IPv6 Router Advertisement Options for DNS
Configuration
NOTE: This test is skipped if the testvar ipv6RdnssSupport is set to no
indicating that the device does not support the RDNSS option.
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
Reference: IETF RFC 6106 - IPv6 Router Advertisement Options for DNS
Configuration
NOTE: This test is skipped if the testvar ipv6DnsslSupport is set to no
indicating that the device does not support the DNSSL option.
ndp-wan (8)
Neighbor Discovery Protocol and Router Advertisement tests for the WAN side of IPv6 devices
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
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.
Reference: RFC 4861 - Neighbor Discovery for IPv6
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
ipv6_ndp_wan_11
Verify DUT responds to Neighbor Solicitations from 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
Reference: RFC 4861 - Neighbor Discovery for IPv6
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
ipv6_ndp_wan_13
Verify DUT responds to DAD-style Neighbor Solicitations on the WAN
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 2462 - IPv6 Stateless Address Autoconfiguration
Section 5.4 Duplicate Address Detection
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
dhcpv6-c (20)
DHCPv6 client tests for the WAN side of the router
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
Reference: IETF RFC 3315 Section 17 "DHCP Server Solicitation"
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"
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
Reference: IETF RFC 3315 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.
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
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
Reference: IETF RFC 3315 Section 18.1 "Client Behavior"
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
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)"
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
Reference: IETF RFC 3315 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
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 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.
Reference: IETF RFC 3315 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.
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.
Reference: IETF RFC 3315 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.
NOTE: This test will not work if Rapid-Commit is used!
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 Section 18.1 "Client Behavior"
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
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 Section 22.12 "Server Unicast Option"
dhcpv6-pd (18)
DHCPv6 prefix delegation tests for WAN to LAN IPv6 configuration
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
Reference: IETF RFC 3633 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.
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
Reference: IETF RFC 3633 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.
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
Reference: IETF RFC 3633 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.
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement 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.
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
Reference: IETF RFC 3633 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.
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
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
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
dhcpv6_pd_15
Verify DUT does not advertise itself as a default router when WAN link is down
step 1. Bring down WAN link
step 2. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 3. Verify that the advertised Router Lifetime is not greater
than 0, or that the router advertisement does not contain
Prefix Information option (3) with valid prefix based on
prefix assigned by DHCPv6 server on WAN
step 4. Bring up WAN link
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement 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].
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement G-5:
By default, if the IPv6 CE router is an advertising
router and loses its IPv6 default router(s) 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].
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
Reference: IETF RFC 3633 Section 12.1 "Requesting router behavior"
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
Reference: IETF RFC 3633 Section 12.1 "Requesting router behavior"
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3315 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.
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
Reference: IETF RFC 3633 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.
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 client updates router advertisements on LAN with new
prefix information
step 6. Verify 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
Reference: IETF RFC 3633 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.
NOTE: This test only applies to configurations where LAN clients
obtain IPv6 addresses via DHCPv6
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
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement W-5:
DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
(IA_PD) SHOULD be done as a single DHCPv6 session.
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 an UDP echo to this destination from the LAN client
step 4. Verify the packet is not forwarded to the WAN
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement WPD-6:
If the delegated prefix(es) are aggregate route(s) of
multiple, more-specific routes, the IPv6 CE router MUST
discard packets that match the aggregate route(s), but not
any of the more-specific routes. In other words, the next-
hop for the aggregate route(s) 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.
NOTE: This test is only applicable if the delegated prefix length
is less than 64.
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
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 6204 - IPv6 CE Router Requirements, Requirement 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.
dhcpv6-s (38)
DHCPv6 server tests for the LAN side of the router
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
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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
Reference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"
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 respond to unicast DHCPv6 Solicit
messages from 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
Reference: IETF RFC 3315 Section 13 "Transmission of Messages by a 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.
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
Reference: IETF RFC 3646
dhcpv6_server_10
Verify server ignores requests with mismatched server DUID
step 1. Modify client to use an unknown server DUID
step 2. Restart DHCPv6 on client with sending Release to the server
step 3. Verify that server does not reply to Renew with unknown server DUID
Reference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"
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
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
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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
Reference: IETF RFC 3315 Section 18.2 "Server Behavior"
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
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
Reference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"
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
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.2 "Receipt of Confirm Messages"
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'
Reference: IETF RFC 3315 Section 18.2.2 "Receipt of Confirm Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.2 "Receipt of Confirm Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"
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'
Reference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.4 "Receipt of Rebind Messages"
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
Reference: IETF RFC 3315 Section 18.2.4 "Receipt of Rebind Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.5 "Receipt of Information-request Messages"
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
Reference: IETF RFC 3315 Section 18.2.6 "Receipt of Release Messages"
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
Reference: IETF RFC 3315 Section 18.2.6 "Receipt of Release Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.6 "Receipt of Release Messages"
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.
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
Reference: IETF RFC 3315 Section 18.2.7 "Receipt of Decline Messages"
dhcpv6_server_81
Verify server sends UseMulticast status code when client sends unicast DHCPv6 Decline
step 1. Initiate a DHCPv6 Decline fro 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
Reference: IETF RFC 3315 Section 18.2.7 "Receipt of Decline Messages"
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.
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'
Reference: IETF RFC 3315 Section 18.2.7 "Receipt of Decline Messages"
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.
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.
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
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
Reference: IETF RFC 3315 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.
dhcpv6_server_110
Verify server assigns same IPv6 address when client requests both IA_NA and IA_PD
step 1. Configure client to send DHCPv6 Request with 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
dhcpv6_server_111
Verify server assigns same IPv6 address when client requests both IA_NA and IA_TA
step 1. Configure client to send DHCPv6 Request with 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
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
Reference: IETF RFC 3315 Section 20 "Relay Agent Behavior"
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.
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
Reference: IETF RFC 3315 Section 20 "Relay Agent Behavior"
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.
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.
pppoe-c-v6 (11)
PPPoE client tests with IPv6 on the WAN side of the router
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
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).
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
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
RFC 1548 The Point-to-Point Protocol
5.8 Echo-Request and Echo-Reply
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.
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 restablished
Reference: RFC 5072 IP Version 6 over PPP
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).
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).
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).
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.
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
Reference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)
Section 8. Other Considerations
From RFC 2516 "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."
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).
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
Reference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)
Appendix A. AC-Cookie
From RFC 2516 "If a Host receives this TAG, it MUST return the TAG
unmodified in the following PADR."
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
Reference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)
Appendix A. Relay-Session-Id
From RFC 2516 "If either the Host or Access Concentrator receives this TAG they
MUST include it unmodified in any discovery packet they send as a response."
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.
6to4 (14)
6to4 tunnel tests for connecting IPv6 hosts over IPv4 networks
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 5.1 Simple scenario - all sites work the same
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 5.2 Mixed scenario with relay to native IPv6
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
setp 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
IPv4 address
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 5.2 Mixed scenario with relay to native IPv6
ipv6_6to4_13
Verify encapsulating IPv4 header for 6to4 does not have the DF flag set
step 1. Forward IPv6 UDP to remoteHostv6 address
step 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packet
setp 3. Verify 'do not fragment' flag is not set on IPv4 header
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 4. Maximum Transmission Unit
The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating
IPv4 header.
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 4. Maximum Transmission Unit
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
6rd (14)
6rd tunnel tests for connecting IPv6 hosts over IPv4 networks
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
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
Reference: RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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.
NOTE: The testvar wanIspNextIp must be properly configured in order
for this test to work correctly. Both wanIspNextIp and wanIspAssignIp
must be in the same WAN network.
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
setp 3. Verify IPv4 src address of tunneled IPv6 traffic matches WAN
IPv4 address
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
ipv6_6rd_13
Verify encapsulating IPv4 header for 6rd does not have the DF flag set
step 1. Forward IPv6 UDP to remoteHostv6 address
step 2. Verify 6rd relay server on the WAN received tunneled IPv6 packet
setp 3. Verify 'do not fragment' flag is not set on IPv4 header
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
Reference: RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
Section 4. Maximum Transmission Unit
The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating
IPv4 header.
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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
Reference: RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
Section 2. IPv6 Prefix Allocation
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
icmp-v6 (16)
ICMPv6 tests for baseline ICMPv6 not including Neighbor Discovery
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
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
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
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
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 expcted to work or not. It defaults to "no" which signifies that the device will not
respond to IPv6 pings on its WAN interface.
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
icmpv6_7
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a global prefix
step 1. Initiaite an outbound ICMPv6 Ping to ff02::2 from the global-prefix
step 2. Verify ICMPv6 Echo Reply is received
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
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
icmpv6_10
Verify ICMPv6 Time Exceeded packet is sent when incoming Hop Limit is 1
step 1. Set the IP Hop Limit of outbound packets to 1
step 2. Forward an IPv6 packet from a LAN client to the WAN
step 3. Verify ICMPv6 Time Exceeded packet is sent to initial LAN host
step 4. Verify the ICMPv6 Time Exceeded packet contains the IP header of the original packet
Reference:
RFC 2463
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
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
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
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
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
Reference: RFC 1981: Path MTU Discovery for IP version 6
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. If the interface
has VLANs enabled, the initial MTU will be 1496 bytes.
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.
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.
Reference: RFC 1981: Path MTU Discovery for IP version 6
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. If the interface
has VLANs enabled, the initial MTU will be 1496 bytes.
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.
firewall-v6 (18)
IPv6 Firewall tests including port scans
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
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
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"
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"
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"
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.
ipv6_firewall_505
Verify outbound packets with forbidden source address 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
Reference: RFC 6092 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.
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
Reference: RFC 6092 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.
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
Reference: RFC 6092 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.
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
Reference: RFC 6092 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.
ipv6_firewall_510
Verify outbound packets with unique 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
Reference: RFC 6092 Section 3.1 "Stateless Filters"
REC-7: By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or from
the exterior network.
ipv6_firewall_511
Verify inbound packets with unique 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 3. Verify traffic is not forwarded to the LAN
Reference: RFC 6092 Section 3.1 "Stateless Filters"
REC-7: By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or from
the exterior network.
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
Reference: RFC 6092 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.
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
Reference: RFC 6092 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.
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
Reference:
IETF RFC 6092
Simple Security in IPv6 Gateway CPE
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.
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
Reference:
IETF RFC 6092
Simple Security in IPv6 Gateway CPE
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.
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
Reference:
IETF RFC 6092
Simple Security in IPv6 Gateway CPE
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.
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
Reference:
IETF RFC 6092
Simple Security in IPv6 Gateway CPE
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.
firewall-out-v6 (3)
IPv6 Firewall tests for limiting outbound access to services
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 firewallOutBlockedTcpPorts testvar is used to determine the list of TCP ports
that the DUT has been configured to block access to.
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 firewallOutBlockedUdpPorts testvar is used to determine the list of UDP ports
that the DUT has been configured to block access to.
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 firewallOutBlockedIpProtos testvar is used to determine the list of IP Protocol types
that the DUT has been configured to block access to.
apps-v6 (10)
Application tests for IPv6
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
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
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 real DNS server 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.
Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses
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
Reference: RFC 2428 FTP Extensions for IPv6 and NATs
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
Reference:
RFC 821 Simple Mail Transfer Protocol
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
Reference:
RFC 1939 Post Office Protocol Version 3
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
Reference:
RFC 1350 TFTP Protocol Version 2
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
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
Reference: RFC 3489 STUN
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
Reference: RFC 3489 STUN
forward-v6 (5)
IPv6 forwarding tests with different packet sizes and directions
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
Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) Specification
Section 3. IPv6 Header Format
NOTE: Decremented by 1 by each node that forwards the packet.
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
Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) Specification
Section 3. IPv6 Header Format
NOTE: The packet is discarded if Hop Limit is decremented to zero.
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.
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
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 (5)
Jumbo MTU IPv6 forwarding tests with different packet sizes and directions
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
Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) Specification
Section 3. IPv6 Header Format
NOTE: Decremented by 1 by each node that forwards the packet.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
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
Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) Specification
Section 3. IPv6 Header Format
NOTE: The packet is discarded if Hop Limit is decremented to zero.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
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.
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
ipv6_jumbo_11
Forward jumbo MTU IPv6 UDP packets with various packet lengths (WAN to LAN)
scaling-v6 (3)
Scaling tests for maximum number of IPv6 clients and connections (TCP, HTTP, etc)
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 client DHCPv6 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.
ipv6_scale_2
Verify all IPv6 clients with multiple TCP connections
step 1. Determine the size of the client DHCPv6 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.
ipv6_scale_3
Verify all IPv6 clients with single UDP connection
step 1. Determine the size of the client DHCPv6 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 1 outbound UDP connection
step 7. Verify each client can send/receive data over each 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.
dslite (9)
DS-Lite tests for tunneling IPv4 over IPv6
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
Reference: RFC 6333 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.
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
Reference: RFC 6333 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.
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
Reference: RFC 6333 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.
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
Reference: RFC 6333 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.
Reference: RFC 2473 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.
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
step 3. Forward an additional IPv4 packet from a LAN client to the WAN with same size
step 4. Verify packet is not forwarded to the WAN
Reference: RFC 6333 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.
Reference: RFC 2473 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.
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
Reference: RFC 6333 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.
Reference: RFC 2473 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.
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.
Reference: RFC 6333 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.
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
Reference: RFC 6333 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.
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
Reference: RFC 6333 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.
dns-v6 (20)
IPv6 DNS proxy and DNS failover related tests
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 LAN client
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
Reference: RFC 1035
Section 3.2.1 Format
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
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 LAN client
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
Reference: RFC 1035
Section 3.2.1 Format
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
ipv6_dns_40
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server
step 1. Initiate an AAAA IPv6 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. 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.
Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses
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 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. 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.
Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses
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, configure the primary DNS server to
return the error code, and the backup to return the normal
response
step 3. All responses will have the authoritative bit set
step 4. Send 3 DNS queries for a new hostname to router's lanIp
step 5. Verify a valid DNS response is received if the error
code is expected to trigger DNS failover
step 6. Configure the primary DNS server back to normal operation
and configure the backup to return the DNS error
step 7. Send 3 DNS queries for a new hostname to router's lanIp
step 8. Verify a valid DNS response is received if the error
code is expected to trigger DNS failover
NOTE: This test sets up the failover to happen from primary to
backup in the first part and then backup to primary. This is
required for implmentations that maybe load balancing DNS across
the DNS servers or may have already failed all future requests to
the primary or backup.
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 'dnsFailoverErrorCodes'. 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).
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, configure the primary DNS server to
return the error code, and the backup to return the normal
response
step 3. All responses will have the authoritative bit set
step 4. Send 3 DNS queries for a new hostname to router's lanIp
step 5. Verify a valid DNS response is received if the error
code is expected to trigger DNS failover
step 6. Confgiure the primary DNS server back to normal operation
and configure the backup to return the DNS error
step 7. Send 3 DNS queries for a new hostname to router's lanIp
step 8. Verify a valid DNS response is received if the error
code is expected to trigger DNS failover
NOTE: This test sets up the failover to happen from primary to
backup in the first part and then backup to primary. This is required
for implmentations that maybe load balancing DNS across the DNS servers
or may have already failed all future requests to the primary or backup.
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).
ipv6_dns_50
Verify Reverse DNS queries to router are forwarded to real DNS server
step 1. Initiate a reverse 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. 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.
ipv6_dns_51
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server
step 1. Initiate a reverse 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. 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.
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 LAN client
step 4. Verify LAN client receives response from new DNS servers
step 5. 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.
ipv6_dns_70
Verify IPv6 DNS lookups with multiple IPv4 responses
step 1. Initiate a DNS lookup for a new unique hostname from LAN client
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
Reference: RFC 1035
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
step 4. Enable all DNS servers
step 5. Verify DNS looks 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.
ipv6_dns_110
Verify IPv6 DNS queries including the EDNS0 option
step 1. Initiate a DNS lookup for a new unique hostname from LAN client
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
Reference: RFC 1035
Section 3.2.1 Format
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
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 LAN client
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 2671 Extension Mechanisms for DNS (EDNS0)
ipv6_dns_121
Verify maximum UDP payload value in EDNS0 option
step 1. Initiate a DNS lookup for a unique hostname from LAN client
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
Reference: RFC 2671 Extension Mechanisms for DNS (EDNS0)
ipv6_dns_130
Verify IPv6 DNS queries for TXT records
step 1. Initiate a DNS TXT query to the router's LAN IPv4 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. Send a return TXT 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.
Reference: RFC 1035 Domain names - implementation and specification
ipv6_dns_140
Verify IPv6 DNS queries for SPF records
step 1. Initiate a DNS SPF query to the router's LAN IPv4 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. Send a return SPF 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.
Reference: RFC 4408
Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1
ipv6_dns_150
Verify IPv6 DNS proxy does not forward DNS server status requests
step 1. Send an IPv6 DNS server status request from LAN client
step 2. Verify the DNS proxy does not forward the request to the
real DNS server
NOTE: Scanning tools including nmap utilize DNS server status
requests when probing a host.
Reference: draft-hall-status-opcode-00-1
Section 6 Security Considerations
ipv6_dns_200
Verify IPv6 DNS proxy does not mangle DNSSEC queries
step 1. Initiate a DNSKEY query to the router's LAN IPv6 address
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.
Reference: RFC 4034
Resource Records for the DNS Security Extensions
ipv6_dns_201
Verify IPv6 DNS proxy does not mangle large DNSSEC responses
step 1. Initiate a DNSKEY query to the router's LAN IPv6 address
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.
Reference: RFC 4035
Section 4.1 EDNS Support
ipv6_dns_300
Verify IPv6 DNS proxy honors TTL values when caching responses
step 1. Perform a DNS lookup on a hostname from the LAN via IPv6
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
Reference: RFC 1035 Domain Names - Implementation and Specification
Section 4.1.3 Resource Record format
url-filter-v6 (6)
IPv6 URL filtering tests for LAN side HTTP clients
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.
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.
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.
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.
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.
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 (24)
MLDv1/v2 and multicast data tests for IPv6 MLD proxy
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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 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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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 10 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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 10 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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
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 occured
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 occured
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.
Reference: RFC 2710 Multicast Listener Discovery for IPv6
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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.
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 10 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
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 10 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
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 10 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
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
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 occured
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.
Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6
ula (15)
IPv6 unique local address (ULA) test module
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
References: IETF RFC 4861 - Neighbor Discovery for IPv6
Section 4.6.2 "Prefix Information"
IETF RFC 4193 - Unique Local IPv6 Unicast Addresses
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
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
References: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement 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.
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
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
References: IETF RFC 4861 - Neighbor Discovery for IPv6
Section 4.6.2 "Prefix Information"
IETF RFC 4193 - Unique Local IPv6 Unicast Addresses
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.
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
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
Reference: IETF RFC 4861 - Neighbor Discovery for IPv6
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
Reference: RFC 4861 - Neighbor Discovery for IPv6
ula_10
Verify unique local prefix is advertised when WAN link is down
step 1. Bring down WAN link
step 2. Listen for IPv6 Router Advertisements on the LAN from DUT
step 3. Verify that the Router Advertisement contains a valid prefix
information option for the expected unique local prefix
step 4. Bring up WAN link
Reference: IETF RFC 6204 - IPv6 CE Router Requirements
Section 4.3: LAN-Side Configuration
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
ula_11
Verify Route Information option for unique local prefix is valid when WAN link is down
step 1. Bring down WAN link
step 2. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 3. Verify that the Router Advertisement contains a valid prefix
information option for the expected unique local prefix
step 4. Verify that the Router Advertisement contains a valid route
information option for the expected unique local prefix
step 5. Bring up WAN link
Reference: IETF RFC 6204 - IPv6 CE Router Requirements
Section 4.3: LAN-Side Configuration
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
ula_12
Verify DUT does not advertise itself as a default router when WAN link is down
step 1. Bring down WAN link
step 2. Listen for Router Advertisements on the LAN for up to one Router
Advertisement interval
step 3. Verify that the Router Advertisement contains only prefix
information options for unique local prefixes
step 4. Verify that the advertised Router Lifetime is not greater than 0
step 5. Bring up WAN link
Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement 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.
NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
expected unique local prefix advertised by the DUT.
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
ula_21
Verify DUT responds to ICMPv6 Echo Requests to the All-Routers group from a unique local prefix
step 1. Initiaite an outbound ICMPv6 Ping to ff02::2 from the LAN client's
unique local address
step 2. Verify ICMPv6 Echo Reply is received
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
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
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
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
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
static-v6 (4)
IPv6 static route related tests
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.
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.
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
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 (27)
IPv6 Forum CE (CPE) Conformance Test Specification tests
v6_cpe_1_1_a
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. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 0 seconds
Prefix Information Option:
Type = 3
L-flag = 0
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. The DUT Transmits an Echo Request to PF2::a.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must not perform any address resolution.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.1 RA Prefix Information Option L-Flag
Part A: L-flag = 0 without Default Router
v6_cpe_1_1_b
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. TR1 transmits RA2 on the WAN network.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 0 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. The DUT Transmits an Echo Request to PF2::a.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must perform address resolution.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.1 RA Prefix Information Option L-Flag
Part B: L-flag = 1 without Default Router
v6_cpe_1_1_c
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. TR1 transmits RA3 on the WAN network.
RA3
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 0
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. The DUT Transmits an Echo Request to PF2::a.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must not perform any address resolution and transmits the Echo
Request to TR1.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.1 RA Prefix Information Option L-Flag
Part C: L-flag = 0 with Default Router
v6_cpe_1_1_d
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. TR1 transmits RA4 on the WAN network.
RA4
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. The DUT Transmits an Echo Request to PF2::a.
step 3. Observe the packets transmitted on the WAN.
Observable Results:
step 3. The DUT must perform address resolution.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.1 RA Prefix Information Option L-Flag
Part D: L-flag = 1 with Default Router
v6_cpe_1_2
DHCPv6 Option: Reconfigure Accept Option
Purpose: Verify that the DUT supports the DHCPv6 Reconfigure Accept Option.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 1
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TR1 transmits an Echo Request to the DUT's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT transmits packets as per the DHCPv6 basic message exchange.
The DUT transmits Solicit and Request messages. The DHCPv6 server
replies with Advertise and Reply messages respectively.
DHCPv6 Solicit Message DHCPv6 Request Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 1 Message Type = 3
Reconfigure Accept Option: Reconfigure Accept Option:
Option Code = 20 Option Code = 20
Option Length = 0 Option Length = 0
IA_PD Option: IA_PD Option:
Option Code = 25 Option Code = 25
IA_PD Prefix Option:
Option Code = 26
Pref. Lifetime = 600
Valid Lifetime = 600
Prefix Length = 60
IPv6 Prefix = PF1
DHCPv6 Advertise Message DHCPv6 Reply Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 2 Message Type = 7
Reconfigure Accept Option: Reconfigure Accept Option:
Option Code = 20 Option Code = 20
Option Length = 0 Option Length = 0
IA_PD Option: IA_PD Option:
Option-Code = 25 Option-Code = 25
IA_PD Prefix Option: IA_PD Prefix Option:
Option Code = 26 Option Code = 26
Pref. Lifetime = 600 Pref. Lifetime = 600
Valid Lifetime = 600 Valid Lifetime = 600
Prefix Length = 60 Prefix Length = 60
IPv6 Prefix = PF1 IPv6 Prefix = PF1
step 4. The DUT must transmit an Echo Reply to TR1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.2 DHCPv6 Option: Reconfigure Accept Option
v6_cpe_1_3
RA M-flag is Set
Purpose: Verify that the DUT initiates DHCPv6 address assignment process
when the M-flag is set in a received RA.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 1
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. Wait for the DUT to configure a global address.
step 4. TN3 transmits an Echo Request to the DUT's global address.
step 5. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT transmits packets as per the DHCPv6 basic message exchange
including an IA_NA option in the Request message.
DHCPv6 Solicit Message DHCPv6 Request Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 1 Message Type = 3
IA_NA Option: IA_NA Option:
Option Code = 3 Option Code = 3
IA Address Option:
Option Code = 5
IPv6 Address = PF2::100
DHCPv6 Advertise Message DHCPv6 Reply Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 2 Message Type = 7
IA_NA Option: IA_NA Option:
Option Code = 3 Option Code = 3
IA Address Option: IA_NA Address Option:
Option Code = 5 Option Code = 5
IPv6 Address = PF2::100 IPv6 Address = PF2::100
Pref. Lifetime = 600
Valid Lifetime = 600
step 5. The DUT must transmit an Echo Reply to TN3.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.3 RA M-Flag is Set
v6_cpe_1_4
Weak Host Model
Purpose: Verify that the DUT supports the weak host model.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Enable DHCPv6-PD and wait 20 seconds to let the DUT perform the
DHCPv6-PD process and assign addresses to TN1 on the LAN network.
The DHCP server replies to all the DUT's messages with valid DHCP
messages.
step 3. TR1 transmits an Echo Request to the DUT's LAN global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must reply to the Echo Reply to TR1 with the source address
of the DUT LAN global address.
NOTE: The subnet ID of the DUT's LAN global address in step 3 will
be computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.4 Weak Host Model
v6_cpe_1_5_a
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=0
Purpose: Verify that the DUT initiates DHCPv6 prefix delegation regardless
of the M and O-flags in a received RA.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to the DUT's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively.
step 4. The DUT must respond to the Echo Request from TN3 with an Echo
Reply.
NOTE: Because the intent of the test is to verify that prefix delegation
occurs, the Echo Request in step 3 will be sent to the DUT's global PF1
address.
NOTE: If the testvar cpeRebootMode is set to "skip", this test will not
be run. If the testvar cpeRebootMode is set to "reboot", the CPE will be
restarted at the end of the test, either using the testvar RestartDUT or
by prompting the user.
NOTE: The subnet ID of the DUT's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix Delegation
Part A: M-Flag = 0, O-Flag = 0
v6_cpe_1_5_b
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=0
Purpose: Verify that the DUT initiates DHCPv6 prefix delegation regardless
of the M and O-flags in a received RA.
Procedure:
step 1. TR1 transmits RA2 on the WAN network.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 1
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to the DUT's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively.
step 4. The DUT must respond to the Echo Request from TN3 with an Echo
Reply.
NOTE: Because the intent of the test is to verify that prefix delegation
occurs, the Echo Request in step 3 will be sent to the DUT's global PF1
address.
NOTE: The subnet ID of the DUT's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix Delegation
Part B: M-Flag = 1, O-Flag = 0
v6_cpe_1_5_c
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=0, O-flag=1
Purpose: Verify that the DUT initiates DHCPv6 prefix delegation regardless
of the M and O-flags in a received RA.
Procedure:
step 1. TR1 transmits RA3 on the WAN network.
RA3
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to the DUT's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively.
step 4. The DUT must respond to the Echo Request from TN3 with an Echo
Reply.
NOTE: Because the intent of the test is to verify that prefix delegation
occurs, the Echo Request in step 3 will be sent to the DUT's global PF1
address.
NOTE: If the testvar cpeRebootMode is set to "skip", this test will not
be run. If the testvar cpeRebootMode is set to "reboot", the CPE will be
restarted at the end of the test, either using the testvar RestartDUT or
by prompting the user.
NOTE: The subnet ID of the DUT's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix Delegation
Part C: M-Flag = 0, O-Flag = 1
v6_cpe_1_5_d
RA M and O flags Effect on DHCP Prefix Delegation, M-flag=1, O-flag=1
Purpose: Verify that the DUT initiates DHCPv6 prefix delegation regardless
of the M and O-flags in a received RA.
Procedure:
step 1. TR1 transmits RA4 on the WAN network.
RA4
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 1
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to the DUT's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively.
step 4. The DUT must respond to the Echo Request from TN3 with an Echo
Reply.
NOTE: Because the intent of the test is to verify that prefix delegation
occurs, the Echo Request in step 3 will be sent to the DUT's global PF1
address.
NOTE: The subnet ID of the DUT's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix Delegation
Part D: M-Flag = 1, O-Flag = 1
v6_cpe_1_6
No Global Address is Configured
Purpose: Verify that the DUT creates its global IPv6 address from its
delegated prefix if it does not acquire global IPv6 address from
SLAAC or DHCPv6.
Procedure:
step 1. TR1 transmits RA1 with no prefix on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 1
O-flag = 0
Router Lifetime = 600 seconds
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to the DUT's global address with
prefix PF1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively. The DUT must perform DAD on its WAN
interface.
DHCPv6 Solicit Message DHCPv6 Request Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 1 Message Type = 3
IA_NA Option: IA_PD Option:
Option Code = 3 Option Code = 25
IA_PD Option: IA_PD Prefix Option:
Option Code = 25 Option Code = 26
Pref. Lifetime = 600
Valid Lifetime = 600
Prefix Length = 60
IPv6 Prefix = PF1
DHCPv6 Advertise Message DHCPv6 Reply Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 2 Message Type = 7
IA_PD Option: IA_PD Option:
Option-Code = 25 Option-Code = 25
IA_PD Prefix Option: IA_PD Prefix Option:
Option Code = 26 Option Code = 26
Pref. Lifetime = 600 Pref. Lifetime = 600
Valid Lifetime = 600 Valid Lifetime = 600
Prefix Length = 60 Prefix Length = 60
IPv6 Prefix = PF1 IPv6 Prefix = PF1
NS1
IPv6 Header:
Next Header = 58
Source Address = Unspecified address (::)
Dest. Address = Solicited multicast of the DUT's tentative
global address
Hop Limit = 255
Neighbor Solicitation:
Target Address = The DUT's tentative global address
step 4. The DUT must transmit and Echo Reply to TN3.
NOTE: If the testvar cpeRebootMode is set to "skip", this test will not
be run. If the testvar cpeRebootMode is set to "reboot", the CPE will be
restarted at the end of the test, either using the testvar RestartDUT or
by prompting the user.
NOTE: The subnet ID of the DUT's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.6 No Global Address is Configured
v6_cpe_1_7
Different DHCPv6 Prefix Size from Hint
Purpose: Verify that the DUT accepts a different delegated prefix length
from its hint.
Test Setup:
Configure the hint of the prefix length of DUT less than 64.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 0
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN3 transmits an Echo Request to TN1's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit and Request
messages. The DHCPv6 server replies with Advertise and Reply
messages respectively.
DHCPv6 Solicit Message DHCPv6 Request Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 1 Message Type = 3
IA_PD Option: IA_PD Option:
Option Code = 25 Option Code = 25
IA_PD Prefix Option: IA_PD Prefix Option:
Option Code = 26 Option Code = 26
Pref. Lifetime = 600 Pref. Lifetime = 600
Valid Lifetime = 600 Valid Lifetime = 600
Prefix Length = <64 Prefix Length = <64
IPv6 Prefix = PF1 IPv6 Prefix = PF1
DHCPv6 Advertise Message DHCPv6 Reply Message
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 2 Message Type = 7
IA_PD Option: IA_PD Option:
Option-Code = 25 Option-Code = 25
IA_PD Prefix Option: IA_PD Prefix Option:
Option Code = 26 Option Code = 26
Pref. Lifetime = 600 Pref. Lifetime = 600
Valid Lifetime = 600 Valid Lifetime = 600
Prefix Length = 64 Prefix Length = 64
IPv6 Prefix = PF1 IPv6 Prefix = PF1
step 4. The DUT must forward the Echo Request to TN1 and Echo Reply from TN1
TN3.
The prefix destination address of the Echo Request must be PF1 which
has a prefix length of 64.
Possible Problems:
This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: The subnet ID of the TN1's global address in step 3 will be
computed using the value of the testvar ipv6LanSubnetId. The
default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.7 Different DHCPv6 Prefix Size for Hint
v6_cpe_1_8
Prevent Forwarding Loops
Purpose: Verify that the DUT prevents forwarding loops when some addresses
covered by the aggregate are not reachable.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to let the DUT perform the DHCPv6-PD process and
assign addresses to the LAN side hosts with prefix PF1.
step 3. TN3 transmits an Echo Request to an address that was not assigned to
the LAN interface, but the prefix must be PF1.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must not forward the Echo Request to the LAN interface.
The DUT should send an ICMPv6 Destination Unreachable message to
TN3. The code field must be set to "0".
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.1.8 Prevent Forwarding Loops
v6_cpe_2_1_a
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /64
Purpose: Verify that the DUT assigns /64 addresses from prefix delegation to
the LAN interfaces.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process
and assign address to the LAN side hosts. The prefix length is 64.
step 3. TN1 transmits RS1 to the all-routers address on the LAN network.
step 4. Observe the packets transmitted on the LAN.
step 5. TN1 transmits an Echo Request to TN3.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with /64 prefix.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
step 6. The DUT must forward the Echo Request to TN3.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.1 Assign /64 Prefixes to LAN Interfaces
Part A: Prefix Length of /64
v6_cpe_2_1_b
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. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 48
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process
and assign address to the LAN side hosts. The prefix length is 48.
step 3. TN1 transmits RS1 to the all-routers address on the LAN network.
step 4. Observe the packets transmitted on the LAN.
step 5. TN1 transmits an Echo Request to TN3.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with /64 prefix.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
step 6. The DUT must forward the Echo Request to TN3.
NOTE: The subnet ID of the DUT's expected LAN prefix in step 4
will be computed using the value of the testvar ipv6LanSubnetId.
The default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.1 Assign /64 Prefixes to LAN Interfaces
Part B: Prefix Length of /48
v6_cpe_2_1_c
Assign /64 Prefixes to LAN Interfaces, Prefix Length of /56
Purpose: Verify that the DUT assigns /64 addresses from prefix delegation to
the LAN interfaces.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 56
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process
and assign address to the LAN side hosts. The prefix length is 56.
step 3. TN1 transmits RS1 to the all-routers address on the LAN network.
step 4. Observe the packets transmitted on the LAN.
step 5. TN1 transmits an Echo Request to TN3.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with /64 prefix.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
step 6. The DUT must forward the Echo Request to TN3.
NOTE: The subnet ID of the DUT's expected LAN prefix in step 4
will be computed using the value of the testvar ipv6LanSubnetId.
The default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.1 Assign /64 Prefixes to LAN Interfaces
Part C: Prefix Length of /56
v6_cpe_2_2_a
RA Route Information Option, Having 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. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process
and assign address to the LAN side hosts.
step 3. TN1 transmits RS1 to the all-routers address.
step 4. Observe the packets transmitted on the LAN.
step 5. TN1 transmits an Echo Request to TN3's global address.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with a Route Information option.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
Route Information Option:
Type = 24
Prefix Length = 64
Prefix Lifetime = 600
Prefix = PF1
step 6. The DUT must forward the Echo Request to TN3.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.2 RA Route Information Option
Part A: Having WAN Connectivity
v6_cpe_2_2_b
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. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD
process and assign address to the LAN side hosts. The
IA_PD lifetime is three times that of the IA_NA lifetime.
step 3. Disable the DUT's connection on the WAN network.
step 4. Wait for 20 seconds.
step 5. TN1 transmits RS1 to the all-routers address.
step 6. Observe the packets transmitted on the LAN.
Observable Results:
step 6. The DUT must transmit RA3 with a Route Information option.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 0 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
Route Information Option:
Type = 24
Prefix Length = 64
Prefix Lifetime = 600
Prefix = PF1
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.2 RA Route Information Option
Part B: Without WAN Connectivity
v6_cpe_2_3_a
No Prefixes Delegated
Purpose: Verify that the DUT does not advertise itself as a default router
if no prefixes are configured or delegated.
Procedure:
step 1. TR1 transmits RA1 with no prefixes on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process.
DHCPv6 server delegated no prefix.
step 3. TN1 transmits RS1 to the all-routers address.
step 4. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with router lifetime of 0 in response to
the Router Solicitation.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 0 seconds
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.3 No Prefixes Delegated
Part A: No Prefixes Delegated
v6_cpe_2_3_b
No Prefixes Delegated, Delegated Prefix Expired
Purpose: Verify that the DUT does not advertise itself as a default router
if no prefixes are configured or delegated.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 30
Pref. Lifetime = 30
Prefix = PF1
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process.
step 3. TN1 transmits RS1 to the all-routers address.
step 4. Observe the packets transmitted on the LAN.
step 5. Wait for delegated prefix to expire.
step 6. TN1 transmits RS1 to the all-routers address.
step 7. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA3 with router lifetime greater than 0 in
response to the Router Solicitation.
RA3
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
step 7. The DUT must transmit RA2 with Router Lifetime of 0 in response to
the Router Solicitation.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 0 seconds
NOTE: The subnet ID of the DUT's expected LAN prefix in step 4
will be computed using the value of the testvar ipv6LanSubnetId.
The default is to use a subnet ID of 1.
NOTE: The valid-lifetime of the delegated IA_PD prefix in step 2
is dictated by the testvar dhcpv6IAValidLifetime.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.3 No Prefixes Delegated
Part B: Delegated Prefix Expired
v6_cpe_2_4
Advertising to Each LAN Inteface
Purpose: Verify that the DUT makes each LAN interface an advertising
interface.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1 RS1
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Dest. Address = ff02::2
M-flag = 0 Router Solicitation:
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD process
and assign addresses to the LAN side hosts.
step 3. TN1 transmits RS1 to the all-routers address.
step 4. Observe the packets transmitted on the LAN.
Observable Results:
step 4. The DUT must transmit RA2 with Prefix Information option. The A and
L flags of the Prefix Information option must be set to 1.
RA2
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 1
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF1
NOTE: The subnet ID of the DUT's expected LAN prefix in step 4
will be computed using the value of the testvar ipv6LanSubnetId.
The default is to use a subnet ID of 1.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.4 Advertising to Each LAN Interface
v6_cpe_2_5
Delegated Prefix Changed
Purpose: Verify that the DUT properly advertises RA when the delegated
prefix changed.
Procedure:
step 1. TR1 transmits RA1 on the WAN network.
RA1
IPv6 Header:
Next Header = 58
Router Advertisement:
M-flag = 0
O-flag = 0
Router Lifetime = 600 seconds
Prefix Information Option:
Type = 3
L-flag = 1
A-flag = 1
Prefix Length = 64
Valid Lifetime = 600
Pref. Lifetime = 600
Prefix = PF2
step 2. Observe the packets transmitted on the WAN.
step 3. TN1 transmits and Echo Request to TN3's global address.
step 4. Observe the packets transmitted on the LAN.
step 5. Wait for PF1 to expire.
step 6. Observe the packets transmitted on the WAN.
step 7. The DHCPv6 server transmits Reply message 1 with the new prefix PF4
to the DUT.
Reply Message 1
IPv6 Header:
Next Header = 17
DHCPv6:
Message Type = 7
IA_PD Option:
Option Code = 25
IA_PD Prefix Option:
Option Code = 26
Pref. Lifetime = 600
Valid Lifetime = 600
Prefix Length = 60
Prefix = PF4
step 8. TN3 transmits an Echo Request to TN1's prefix PF1 global address.
step 9. Observe the packets transmitted on the LAN.
step 10. TN3 transmits an Echo Request to TN1's prefix PF4 global address.
step 11. Observe the packets transmitted on the LAN.
Observable Results:
step 2. The DUT must follow the DHCPv6 message procedure defined in the
DHCPv6 basic message exchange. The DUT transmits Solicit message
and Request message. The DHCPv6 server replies with Advertise
message 1 and Reply message 1 respectively.
The prefix is PF1.
Advertise Message 1 Reply Message 1
IPv6 Header: IPv6 Header:
Next Header = 17 Next Header = 17
DHCPv6: DHCPv6:
Message Type = 2 Message Type = 7
IA_PD Option: IA_PD Option:
Option Code = 25 Option Code = 25
IA_PD Prefix Option: IA_PD Prefix Option:
Option Code = 26 Option Code = 26
Pref. Lifetime = 60 Pref. Lifetime = 60
Valid Lifetime = 60 Valid Lifetime = 60
Prefix Length = 60 Prefix Length = 60
Prefix = PF1 Prefix = PF1
step 4. The DUT must forward the Echo Request to TN3. The DUT must forward
the Echo Reply from TN3 to TN1.
step 6. The DUT must transmit a properly formatted Renew message.
Renew Message
IPv6 Header:
Next Header = 17
DHCPv6:
Message Type = 5
Servier Identifier Option:
DUID = DHCPv6 server's DUID
Client Identifier Option:
DUID = DUT's DUID
IA_PD Option:
Option Code = 25
IA_PD PRefix Option:
Option Code = 26
Pref. Lifetime = 600
Valid Lifetime = 600
Prefix Length = 60
IPv6 Prefix = PF1
step 9. The DUT must not forward the Echo Request to TN1. The DUT must send
an ICMP Destination Unreachable message, code 5 to TR1.
step 11. The DUT must forward the Echo Request to TN1. The DUT must forward
the Echo Reply from TN1 to TN3.
NOTE: The subnet ID of TN1's PF1/PF4 global address in step 8/10
will be computed using the value of the testvar ipv6LanSubnetId.
The default is to use a subnet ID of 1.
NOTE: The valid-lifetime of the delegated IA_PD prefix in step 2
is dictated by the testvar dhcpv6IAValidLifetime.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.2.5 Delegated Prefix Changed
v6_cpe_3_1_a
Default Source Address Selection, Prefer Appropriate Scope
Purpose: Verify that the DUT properly selects default source address.
Procedure:
step 1. TR1 transmits RA1 and RA2 on the WAN network.
RA1 RA2
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Router Advertisement:
M-flag = 0 M-flag = 0
O-flag = 0 O-flag = 0
Router Lifetime = 600 seconds Router Lifetime = 600 seconds
Prefix Information Option: Prefix Information Option:
Type = 3 Type = 3
L-flag = 1 L-flag = 1
A-flag = 1 A-flag = 1
Prefix Length = 64 Prefix Length = 64
Valid Lifetime = 600 Valid Lifetime = 600
Pref. Lifetime = 600 Pref. Lifetime = 600
Prefix = PF4 Prefix = PF2
step 2. Wait 10 seconds.
step 3. The DUT transmits an Echo Request to TN2's global address.
step 4. Observe the packets transmitted on the WAN.
Observable Results:
step 4. The DUT must transmit the Echo Request with PF2 prefix as the source
address.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 3.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.3.1 Default Source Address Selection
Part A: Prefer Appropriate Scope
v6_cpe_3_1_b
Default Source Address Selection, Avoid Deprecated Addresses
Purpose: Verify that the DUT properly selects default source address.
Procedure:
step 1. TR1 transmits RA1 and RA2 on the WAN network.
RA1 RA2
IPv6 Header: IPv6 Header:
Next Header = 58 Next Header = 58
Router Advertisement: Router Advertisement:
M-flag = 0 M-flag = 0
O-flag = 0 O-flag = 0
Router Lifetime = 600 seconds Router Lifetime = 600 seconds
Prefix Information Option: Prefix Information Option:
Type = 3 Type = 3
L-flag = 1 L-flag = 1
A-flag = 1 A-flag = 1
Prefix Length = 64 Prefix Length = 64
Valid Lifetime = 600 Valid Lifetime = 600
Pref. Lifetime = 600 Pref. Lifetime = 600
Prefix = PF4 Prefix = PF2
step 2. Wait 10 seconds.
step 3. TR1 transmits a RA with PF2's prefix lifetime of 0.
step 4. The DUT transmits an Echo Request to TN2's global address.
step 5. Observe the packets transmitted on the WAN.
Observable Results:
step 5. The DUT must transmit an Echo Request with PF4 prefix as the source
address.
NOTE: This test may be omitted if the DUT does not implement an
application for sending ICMPv6 Echo Requests.
NOTE: If the testvar interactiveTestMode is set to "skip", this test will
not be run. If the testvar interactiveTestMode is set to "prompt", the
user will be prompted to cause the DUT to send the ICMPv6 Echo Request in
step 4.
Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02
CPE.Conf.3.1 Default Source Address Selection
Part B: Avoid Deprecated Addresses
v6_cpe_3_1_c
Default Source Address Selection, Use Longest Matching Prefix
v6_cpe_3_2
Default Router Changed
sip-v6 (6)
SIP over IPv6 testing
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
RFC 3261 SIP: Session Initiation Protocol
Section 20 Header Fields
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
RFC 3261 SIP: Session Initiation Protocol
Section 20 Header Fields
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
RFC 3261 SIP: Session Initiation Protocol
Section 20 Header Fields
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
RFC 3261 SIP: Session Initiation Protocol
Section 20 Header Fields
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
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
RFC 3261 SIP: Session Initiation Protocol
Section 20 Header Fields
triggerp-v6 (2)
Tests to verify configured IPv6 trigger ports on the router
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
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 (31)
IETF RFC 6092 simple security in IPv6 gateway CPE tests
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
IETF RFC 2464 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.
IETF RFC 6085 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.
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
Reference:
IETF RFC 6092 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).
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
Reference:
IETF RFC 6092 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.
rfc6092_rec_5
Section 3.1: Stateless filters, REC-5
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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 IPv4 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet usuing the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different IPv4 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 usuing the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using the same source port and IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
NOTE: This test case only verifies that the normal TCP 3-way
handshake mode is supported.
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
Reference:
IETF RFC 6092 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.
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 IPv4 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet usuing the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different IPv4 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 usuing the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using the same source port and IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
NOTE: This test case only verifies that the normal SCTP
association establishment is supported.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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. [...] The value of the
"transitory association idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable by
the network administrator.
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
Reference:
IETF RFC 6092 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.
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
Reference:
IETF RFC 6092 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.
rip-ng (10)
RIPng tests for LAN side of the router
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'.
Reference:
IETF RFC 2080 Section 2.3: Timers
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
Reference:
IETF RFC 2080 Section 2.4.2: Response Messages
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
IETF RFC 2080 Section 2.4.1: Request Messages
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
Reference:
IETF RFC 2080 Section 2.4.2: Response Messages
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
Reference:
IETF RFC 2080 Section 2.4.2: Response Messages
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)
Reference:
IETF RFC 2080 Section 2.5.2: Generating Response Messages
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
Reference:
IETF RFC 2080 Section 2.2: Addressing Considerations
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
Reference:
IETF RFC 2080 Section 2.1: Message Format
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
Reference:
IETF RFC 2080 Section 2.4.2: Response Messages
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
Reference:
IETF RFC 2080 Section 2.1.1: Next HopNmap
nmap (16)
Nmap based IPv4 portscan tests from the LAN side of the device
v4_lan_tcp_connect_info
NMap IPv4 TCP Connect scan
step 1. Initiate a NMap IPv4 TCP Connect scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_syn_info
NMap IPv4 TCP Syn scan
step 1. Initiate a NMap IPv4 TCP Syn scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_fin_info
NMap IPv4 TCP Fin scan
step 1. Initiate a NMap IPv4 TCP Fin scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_null_info
NMap IPv4 TCP Null scan
step 1. Initiate a NMap IPv4 TCP Null scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_xmas_info
NMap IPv4 TCP XMAS scan
step 1. Initiate a NMap IPv4 TCP XMAS scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_psh_info
NMap IPv4 TCP PSH scan
step 1. Initiate a NMap IPv4 TCP PSH scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_urg_info
NMap IPv4 TCP URG scan
step 1. Initiate a NMap IPv4 TCP URG scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_finurg_info
NMap IPv4 TCP FIN+URG scan
step 1. Initiate a NMap IPv4 TCP FIN+URG scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_finpsh_info
NMap IPv4 TCP FIN+PSH scan
step 1. Initiate a NMap IPv4 TCP FIN+PSH scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_maimon_info
NMap IPv4 TCP Maimon scan
step 1. Initiate a NMap IPv4 TCP Maimon scan from the LAN
step 2. Display the final NMap report
v4_lan_tcp_ack_info
NMap IPv4 TCP ACK scan
step 1. Initiate a NMap IPv4 TCP ACK scan from the LAN
step 2. Display the final NMap report
v4_lan_udp_info
NMap IPv4 UDP scan
step 1. Initiate a NMap IPv4 UDP scan from the LAN
step 2. Display the final NMap report
v4_lan_sctp_init_info
NMap IPv4 SCTP Init scan
step 1. Initiate a NMap IPv4 SCTP Init scan from the LAN
step 2. Display the final NMap report
v4_lan_sctp_cookie_info
NMap IPv4 SCTP Cookie scan
step 1. Initiate a NMap IPv4 SCTP Cookie scan from the LAN
step 2. Display the final NMap report
v4_lan_os_detection
NMap IPv4 OS Detection from LAN side of device
step 1. Initiate a NMap IPv4 scan for OS detection from the LAN
step 2. Display the final NMap report
v4_lan_os_detection_version
NMap IPv4 OS Detection with version detection from LAN side of device
step 1. Initiate a NMap IPv4 scan for OS detection with version detection from the LAN
step 2. Display the final NMap report
nmap-wan (16)
Nmap based IPv4 portscan tests from the WAN side of the device
v4_wan_tcp_connect_info
NMap IPv4 TCP Connect scan
step 1. Initiate a NMap IPv4 TCP Connect scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_syn_info
NMap IPv4 TCP Syn scan
step 1. Initiate a NMap IPv4 TCP Syn scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_fin_info
NMap IPv4 TCP Fin scan
step 1. Initiate a NMap IPv4 TCP Fin scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_null_info
NMap IPv4 TCP Null scan
step 1. Initiate a NMap IPv4 TCP Null scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_xmas_info
NMap IPv4 TCP XMAS scan
step 1. Initiate a NMap IPv4 TCP XMAS scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_psh_info
NMap IPv4 TCP PSH scan
step 1. Initiate a NMap IPv4 TCP PSH scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_urg_info
NMap IPv4 TCP URG scan
step 1. Initiate a NMap IPv4 TCP URG scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_finurg_info
NMap IPv4 TCP FIN+URG scan
step 1. Initiate a NMap IPv4 TCP FIN+URG scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_finpsh_info
NMap IPv4 TCP FIN+PSH scan
step 1. Initiate a NMap IPv4 TCP FIN+PSH scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_maimon_info
NMap IPv4 TCP Maimon scan
step 1. Initiate a NMap IPv4 TCP Maimon scan from the WAN
step 2. Display the final NMap report
v4_wan_tcp_ack_info
NMap IPv4 TCP ACK scan
step 1. Initiate a NMap IPv4 TCP ACK scan from the WAN
step 2. Display the final NMap report
v4_wan_udp_info
NMap IPv4 UDP scan
step 1. Initiate a NMap IPv4 UDP scan from the WAN
step 2. Display the final NMap report
v4_wan_sctp_init_info
NMap IPv4 SCTP Init scan
step 1. Initiate a NMap IPv4 SCTP Init scan from the WAN
step 2. Display the final NMap report
v4_wan_sctp_cookie_info
NMap IPv4 SCTP Cookie scan
step 1. Initiate a NMap IPv4 SCTP Cookie scan from the WAN
step 2. Display the final NMap report
v4_wan_os_detection
NMap IPv4 OS Detection from WAN side of device
step 1. Initiate a NMap IPv4 scan for OS detection from the WAN
step 2. Display the final NMap report
v4_wan_os_detection_version
NMap IPv4 OS Detection with version detection from WAN side of device
step 1. Initiate a NMap IPv4 scan for OS detection with version detection from the WAN
step 2. Display the final NMap report
nmap-v6 (16)
Nmap based IPv6 portscan tests from the LAN side of the device
v6_lan_tcp_connect_info
NMap IPv6 TCP Connect scan
step 1. Initiate a NMap IPv6 TCP Connect scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_syn_info
NMap IPv6 TCP Syn scan
step 1. Initiate a NMap IPv6 TCP Syn scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_fin_info
NMap IPv6 TCP Fin scan
step 1. Initiate a NMap IPv6 TCP Fin scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_null_info
NMap IPv6 TCP Null scan
step 1. Initiate a NMap IPv6 TCP Null scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_xmas_info
NMap IPv6 TCP XMAS scan
step 1. Initiate a NMap IPv6 TCP XMAS scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_psh_info
NMap IPv6 TCP PSH scan
step 1. Initiate a NMap IPv6 TCP PSH scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_urg_info
NMap IPv6 TCP URG scan
step 1. Initiate a NMap IPv6 TCP URG scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_finurg_info
NMap IPv6 TCP FIN+URG scan
step 1. Initiate a NMap IPv6 TCP FIN+URG scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_finpsh_info
NMap IPv6 TCP FIN+PSH scan
step 1. Initiate a NMap IPv6 TCP FIN+PSH scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_maimon_info
NMap IPv6 TCP Maimon scan
step 1. Initiate a NMap IPv6 TCP Maimon scan from the LAN
step 2. Display the final NMap report
v6_lan_tcp_ack_info
NMap IPv6 TCP ACK scan
step 1. Initiate a NMap IPv6 TCP ACK scan from the LAN
step 2. Display the final NMap report
v6_lan_udp_info
NMap IPv6 UDP scan
step 1. Initiate a NMap IPv6 UDP scan from the LAN
step 2. Display the final NMap report
v6_lan_sctp_init_info
NMap IPv6 SCTP Init scan
step 1. Initiate a NMap IPv6 SCTP Init scan from the LAN
step 2. Display the final NMap report
v6_lan_sctp_cookie_info
NMap IPv6 SCTP Cookie scan
step 1. Initiate a NMap IPv6 SCTP Cookie scan from the LAN
step 2. Display the final NMap report
v6_lan_os_detection
NMap IPv6 OS Detection from LAN side of device
step 1. Initiate a NMap IPv6 scan for OS detection from the LAN
step 2. Display the final NMap report
v6_lan_os_detection_version
NMap IPv6 OS Detection with version detection from LAN side of device
step 1. Initiate a NMap IPv6 scan for OS detection with version detection from the LAN
step 2. Display the final NMap report
nmap-wan-v6 (16)
Nmap based IPv6 portscan tests from the WAN side of the device
v6_wan_tcp_connect_info
NMap IPv6 TCP Connect scan
step 1. Initiate a NMap IPv6 TCP Connect scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_syn_info
NMap IPv6 TCP Syn scan
step 1. Initiate a NMap IPv6 TCP Syn scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_fin_info
NMap IPv6 TCP Fin scan
step 1. Initiate a NMap IPv6 TCP Fin scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_null_info
NMap IPv6 TCP Null scan
step 1. Initiate a NMap IPv6 TCP Null scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_xmas_info
NMap IPv6 TCP XMAS scan
step 1. Initiate a NMap IPv6 TCP XMAS scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_psh_info
NMap IPv6 TCP PSH scan
step 1. Initiate a NMap IPv6 TCP PSH scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_urg_info
NMap IPv6 TCP URG scan
step 1. Initiate a NMap IPv6 TCP URG scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_finurg_info
NMap IPv6 TCP FIN+URG scan
step 1. Initiate a NMap IPv6 TCP FIN+URG scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_finpsh_info
NMap IPv6 TCP FIN+PSH scan
step 1. Initiate a NMap IPv6 TCP FIN+PSH scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_maimon_info
NMap IPv6 TCP Maimon scan
step 1. Initiate a NMap IPv6 TCP Maimon scan from the WAN
step 2. Display the final NMap report
v6_wan_tcp_ack_info
NMap IPv6 TCP ACK scan
step 1. Initiate a NMap IPv6 TCP ACK scan from the WAN
step 2. Display the final NMap report
v6_wan_udp_info
NMap IPv6 UDP scan
step 1. Initiate a NMap IPv6 UDP scan from the WAN
step 2. Display the final NMap report
v6_wan_sctp_init_info
NMap IPv6 SCTP Init scan
step 1. Initiate a NMap IPv6 SCTP Init scan from the WAN
step 2. Display the final NMap report
v6_wan_sctp_cookie_info
NMap IPv6 SCTP Cookie scan
step 1. Initiate a NMap IPv6 SCTP Cookie scan from the WAN
step 2. Display the final NMap report
v6_wan_os_detection
NMap IPv6 OS Detection from WAN side of device
step 1. Initiate a NMap IPv6 scan for OS detection from the WAN
step 2. Display the final NMap report
v6_wan_os_detection_version
NMap IPv6 OS Detection with version detection from WAN side of device
step 1. Initiate a NMap IPv6 scan for OS detection with version detection from the WAN
step 2. Display the final NMap report
扫一扫
7684
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
