step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-HopOptions and Destination Options extension headers using the PadN and Pad1options, respectivelyHop-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        = 0x00000000Destination 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 destinationusing the extension headers generated in Step 1step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 secondsReference:IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6

step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-HopOptions and Destination Options extension headers using the PadN andPad1 options, respectivelyHop-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        = 0x00000000Destination 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 IPv6link-local address using the extension headers generated in Step 1step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 secondsReference:IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6

step 1. Generate an ICMPv6 Echo Request packet containing a IPv6 Hop-by-HopOptions extension header with a Next Header value of 200 (IPprotocol 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        = 0x00000000Unrecognized 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 IPv6link-local address using the extension headers generated in Step 1step 3. Verify that the packet transmitted in Step 2 is discarded byensuring that no ICMPv6 Echo Reply packets are received within 3secondsstep 4. Optional - if an ICMPv6 Parameter Problem packet is received, verifythat the ICMPv6 Parameter Problem message contains a value of 1 inthe Code fieldstep 5. Optional - if an ICMPv6 Parameter Problem packet is received, verifythat the ICMPv6 Parameter Problem message contains a value of 40 inthe Pointer fieldReference:IETF RFC2460 Section 4:If, as a result of processing a header, a node is required to proceedto the next header but the Next Header value in the current header isunrecognized by the node, it should discard the packet and send anICMP Parameter Problem message to the source of the packet, with anICMP Code value of 1 ("unrecognized Next Header type encountered")and the ICMP Pointer field containing the offset of the unrecognizedvalue within the original packet.  The same action should be taken ifa node encounters a Next Header value of zero in any header otherthan an IPv6 header.IETF RFC4443 Section 3.4:If an IPv6 node processing a packet finds a problem with a field inthe IPv6 header or extension headers such that it cannot completeprocessing the packet, it MUST discard the packet and SHOULD send anICMPv6 Parameter Problem message to the packet's source, indicatingthe 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 headerwhere the error was detected. For example, an ICMPv6 message withType field = 4, Code field = 1, and Pointer field = 40 would indicatethat the IPv6 extension header following the IPv6 header of theoriginal packet holds an unrecognized Next Header field value.

step 1. Generate an ICMPv6 Echo Request packet containing the IPv6Hop-by-Hop Options extension header with a Next Header value of 0Hop-by-Hop Options Header:Next Header        = 0x00 (HOPOPT)Length             = 0x00 (8 bytes)Option Type        = 0x01 (PadN)Option Data Length = 0x04 (6 bytes)Option Data        = 0x00000000Next 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 IPv6link-local address using the extension headers generated in Step 1step 3. Verify that the packet transmitted in Step 2 is discarded byensuring that no ICMPv6 Echo Reply packets are received within 3secondsstep 4. Optional - if an ICMPv6 Parameter Problem packet is received, verifythat the ICMPv6 Parameter Problem message contains a value of 1 inthe Code fieldstep 5. Optional - if an ICMPv6 Parameter Problem packet is received, verifythat the ICMPv6 Parameter Problem message contains a value of 40 inthe Pointer fieldReference:IETF RFC2460 Section 4:If, as a result of processing a header, a node is required to proceedto the next header but the Next Header value in the current header isunrecognized by the node, it should discard the packet and send anICMP Parameter Problem message to the source of the packet, with anICMP Code value of 1 ("unrecognized Next Header type encountered")and the ICMP Pointer field containing the offset of the unrecognizedvalue within the original packet.  The same action should be taken ifa node encounters a Next Header value of zero in any header otherthan an IPv6 header.IETF RFC4443 Section 3.4:If an IPv6 node processing a packet finds a problem with a field inthe IPv6 header or extension headers such that it cannot completeprocessing the packet, it MUST discard the packet and SHOULD send anICMPv6 Parameter Problem message to the packet's source, indicatingthe 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 headerwhere the error was detected. For example, an ICMPv6 message withType field = 4, Code field = 1, and Pointer field = 40 would indicatethat the IPv6 extension header following the IPv6 header of theoriginal packet holds an unrecognized Next Header field value.

step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-HopOptions and Destination Options extension headers. The Hop-by-HopOptions extension header will have a Next Header value of 59 (noNext 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        = 0x00000000Destination Options Header:Next Header        = 0x3a (ICMP)Length             = 0x00 (8 bytes)Option Type        = 0x01 (PadN)Option Data Length = 0x04 (6 bytes)Option Data        = 0x00000000step 2. Initiate an ICMPv6 Echo Request (ping) to the DUT's LAN-side IPv6link-local address using the extension header generated in Step 1step 3. Verify that the DUT ignores the ICMPv6 Echo Request packet byensuring that no ICMPv6 Echo Reply packets are received within 3secondsReference:IETF RFC2460 Section 4.7:The value 59 in the Next Header field of an IPv6 header or anyextension header indicates that there is nothing following thatheader.  If the Payload Length field of the IPv6 header indicates thepresence of octets past the end of a header whose Next Header fieldcontains 59, those octets must be ignored, and passed on unchanged ifthe packet is forwarded.

step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-HopOptions and Destination Options extension headers. The Hop-by-HopOptions extension header will have a Next Header value of 59 (noNext 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        = 0x00000000Destination Options Header:Next Header        = 0x3a (ICMP)Length             = 0x00 (8 bytes)Option Type        = 0x01 (PadN)Option Data Length = 0x04 (6 bytes)Option Data        = 0x00000000step 2. Initiate an ICMPv6 Echo Request (ping) to a WAN IPv6 destinationaddress using the extension header generated in Step 1step 3. Verify that the WAN host receives the packet transmitted in Step 2step 4. Verify that the ICMPv6 Echo Request packet received by the WAN hostis identical to the packet that was transmitted. Note that theICMPv6 Echo Request packet may be displayed as as an IPv6 protocoltype 0 packet (Hop-by-Hop Options) due to the inclusion of the noNext Header field in the Hop-by-Hop Options extension header. Thedata portion of the received IPv6 packet on the WAN should beanalayzed 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 anyextension header indicates that there is nothing following thatheader.  If the Payload Length field of the IPv6 header indicates thepresence of octets past the end of a header whose Next Header fieldcontains 59, those octets must be ignored, and passed on unchanged ifthe packet is forwarded.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 7 (0x07). Option Type 7 contains high order bits of00.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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client toa WAN IPv6 destination using the extension header generated inStep 1step 3. Verify that the DUT ignores the unknown Option Type by ensuring thatan ICMPv6 Echo Reply (ping response) packet is receivedReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, 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 informationthat must be examined by every node along a packet's delivery path.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 71 (0x47). Option Type 71 contains high order bits of01.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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client toa WAN IPv6 destination using the extension header generated inStep 1step 3. Verify that the DUT silently discards the packet transmitted in Step2 be ensuring that it does not forward an ICMPv6 Echo Request packetto the WAN IPv6 destination within 3 secondsstep 4. Repeat Step 2step 5. Verify that the DUT silently discards the packet transmitted in Step4 by ensuring that it does not send an ICMPv6 Parameter Problempacket to the LAN source within 3 secondsReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, 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 informationthat must be examined by every node along a packet's delivery path.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 135 (0x87). Option Type 135 contains high order bitsof 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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client toa WAN IPv6 destination using the extension header generated inStep 1step 3. Verify that the DUT discards the packet transmitted in Step 2 byensuring that it does not forward an ICMPv6 Echo Request packet tothe WAN IPv6 destination within 3 secondsstep 4. Repeat Step 2step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to thesource in response to the packet transmitted in Step 4 within 3secondsstep 6. Verify that the ICMPv6 Parameter Problem message contains a value of2 in the Code fieldstep 7. Verify that the ICMPv6 Parameter Problem message contains a value of42 in the Pointer fieldReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, 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 informationthat must be examined by every node along a packet's delivery path.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 135 (0x87). Option Type 135 contains high order bitsof 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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client tothe all nodes multicast destination using the extension headergenerated in Step 1step 3. Verify that the DUT discards the packet transmitted in Step 2 beensuring that it does not forward an ICMPv6 Echo Request packet tothe LAN host within 3 secondsstep 4. Repeat Step 2step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to thesource in response to the packet transmitted in Step 4 within 3secondsstep 6. Verify that the ICMPv6 Parameter Problem message contains a value of2 in the Code fieldstep 7. Verify that the ICMPv6 Parameter Problem message contains a value of42 in the Pointer fieldReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, Code 2, message to the packet's Source Address,pointing to the unrecognized Option Type.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 199 (0xc7). Option Type 199 contains high order bitsof 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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client toa WAN IPv6 destination using the extension header generated inStep 1step 3. Verify that the DUT discards the packet transmitted in Step 2 beensuring that it does not forward an ICMPv6 Echo Request packet tothe WAN IPv6 destination within 3 secondsstep 4. Repeat Step 2step 5. Verify that the DUT sends an ICMPv6 Parameter Problem packet to thesource in response to the packet transmitted in Step 4 within 3secondsstep 6. Verify that the ICMPv6 Parameter Problem message contains a value of2 in the Code fieldstep 7. Verify that the ICMPv6 Parameter Problem message contains a value of42 in the Pointer fieldReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, 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 informationthat must be examined by every node along a packet's delivery path.

step 1. Generate a Hop-by-Hop Options extension header with an unknownOption Type of 199 (0xc7). Option Type 199 contains high order bitsof 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        = 0x00000000step 2. Initiate an outbound ICMPv6 Echo Request (ping) from a LAN client tothe all nodes multicast destination using the extension headergenerated in Step 1step 3. Verify that the DUT discards the packet transmitted in Step 2 anddoes not send an ICMPv6 Parameter Problem packet to the sourceReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.2:The Option Type identifiers are internally encoded such that theirhighest-order two bits specify the action that must be taken if theprocessing 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 thepacket's Destination Address was a multicast address, send anICMP Parameter Problem, Code 2, message to the packet'sSource Address, pointing to the unrecognized Option Type.11 - discard the packet and, only if the packet's DestinationAddress was not a multicast address, send an ICMP ParameterProblem, Code 2, message to the packet's Source Address,pointing to the unrecognized Option Type.

step 1. Generate an ICMP Echo Request packet containing an IPv6 Routingextension header. The destination address is the gateway's globaladdress, which forces header processing. The segment is set to theRemoteHost's IPv6 address.Routing Extension Header:Next Header        = 0x3a (ICMPv6)Length             = 0x06 (56 bytes)Routing Type       = 0x00 (Source Routing)Segments Left:     = 0x01step 2. The RemoteHost is inspected to verify the gateway did not resend thepacketstep 3. The packet is resentstep 4. ICMPv6 Parameter Problem packet is verified as delivered to the LANclientReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC5095 Section 3:An IPv6 node that receives a packet with a destination addressassigned to it and that contains an RH0 extension header MUST NOTexecute the algorithm specified in the latter part of Section 4.4 of[RFC2460] for RH0.  Instead, such packets MUST be processed accordingto the behaviour specified in Section 4.4 of [RFC2460] for a datagramthat includes an unrecognised Routing Type value, namely:If Segments Left is zero, the node must ignore the Routing headerand proceed to process the next header in the packet, whose typeis identified by the Next Header field in the Routing header.If Segments Left is non-zero, the node must discard the packet andsend an ICMP Parameter Problem, Code 0, message to the packet'sSource Address, pointing to the unrecognized Routing Type.

step 1. Generate an ICMP Echo Request packet containing an IPv6 Routingextension header. The destination address is the gateway's globaladdress, which forces header processing. The segment is set to theRemoteHost's IPv6 address.Routing Extension Header:Next Header        = 0x3a (ICMPv6)Length             = 0x06 (56 bytes)Routing Type       = 0x00 (Source Routing)Segments Left:     = 0x00step 2. The RemoteHost is inspected to verify the gateway did not resend thepacketstep 3. The packet is resentstep 4. The LAN client is inspected to verify the ICMPv6 Echo Reply wasreceived from the gatewayReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC5095 Section 3:An IPv6 node that receives a packet with a destination addressassigned to it and that contains an RH0 extension header MUST NOTexecute the algorithm specified in the latter part of Section 4.4 of[RFC2460] for RH0.  Instead, such packets MUST be processed accordingto the behaviour specified in Section 4.4 of [RFC2460] for a datagramthat includes an unrecognised Routing Type value, namely:If Segments Left is zero, the node must ignore the Routing headerand proceed to process the next header in the packet, whose typeis identified by the Next Header field in the Routing header.If Segments Left is non-zero, the node must discard the packet andsend an ICMP Parameter Problem, Code 0, message to the packet'sSource Address, pointing to the unrecognized Routing Type.

step 1. Generate an ICMP Echo Request packet containing an IPv6 Routingextension header. The destination address is the gateway's globaladdress, which forces header processing. The segment is set to theRemoteHost's IPv6 address.Routing Extension Header:Next Header        = 0x3a (ICMPv6)Length             = 0x06 (56 bytes)Routing Type       = 0x33 (Unknown Type)Segments Left:     = 0x01step 2. The RemoteHost is inspected to verify the gateway did not resend thepacketstep 3. The packet is resentstep 4. ICMPv6 Parameter Problem packet is verified as delivered to the LANclientReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.4:If, while processing a received packet, a node encounters a Routingheader with an unrecognized Routing Type value, the required behaviorof the node depends on the value of the Segments Left field, asfollows:If Segments Left is zero, the node must ignore the Routing headerand proceed to process the next header in the packet, whose typeis identified by the Next Header field in the Routing header.If Segments Left is non-zero, the node must discard the packet andsend an ICMP Parameter Problem, Code 0, message to the packet'sSource Address, pointing to the unrecognized Routing Type.

step 1. Generate an ICMP Echo Request packet containing an IPv6 Routingextension header. The destination address is the gateway's globaladdress, which forces header processing. The segment is set to theRemoteHost's IPv6 address.Routing Extension Header:Next Header        = 0x3a (ICMPv6)Length             = 0x06 (56 bytes)Routing Type       = 0x33 (Unknown Type)Segments Left:     = 0x00step 2. The RemoteHost is inspected to verify the gateway did not resend thepacketstep 3. The packet is resentstep 4. The LAN client is inspected to verify the ICMPv6 Echo Reply wasreceived from the gatewayReferences:IPv6 Ready Phase-1/Phase-2 Test Specification Core Protocolshttp://ipv6ready.org/docs/Core_Conformance_Latest.pdfIETF RFC2460 Section 4.4:If, while processing a received packet, a node encounters a Routingheader with an unrecognized Routing Type value, the required behaviorof the node depends on the value of the Segments Left field, asfollows:If Segments Left is zero, the node must ignore the Routing headerand proceed to process the next header in the packet, whose typeis identified by the Next Header field in the Routing header.If Segments Left is non-zero, the node must discard the packet andsend an ICMP Parameter Problem, Code 1, message to the packet'sSource Address, pointing to the unrecognized Routing Type.

step 1. Generate a valid 3000 byte ICMPv6 Echo Request packetstep 2. Set IPv6 MTU of the LAN to 1280 bytesstep 3. Initiate an outbound ICMPv6 Echo Request (ping) to the DUT'sLAN-side IPv6 link-local address using the packet generated inStep 1step 4. Verify that an ICMPv6 Echo Reply packet is received within 3 secondsReference:IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6

step 1. Generate a valid 3000 byte ICMPv6 Echo Request packetstep 2. Set IPv6 MTU of the LAN client to 1280 bytesstep 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytesstep 4. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destinationusing the packet generated in Step 1step 5. Verify that an ICMPv6 Echo Reply packet is received within 3 secondsReference:IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6

step 1. Generate a valid 3000 byte UDP Echo packetstep 2. Set IPv6 MTU of the LAN client to 1280 bytesstep 3. Set IPv6 MTU of the remoteHost WAN server to 1280 bytesstep 4. Initiate an outbound UDP Echo to a WAN IPv6 destination using thepacket generated in Step 1step 5. Verify that a UDP Echo response is received on the LANReference:IETF RFC2460 Sections 4, 4.2, 4.3, and 4.6

step 1. Send a Router Solicitation from the LANstep 2. Wait for a Router Advertisement from the DUTstep 3. Verify the fields in the Router AdvertisementReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Listen for a Router Advertisement on the LANstep 2. Wait for a second Router Advertisement on the LANstep 3. Verify that the DUT is periodically sending AdvertismentsReference: IETF RFC 4861 - Neighbor Discovery for IPv6NOTE: The testvar ipv6RAInterval will control how long this test waits for aRouter Advertisement.

step 1. Send a Neighbor Solicitation on the LAN for the DUT's link-local addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify fields of the Neighbor AdvertisementReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Neighbor Solicitation on the LAN for the DUT's global IPv6 addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify fields of Neighbor AdvertisementReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Send an Neighbor Solicitation for the DUT's link-local address with a hop-count of 64step 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT's link-local addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify source, destination, and contents of Neighbor AdvertisementReference:  IETF RFC 2462 - IPv6 Stateless Address AutoconfigurationSection 5.4 Duplicate Address Detection

step 1. Send an Neighbor Solicitation for the lanStack's link-local address to the DUT's link-local addressand its global addressstep 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrongSolicited-Node Multicast Addressstep 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1: Create a new client on the LANstep 2: Send a ping to the Global-Unicast-Address of the new clientstep 3: Verify the DUT sends an ICMPv6 Redirect messsagestep 4. Verify the ICMPv6 Redirect messagestep 5: Verify the new client responds to the pingReference: IETF RFC 4861 - Neighbor Discovery for IPv6Section 8 Redirect FunctionNOTE: This test is similar to ipv6_forward_3, except it verifies that theDUT is sending valid ICMPv6 Redirect messages back to the sender. Testipv6_forward_3 verifies that the packet is forwarded to the correctdestination.

step 1. Listen for a Router Advertisement on the LANstep 2. Check the "managed address configuration" flag (M bit) in the RouterAdvertisement received in Step 1step 3. If the DUT is configured to provide global addresses via DHCPv6 onthe LAN, the M bit should be set; if autoconfiguration is usedinstead, the M bit should not be setstep 4. If the DUT is configured to provide global addresses viaautoconfiguration on the LAN, and the "other stateful configuration"flag (O bit) is set, send a DHCPv6 Information-request including anOption 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 viaDHCPv6 and the "managed address configuration" flag(M bit) is set, send a DHCPv6 Information-request including anOption Request for DHCPv6 Options 23 'DNS Recursive Name Server'and 24 'Domain Search List' to the DUTstep 6. Verify that the DUT sends a DHCPv6 Reply in response to the DHCPv6Information-request message sent by the client in Steps 4 or 5step 7. Verify that the DUT's DHCPv6 Reply includes DHCPv6 Options 23 and 24Step 8. Verify the DNS server information provided by the DUT. If the testvaripv6DNStoLAN is set to "yes", the DNS server addresses provided shouldmatch the addresses of the DNS servers configured on the WAN. If theipv6DNStoLAN testvar is set to "no", the LAN side IPv6 address of theDUT should be provided as the DNS server.step 9. Verify the domain search list information provided by the DUTReference: IETF RFC 4861 - Neighbor Discovery for IPv6Section 4.2 "Router Advertisement Message Format"

step 1. Listen for Router Advertisements on the LAN for one RouterAdvertisement intervalstep 2. Verify at least one Router Advertisement contains a valid prefixbased on the DUT's LAN IPv6 addressstep 3. Verify that the prefix length associated with the prefix discoveredin 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 validlifetimestep 5. Check the autonomous address-configuration flag (A bit) in theRouter Advertisement received in Step 1step 6. If the DUT is configured to provide global addresses via DHCPv6 onthe LAN, the A bit should not be set; if autoconfiguration is usedinstead, the A bit should be setstep 7. Verify that the prefix discovered in Step 2 has the on-link flag(L bit) setReference: IETF RFC 4861 - Neighbor Discovery for IPv6Section 4.6.2 "Prefix Information"NOTE: This test is designed to work with DUT's that support only a singleLAN mode for address autoconfiguration, either DHCPv6 or autoconfiguration.DUT configurations in which both modes are enabled simultaneously (wherethe 'A' and 'M' bits are both set) are not currently supported by this test.

step 1. Listen for a Router Advertisement on the LANstep 2. Verify that one or more RDNSS options (25) are present in RAstep 3. Verify the addresses provided in RDNSS options. If the testvaripv6DNStoLAN is set to "yes", the DNS server addresses listedin the RDNSS option should match the addresses of the DNSservers configured on the WAN. If the ipv6DNStoLAN testvar isset to "no", the RDNSS option should list only the LAN sideIPv6 address of the DUT (global or link-local address).step 4. Verify the RDNSS option lifetimeReference: IETF RFC 6106 - IPv6 Router Advertisement Options for DNSConfigurationNOTE: This test is skipped if the testvar ipv6RdnssSupport is set to noindicating that the device does not support the RDNSS option.

step 1. Listen for a Router Advertisement on the LANstep 2. Verify that one or more DNSSL options (31) are present in RAstep 3. Verify the domain search list provided in the DNSSL option. Thedomain search list should contain the domain name specified by thetestvar wanDomainName.step 4. Verify the DNSSL option lifetimeReference: IETF RFC 6106 - IPv6 Router Advertisement Options for DNSConfigurationNOTE: This test is skipped if the testvar ipv6DnsslSupport is set to noindicating that the device does not support the DNSSL option.

step 1. Send a Router Solicitation from the WANstep 2. Wait to see if DUT sends a Router Advertisement on the WANstep 3. Verify the expected behaviorNote: The testvar ipv6ExpectRAonWan determines if this test shouldexpect to see Router Advertisements from the DUT on the WANReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Wait for a Router Advertisement on the WANstep 2. Wait for a second Router Advertisement on the WANstep 3. Verify if the DUT is periodically sending Advertisments as expectedNotes: The testvar ipv6ExpectRAonWan determines if this test shouldexpect to see Router Advertisements from the DUT on the WANThe testvar ipv6RAInterval will control how longthis test waits for a Router Advertisement.Reference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Neighbor Solicitation on the WAN for the DUT's link-local addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify fields of the Neighbor AdvertisementReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Neighbor Solicitation on the WAN for the DUT's global IPv6 addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify fields of Neighbor AdvertisementReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Send an invalid Neighbor Solicitation for the DUT's WAN-side global addressstep 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Duplicate-Address-Detection style Neighbor Solicition for the DUT'slink-local address on the WANstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify source, destination, and contents of Neighbor AdvertisementReference:  RFC 2462 - IPv6 Stateless Address AutoconfigurationSection 5.4 Duplicate Address Detection

step 1. Send an Neighbor Solicitation for the wanStack's link-local address to the DUT'slink-local address and its global addressstep 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Send an Neighbor Solicitation for the DUT's link-local address, but sent to the wrongSolicited-Node Multicast Addressstep 2. Verify the DUT ignores the Solicitation and doesn't respond with a Neighbor Advertisementstep 3. Send a valid Neighbor Solicitation to make sure DUT is properly respondingReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Check existing DHCPv6 bindings on the WAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify Valid and Preferred lifetimes for bindingstep 4. Verify that the binding has not expiredReference: IETF RFC 3315 Section 17 "DHCP Server Solicitation"

step 1. Wait for DHCPv6 client's current non-temporary address bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains Server Identifier option (2) with correctserver DUIDstep 4. Verify Renew contains IA_NA option (3) for same non-temporaryaddressstep 5. Send valid Reply to update bindingReference: IETF RFC 3315 Section 18.1.3 "Creation and Transmission ofRenew Messages"To extend the valid and preferred lifetimes for the addressesassociated with an IA, the client sends a Renew message to the serverfrom which the client obtained the addresses in the IA containing anIA option for the IA.  The client includes IA Address options in theIA option for the addresses associated with the IA.  The serverdetermines new lifetimes for the addresses in the IA according to theadministrative configuration of the server.

step 1. Configure the server to use an undefined server DUID formatstep 2. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3. Do not respond to Renew or Rebind messages from clientstep 4. Verify client sends Solicit message and obtains an IPv6 addressstep 5. Repeat steps 1 - 4 for various undefined DUID server formatsstep 6. Reestablish the DHCPv6 binding using the original DUID formatReference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"

step 1. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_NA option (3)step 5. Respond to first Solicit message with incorrect ClientIdentifier option(1) DUIDstep 6. Verify client restransmits Solicit messagestep 7. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 17.1.2 "Transmission of Solicit Messages"If the client does not receive any Advertise messages before thefirst RT has elapsed, it begins the retransmission mechanismdescribed in section 14.  The client terminates the retransmissionprocess as soon as it receives any Advertise message, and the clientacts on the received Advertise message without waiting for anyadditional Advertise messages.

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

step 1. Configure DHCPv6 server to use a large User Class option (15)to force IPv6 fragmentationstep 2. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3. Do not respond to Renew or Rebind messages from clientstep 4. Verify client sends Solicit messagestep 5. Respond to first Solicit message with Advertise containinglarge User Class Option (15) causing fragmentationstep 6. Verify client sends valid Request in response to Advertisestep 7. Disable server User Class option (15) created in Step 1step 8. If client fails Step 6, cleanup and wait for client toretransmit Solicit messagestep 9. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 18.1 "Client Behavior"

step 1. Configure DHCPv6 server to use bad UDP checksumsstep 2. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3. Do not respond to Renew or Rebind messages from clientstep 4. Verify client sends Solicit messagestep 5. Respond to first Solicit message with Advertise containinginvalid UDP checksumstep 6. Verify client does not send valid Request in response toAdvertisestep 7. Configure DHCPv6 server to use valid UDP checksumsstep 8. Wait for client to retransmit Solicit messagestep 9. Send valid Advertise message and wait for transaction tofinish

step 1. Wait for DHCPv6 client's current non-temporary address bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Inspect the composition of the DUID to ensure correctnessReference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"

step 1. Wait for DHCPv6 client's current non-temporary address bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains IA_NA option (3) for same non-temporaryaddressstep 4. Send valid DHCPv6 Reply with NoBinding status code (3)step 5. Verify DHCPv6 client sends Request messagestep 6. Verify Request contains IA_NA option (3) for same non-temporaryaddressReference: IETF RFC 3315 Section 18.1.8 "Receipt of Reply Messages"When the client receives a Reply message in response to a Renew orRebind message, the client examines each IA independently.  For eachIA in the original Renew or Rebind message, the client:-  sends a Request message if the IA contained a Status Code optionwith the NoBinding status (and does not send any additionalRenew/Rebind messages)-  sends a Renew/Rebind if the IA is not in the Reply message-  otherwise accepts the information in the IA

step 1. Wait for DHCPv6 client's current non-temporary address bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains IA_NA option (3) for same non-temporaryaddressstep 4. Send valid DHCPv6 Reply with UnspecFail status code (1)step 5. Verify DHCPv6 client recovers by retransmitting Renew orsending Requeststep 6. Verify Renew or Request contains IA_NA option (3) for samenon-temporary addressReference: IETF RFC 3315 Section 18.1.8 "Receipt of Reply Messages"If the client receives a Reply message with a Status Code containingUnspecFail, the server is indicating that it was unable to processthe message due to an unspecified failure condition.  If the clientretransmits the original message to the same server to retry thedesired operation, the client MUST limit the rate at which itretransmits the message and limit the duration of the time duringwhich it retransmits the message.

step 1. Wait for DHCPv6 client's current non-temporary address bindingT1 to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Do not respond to Renew messagestep 4. Verify DHCPv6 client sends Rebind messagestep 5. Verify Rebind contains IA_NA option (3) for same non-temporaryaddressstep 6. Send valid Reply to update bindingReference: IETF RFC 3315 Section 18.1.4 "Creation and Transmission ofRebind Messages"At time T2 for an IA (which will only be reached if the server towhich the Renew message was sent at time T1 has not responded), theclient initiates a Rebind/Reply message exchange with any availableserver.  The client includes an IA option with all addressescurrently assigned to the IA in its Rebind message.

step 1. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_NA option (3)step 5. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 18.1.4 "Creation and Transmission ofRebind Messages"The message exchange is terminated when the valid lifetimes of allthe addresses assigned to the IA expire (see section 10), at whichtime the client has several alternative actions to choose from; forexample:-  The client may choose to use a Solicit message to locate a newDHCP server and send a Request for the expired IA to the newserver.-  The client may have other addresses in other IAs, so the clientmay choose to discard the expired IA and use the addresses in theother IAs.

step 1. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_NA option (3)step 5. Do not respond to first Solicit messagestep 6. Verify client restransmits Solicit messagestep 7. Verify retransmitted Solicit message contains same transactionID as first Solicit messagestep 8. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 17.1.2 "Transmission of Solicit Messages"If the client does not receive any Advertise messages before thefirst RT has elapsed, it begins the retransmission mechanismdescribed in section 14.  The client terminates the retransmissionprocess as soon as it receives any Advertise message, and the clientacts on the received Advertise message without waiting for anyadditional Advertise messages.Reference: IETF RFC 3315 Section 15.1 "Use of Transaction IDs"The "transaction-id" field holds a value used by clients and serversto synchronize server responses to client messages.  A client SHOULDgenerate a random number that cannot easily be guessed or predictedto use as the transaction ID for each new message it sends.  Notethat if a client generates easily predictable transactionidentifiers, it may become more vulnerable to certain kinds ofattacks from off-path intruders.  A client MUST leave the transactionID unchanged in retransmissions of a message.

step 1.  Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2.  Do not respond to Renew or Rebind messages from clientstep 3.  Verify client sends Solicit messagestep 4.  Verify Solicit contains IA_NA option (3)step 5.  Send valid Advertise messagestep 6.  Verify client sends Request message containing IA_NA option (3)step 7.  Do not respond to Request messagestep 8.  Verify client retransmists Request messagestep 9.  Verify retransmitted Request message contains same transactionID as first Request messagestep 10. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 14 "Reliability of Client InitiatedMessage Exchanges"DHCP clients are responsible for reliable delivery of messages in theclient-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 theretransmission strategy to be used by clients in client-initiatedmessage exchanges.Reference: IETF RFC 3315 Section 15.1 "Use of Transaction IDs"The "transaction-id" field holds a value used by clients and serversto synchronize server responses to client messages.  A client SHOULDgenerate a random number that cannot easily be guessed or predictedto use as the transaction ID for each new message it sends.  Notethat if a client generates easily predictable transactionidentifiers, it may become more vulnerable to certain kinds ofattacks from off-path intruders.  A client MUST leave the transactionID unchanged in retransmissions of a message.NOTE: This test will not work if Rapid-Commit is used!

step 1. Change the client's DHCPv6 binding to use the newnon-temporary IPv6 address address specified by the testvar"ipv6WanIspNextIp"step 2. Verify DHCPv6 client sends DHCPv6 Renew or Requeststep 3. Verify Renew or Request contains IA_NA option (3) for samenon-temporary addressstep 4. Send valid DHCPv6 Reply with new non-temporary addressstep 5. Verify client updates with new non-temporary addressstep 6. Ping client's new non-temporary addressstep 7. Restore client's original non-temporary address by repeatingSteps 1 through 5 using original non-temporary addressstep 8. Ping client's original non-temporary addressReference: IETF RFC 3315 Section 18.1.8 "Receipt of Reply Messages"If the Reply was received in response to a Solicit (with a RapidCommit option), Request, Renew or Rebind message, the client updatesthe information it has recorded about IAs from the IA optionscontained in the Reply message:-  Record T1 and T2 times.-  Add any new addresses in the IA option to the IA as recorded bythe client.-  Update lifetimes for any addresses in the IA option that theclient already has recorded in the IA.-  Discard any addresses from the IA, as recorded by the client, thathave a valid lifetime of 0 in the IA Address option.-  Leave unchanged any information about addresses the client hasrecorded in the IA but that were not included in the IA from theserver.

step 1. Configure DHCPv6 server to use unknown DHCPv6 option typestep 2. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3. Do not respond to Renew or Rebind messages from clientstep 4. Verify client sends Solicit messagestep 5. Respond to first Solicit message with Advertise containingunknown DHCPv6 option typestep 6. Verify client sends valid Request in response to Advertisestep 7. Disable unknown DHCPv6 server optionstep 8. If client fails Step 6, cleanup and wait for client toretransmit Solicit messagestep 9. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 18.1 "Client Behavior"

step 1. Configure DHCPv6 server to use unknown DHCPv6 option typewith invalid lengthstep 2. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3. Do not respond to Renew or Rebind messages from clientstep 4. Verify client sends Solicit messagestep 5. Respond to first Solicit message with Advertise containingunknown DHCPv6 option typestep 6. Verify client does not send valid Request in response toAdvertisestep 7. Disable unknown DHCPv6 server optionstep 8. Wait for client to retransmit Solicit messagestep 9. Send valid Advertise message and wait for transaction tofinish

step 1. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_NA option (3)step 5. Verify Solicit contains Elapsed Time option (8) with value of 0step 6. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 22.9 "Elapsed Time Option"A client MUST include an Elapsed Time option in messages to indicatehow long the client has been trying to complete a DHCP messageexchange.  The elapsed time is measured from the time at which theclient sent the first message in the message exchange, and theelapsed-time field is set to 0 in the first message in the messageexchange.

step 1. Wait for DHCPv6 client's current non-temporary address bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_NA option (3)step 5. Verify Solicit contains Elapsed Time option (8) with value of 0step 6. Do not respond to Solicitstep 7. Verify client retransmists Solicit messagestep 8. Verify retransmitted Solicit message contains Elapsed Time option(8) with a value greater than 0step 9. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 22.9 "Elapsed Time Option"A client MUST include an Elapsed Time option in messages to indicatehow long the client has been trying to complete a DHCP messageexchange.  The elapsed time is measured from the time at which theclient sent the first message in the message exchange, and theelapsed-time field is set to 0 in the first message in the messageexchange.

step 1.  Configure DHCPv6 server to use Server Unicast Option (12)step 2.  Wait for DHCPv6 client's current non-temporary address bindingto expirestep 3.  Do not respond to Renew or Rebind messages from clientstep 4.  Verify client sends Solicit messagestep 5.  Respond to first Solicit message with Advertise containingServer Unicast Option (12)step 6.  Verify client sends valid Renew messagestep 7.  Verify Renew message in Step 6 is sent to the address inthe Server Unicast Option (12)step 8.  Disable Server Unicast option (12) created in Step 1step 9.  If client fails Step 6, cleanup and wait for client toretransmit Solicit messagestep 10. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 22.12 "Server Unicast Option"

step 1. Check existing DHCPv6 bindings on the WAN side of the CPEstep 2. Verify whether or not prefix binding existsstep 3. Verify Valid and Preferred lifetimes for bindingstep 4. Verify that the binding has not expiredReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"The requesting router uses a Request message to populate IA_PDs withprefixes.  The requesting router includes one or more IA_PD optionsin the Request message.  The delegating router then returns theprefixes for the IA_PDs to the requesting router in IA_PD options ina Reply message.

step 1. Wait for DHCPv6 client's current prefix bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains Server Identifier option (2) with correctserver DUIDstep 4. Verify Renew contains IA_NA option (3) for same addressprefixstep 5. Send valid Reply to update bindingReference: IETF RFC 3633 Section 7 "Overview of DHCP with PrefixDelegation"Before the valid lifetime on each delegated prefix expires, therequesting router includes the prefix in an IA_PD option sent in aRenew message to the delegating router.  The delegating routerresponds by returning the prefix with updated lifetimes to therequesting router.

step 1. Listen for IPv6 router advertisements from DUT on LANstep 2. Verify that router advertisement contains Prefix Informationoption (3) with valid prefix based on prefix assignedby DHCPv6 server on WANReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"Upon the receipt of a valid Reply message, for each IA_PD therequesting router assigns a subnet from each of the delegatedprefixes to each of the links to which the associated interfaces areattached, with the following exception: the requesting router MUSTNOT assign any delegated prefixes or subnets from the delegatedprefix(es) to the link through which it received the DHCP messagefrom the delegating router.Reference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement L-2:The IPv6 CE router MUST assign a separate /64 from itsdelegated prefix(es) (and ULA prefix if configured to provideULA addressing) for each of its LAN interfaces.

step 1. Listen for IPv6 router advertisements from DUT on LANstep 2. Verify that router advertisement contains Prefix Informationoption (3) with valid prefix based on prefix assignedby DHCPv6 server on WANstep 3. Verify Prefix Information option (3) contains a Valid lifetimenot greater than the valid lifetime provided by the DHCPv6server in the IA_PD Prefix optionstep 4. Verify Prefix Information option (3) contains a Preferredlifetime not greater than the preferred lifetime provided bythe DHCPv6 server in the IA_PD Prefix optionReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"If the requesting router assigns a delegated prefix to a link towhich the router is attached, and begins to send routeradvertisements for the prefix on the link, the requesting router MUSTset the valid lifetime in those advertisements to be no later thanthe valid lifetime specified in the IA_PD Prefix option.  Arequesting router MAY use the preferred lifetime specified in theIA_PD Prefix option.

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address prefix on the LANmatches the prefix delegated on the WANNOTE: This test only applies to configurations where LAN clientsobtain IPv6 addresses via DHCPv6

step 1. Listen for IPv6 router advertisements from DUT on LANstep 2. Verify that router advertisement contains Prefix Informationoption (3) with valid prefix based on prefix assignedby DHCPv6 server on WANstep 3. Verify Prefix Information option (3) contains a Valid lifetimenot greater than the valid lifetime provided by the DHCPv6server in the IA_PD Prefix optionstep 4. Verify Prefix Information option (3) contains a Preferredlifetime not greater than the preferred lifetime provided bythe DHCPv6 server in the IA_PD Prefix option

step 1. Listen for IPv6 RA from DUTstep 2. Verify RA contains prefix based on public IPv4 WANstep 3. Verify advertised prefix includes the expected subnet IDNote: The expected subnet ID bits can be configured using the testvaripv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length stringof hex characters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Bring down WAN linkstep 2. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 3. Verify that the advertised Router Lifetime is not greaterthan 0, or that the router advertisement does not containPrefix Information option (3) with valid prefix based onprefix assigned by DHCPv6 server on WANstep 4. Bring up WAN linkReference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement G-4:By default, an IPv6 CE router that has no defaultrouter(s) on its WAN interface MUST NOT advertiseitself as an IPv6 default router on its LAN interfaces.That is, the "Router Lifetime" is set to zero in allRouter 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 advertisingrouter and loses its IPv6 default router(s) on the WANinterface, it MUST explicitly invalidate itself as anIPv6 default router on each of its advertisinginterfaces by immediately transmitting one or moreRouter Advertisement messages with the "RouterLifetime" field set to zero [RFC4861].

step 1. Wait for DHCPv6 client's current prefix bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains IA_PD option (26) for same addressprefixstep 4. Send valid DHCPv6 Reply with NoBinding status code (3)step 5. Verify DHCPv6 client sends Request messagestep 6. Verify Request contains IA_PD option (26) for same addressprefixReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"

step 1. Wait for DHCPv6 client's current prefix bindingT1 timer to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Verify Renew contains IA_PD option (26) for same addressprefixstep 4. Send valid DHCPv6 Reply with UnspecFail status code (1)step 5. Verify DHCPv6 client recovers by retransmitting Renew orsending Requeststep 6. Verify Renew or Request contains IA_PD option (26) for sameprefixReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"

step 1. Wait for DHCPv6 client's current prefix bindingT1 to expirestep 2. Verify DHCPv6 client sends DHCPv6 Renewstep 3. Do not respond to Renew messagestep 4. Verify DHCPv6 client sends Rebind messagestep 5. Verify Rebind contains IA_PD option (26) for same addressprefixstep 6. Send valid Reply to update bindingReference: IETF RFC 3315 Section 18.1.4 "Creation and Transmission ofRebind Messages"At time T2 for an IA (which will only be reached if the server towhich the Renew message was sent at time T1 has not responded), theclient initiates a Rebind/Reply message exchange with any availableserver.  The client includes an IA option with all addressescurrently assigned to the IA in its Rebind message.

step 1. Wait for DHCPv6 client's current prefix bindingto expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains IA_PD option (26)step 5. Send valid Advertise message and wait for transaction tofinishReference: IETF RFC 3315 Section 18.1.4 "Creation and Transmission ofRebind Messages"The message exchange is terminated when the valid lifetimes of allthe addresses assigned to the IA expire (see section 10), at whichtime the client has several alternative actions to choose from; forexample:-  The client may choose to use a Solicit message to locate a newDHCP server and send a Request for the expired IA to the newserver.-  The client may have other addresses in other IAs, so the clientmay choose to discard the expired IA and use the addresses in theother IAs.

step 1. Change the client's DHCPv6 binding to use the new IPv6prefix specified by the testvar "dhcpv6WanAssignNextPrefix"step 2. Verify DHCPv6 client sends DHCPv6 Renew or Requeststep 3. Verify Renew or Request contains IA_PD option (26) forsame prefixstep 4. Send valid DHCPv6 Reply with new prefixstep 5. Verify client updates router advertisements on LAN with newprefix informationstep 6. Send pings from LAN client to an IPv6 remote host on theWAN to verify connectivity with new prefixstep 7. Restore client's original prefix by repeating Steps 1through 5 using original IPv6 prefixstep 8. Send pings from LAN client to an IPv6 remote host on theWAN to verify connectivity with original prefixReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"Upon the receipt of a valid Reply message, for each IA_PD therequesting router assigns a subnet from each of the delegatedprefixes to each of the links to which the associated interfaces areattached, with the following exception: the requesting router MUSTNOT assign any delegated prefixes or subnets from the delegatedprefix(es) to the link through which it received the DHCP messagefrom the delegating router.

step 1. Change the client's DHCPv6 binding to use the new IPv6prefix specified by the testvar "dhcpv6WanAssignNextPrefix"step 2. Verify DHCPv6 client sends DHCPv6 Renew or Requeststep 3. Verify Renew or Request contains IA_PD option (26) forsame prefixstep 4. Send valid DHCPv6 Reply with new prefixstep 5. Verify client updates router advertisements on LAN with newprefix informationstep 6. Verify client updates DHCPv6 server on the LAN with newprefixstep 7. Send pings from LAN DHCPv6 client to an IPv6 remote hoston the WAN to verify connectivity with new prefixstep 8. Restore client's original prefix by repeating Steps 1through 6 using original IPv6 prefixstep 9. Send pings from LAN DHCPv6 client to an IPv6 remote hoston the WAN to verify connectivity with original prefixReference: IETF RFC 3633 Section 12.1 "Requesting router behavior"Upon the receipt of a valid Reply message, for each IA_PD therequesting router assigns a subnet from each of the delegatedprefixes to each of the links to which the associated interfaces areattached, with the following exception: the requesting router MUSTNOT assign any delegated prefixes or subnets from the delegatedprefix(es) to the link through which it received the DHCP messagefrom the delegating router.NOTE: This test only applies to configurations where LAN clientsobtain IPv6 addresses via DHCPv6

step 1. Wait for DHCPv6 client's current prefix binding to expirestep 2. Do not respond to Renew or Rebind messages from clientstep 3. Verify client sends Solicit messagestep 4. Verify Solicit contains both IA_NA option (3) andIA_PD option (26)step 5. Send valid Advertise message and wait for transaction tofinishReference: 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.

step 1. Build a destination IPv6 address by setting all subnet bitsstep 2. This test assumes that this address is not configured on aninterfacestep 3. Send an UDP echo to this destination from the LAN clientstep 4. Verify the packet is not forwarded to the WANReference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement WPD-6:If the delegated prefix(es) are aggregate route(s) ofmultiple, more-specific routes, the IPv6 CE router MUSTdiscard packets that match the aggregate route(s), but notany of the more-specific routes.  In other words, the next-hop for the aggregate route(s) should be the nulldestination.  This is necessary to prevent forwarding loopswhen some addresses covered by the aggregate are notreachable [RFC4632].(a) The IPv6 CE router SHOULD send an ICMPv6 DestinationUnreachable message in accordance with Section 3.1 of[RFC4443] back to the source of the packet, if thepacket is to be dropped due to this rule.NOTE: This test is only applicable if the delegated prefix lengthis less than 64.

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address on the LAN includesthe expected SLA IDReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix AllocationRFC 3056 defines a 16 bit "SLA ID" field for subnetting. MostDUT's allow the SLA ID to be arbitrarily configured. This testverifies that the DUT uses the expected SLA ID. The expected SLAcan be configured using the testvar "ipv6LanSubnetId" which mustbe a hex string with four or less characters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 2. Verify that the DUT includes a Route Information option for thedelegated prefix configured using the testvardhcpv6WanAssignPrefixReferences: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement L-3:An IPv6 CE router MUST advertise itself as a router for thedelegated prefix(es) (and ULA prefix if configured to provideULA addressing) using the "Route Information Option" specifiedin Section 2.3 of [RFC4191].  This advertisement isindependent of having or not having IPv6 connectivity on theWAN interface.

step 1. Restart DHCPv6 on LAN client without sending a Release to the serverstep 2. Verify that the server assigns an address to the clientstep 3. Verify that the address assigned by the server is the same as theclient's original addressReference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"

step 1. Release client's current DHCPv6 bindingstep 2. Configure the client to use a client DUID with unknown formatstep 3. Restart DHCPv6 on clientstep 4. Verify the client obtains an addressstep 5. Repeat Steps 1 through 4 for different unknown client DUID formatsstep 6. Release the DHCPv6 bindingstep 7. Verify that the server assigns an address to the client using theclient's original DUID formatReference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"

step 1. Release client's current DHCPv6 bindingstep 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'sunicast addressstep 4. Restart DHCPv6 on LAN clientstep 5. Verify that server does not respond to unicast DHCPv6 Solicitmessages from clientstep 6. Restart DHCPv6 on LAN client using All_DHCP_Relay_Agents_and_Serversmulticast addressstep 7. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 13 "Transmission of Messages by a Client"Unless otherwise specified in this document, or in a document thatdescribes how IPv6 is carried over a specific type of link (for linktypes that do not support multicast), a client sends DHCP messages tothe All_DHCP_Relay_Agents_and_Servers.

step 1. Release client's current DHCPv6 bindingstep 2. Restart DHCPv6 on clientstep 3. Verify that LAN client receives DHCPv6 DNS Recursive Name Server(23) option from serverstep 4. Verify the DNS server addresses provided by the DHCPv6 server. Ifthe testvar ipv6DNStoLAN is set to "yes", the DNS server addressesprovided should match the addresses of the DNS servers configured onthe WAN. If the ipv6DNStoLAN testvar is set to "no", the LAN sideIPv6 address of the DUT should be provided as the DNS server.step 5. Check if LAN client receives DHCPv6 Domain Search List (24) optionfrom serverReference: IETF RFC 3646

step 1. Modify client to use an unknown server DUIDstep 2. Restart DHCPv6 on client with sending Release to the serverstep 3. Verify that server does not reply to Renew with unknown server DUIDReference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"

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

step 1. Release client's current DHCPv6 bindingstep 2. Configure client to omit address hint in DHCPv6 Request messagesstep 3. Restart DHCPv6 on clientstep 4. Verify client obtains an addressstep 5. Release client's current DHCPv6 bindingstep 6. Configure client to include address hint in DHCPv6 Request messagestep 7. Verify client obtains an addressReference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"

step 1. Configure the client to use a new IA_NA IAIDstep 2. Restart DHCPv6 on client without sending a Release to the serverstep 3. Verify that the server assigns a new address to the clientstep 4. Restore client's original IA_NA IAIDstep 5. Restart DHCPv6 on client without sending a Release to the serverstep 6. Verify that the server assigns an address to the clientstep 7. Verify that the address assigned by the server is the same as theclient's original addressReference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"

step 1. Configure client to use a large User Class (15) option to forceIPv6 fragmentationstep 2. Initiate Renew for client's current IPv6 addressstep 3. Verify that server responds to Renew with valid Reply messageReference: IETF RFC 3315 Section 18.2 "Server Behavior"

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

step 1. Initiate a DHCPv6 Renew for the client's current IPv6 addressstep 2. Verify that the server sends a Replystep 3. Inspect the composition of the server DUID in Reply to ensurecorrectnessReference: IETF RFC 3315 Section 9 "DHCP Unique Identifier (DUID)"

step 1. Initiate DHCPv6 Request from the clientstep 2. Verify that the server assigns the same address to the clientReference: IETF RFC 3315 Section 18.2.1 "Receipt of Request Messages"When the server receives a valid Request message, the server createsthe bindings for that client according to the server's policy andconfiguration information and records the IAs and other informationrequested by the client.

step 1. Initiate a DHCPv6 Request from the client using the server's unicastaddressstep 2. Verify the that the server sends a Reply message with a status codeof 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 clientto which the server has not sent a unicast option, the serverdiscards the Request message and responds with a Reply messagecontaining a Status Code option with the value UseMulticast, a ServerIdentifier option containing the server's DUID, the Client Identifieroption from the client message, and no other options.

step 1. Initiate a DHCPv6 Request from the client with an unknownIAID containing an unknown address, which is notconsidered "on link"step 2. Verify that the server sends a Reply message with a status code of4 '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 inany IA in the message from the client is not appropriate for the linkto which the client is connected, the server MUST return the IA tothe client with a Status Code option with the value NotOnLink.

step 1. Initiate a DHCPv6 Confirm from the clientstep 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"

step 1. Initiate a DHCPv6 Confirm from the client with an unknownIAID containing an unknown address, which is notconsidered "on link"step 2. Verify that the server sends a Reply message with a status code of4 'NotOnLink'Reference: IETF RFC 3315 Section 18.2.2 "Receipt of Confirm Messages"When the server receives a Confirm message, the server determineswhether the addresses in the Confirm message are appropriate for thelink to which the client is attached.  If all of the addresses in theConfirm message pass this test, the server returns a status ofSuccess.  If any of the addresses do not pass this test, the serverreturns a status of NotOnLink.  If the server is unable to performthis test (for example, the server does not have information aboutprefixes on the link to which the client is connected), or there wereno addresses in any of the IAs sent by the client, the server MUSTNOT send a reply to the client.

step 1. Initiate a DHCPv6 Confirm from the client with an unknown IAIDcontaining no addressesstep 2. Verify that the server does not send a Reply messageReference: IETF RFC 3315 Section 18.2.2 "Receipt of Confirm Messages"When the server receives a Confirm message, the server determineswhether the addresses in the Confirm message are appropriate for thelink to which the client is attached.  If all of the addresses in theConfirm message pass this test, the server returns a status ofSuccess.  If any of the addresses do not pass this test, the serverreturns a status of NotOnLink.  If the server is unable to performthis test (for example, the server does not have information aboutprefixes on the link to which the client is connected), or there wereno addresses in any of the IAs sent by the client, the server MUSTNOT send a reply to the client.

step 1. Initiate DHCPv6 Renew for the client's current IPv6 addressstep 2. Verify that the server updates the client's current IPv6 addressbindingReference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"

step 1. Initiate DHCPv6 Renew using the server's unicast addressstep 2. Verify the that the server sends a Reply message with a statuscode 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 towhich the server has not sent a unicast option, the server discardsthe Renew message and responds with a Reply message containing aStatus Code option with the value UseMulticast, a Server Identifieroption containing the server's DUID, the Client Identifier optionfrom the client message, and no other options.

step 1. Initiate DHCPv6 Renew with an unknown IAID that should not have abindingstep 2. Verify that the server sends a Reply message with a status code of3 '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 serverreturns the IA containing no addresses with a Status Code option setto NoBinding in the Reply message.

step 1. Initiate a DHCPv6 Renew from client with a valid IAID containingunknown addressstep 2. Verify that the server sends Reply message with correct IAIDstep 3. Verify Reply contains correct IA IPv6 addressstep 4. Verify Reply contains IA Preferred lifetime of 0step 5. Verify Reply contains IA Valid lifetime of 0step 6. Restart DHPCv6 on clientstep 7. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 18.2.3 "Receipt of Renew Messages"If the server finds that any of the addresses are not appropriate forthe link to which the client is attached, the server returns theaddress to the client with lifetimes of 0.

step 1. Initiate a DHCPv6 Rebind from the clientstep 2. Verify that the server updates the client's current IPv6 addressbindingReference: IETF RFC 3315 Section 18.2.4 "Receipt of Rebind Messages"

step 1. Initiate a DHCPv6 Rebind with a valid IAID containing unknownaddressstep 2. Verify that the server sends a Reply message with correct IAIDstep 3. Verify Reply contains correct IA IPv6 addressstep 4. Verify Reply contains IA Preferred lifetime of 0step 5. Verify Reply contains IA Valid lifetime of 0step 6. Restart DHPCv6 on clientstep 7. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 18.2.4 "Receipt of Rebind Messages"If the server finds that any of the addresses are not appropriate forthe link to which the client is attached, the server returns theaddress to the client with lifetimes of 0.

step 1. Initiate a DHCPv6 Information-request from clientstep 2. Verify response from serverReference: IETF RFC 3315 Section 18.2.5 "Receipt of Information-request Messages"

step 1. Initiate a DHCPv6 Release from the clientstep 2. Verify that the server sends a Reply message with a status code of0 'Success'step 3. Restart DHCPv6 on clientstep 4. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 18.2.6 "Receipt of Release Messages"

step 1. Initiate a DHCPv6 Release from the client using the server's unicastaddressstep 2. Verify the that the server sends a Reply message with a status codeof 5 'UseMulticast'step 3. Restart DHCPv6 on clientstep 4. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 18.2.6 "Receipt of Release Messages"When the server receives a Release message via unicast from a clientto which the server has not sent a unicast option, the serverdiscards the Release message and responds with a Reply messagecontaining a Status Code option with value UseMulticast, a ServerIdentifier option containing the server's DUID, the Client Identifieroption from the client message, and no other options.

step 1. Initiate DHCPv6 Release with an unknown IAID that should not have abindingstep 2. Verify that the server sends a Reply message with a status code of3 '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 aStatus Code option with the value NoBinding in the IA option.  No other options areincluded in the IA option.

step 1. Initiate a DHCPv6 Decline for the client's current IPv6 addressstep 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 serverstep 4. Verify that the server assigns an address to clientstep 5. Verify that the address assigned by the server is not the same asthe client's original addressReference: IETF RFC 3315 Section 18.2.7 "Receipt of Decline Messages"

step 1. Initiate a DHCPv6 Decline fro the client using the server's unicastaddressstep 2. Verify the that the server sends a Reply message with a status codeof 5 'UseMulticast'step 3. Restart DHCPv6 on LAN interface without sending a Release to theserverstep 4. Verify that the server assigns an address to the clientstep 5. Verify that the address assigned by the server is the same as theclient's original addressReference: IETF RFC 3315 Section 18.2.7 "Receipt of Decline Messages"When the server receives a Decline message via unicast from a clientto which the server has not sent a unicast option, the serverdiscards the Decline message and responds with a Reply messagecontaining a Status Code option with the value UseMulticast, a ServerIdentifier option containing the server's DUID, the Client Identifieroption from the client message, and no other options.

step 1. Initiate DHCPv6 Decline with an unknown IAID that should not have abindingstep 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 aStatus Code option with the value NoBinding in the IA option.  No other options areincluded in the IA option.

step 1. Configure client to use unknown DHCPv6 optionstep 2. Restart DHCPv6 on LAN client without sending a Release to the serverstep 3. Verify that the server assigns an address to the clientstep 4. Verify that the address assigned by the server is the same as theclient's original addressNote: To ensure compatibility with future client implemenations that maysupport yet to be defined DHCPv6 options, servers should ignore any optionsthat are unknown.

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

step 1. Configure the client to request DHCPv6 option 14 'Rapid Commit'step 2. Restart DHCPv6 on the clientstep 3. Verify that DHCPv6 server responds with Reply message containing the'Rapid Commit' optionstep 4. Verify that the server assigns an address to the clientstep 5. Verify that the address assigned by the server is the same as theclient's original addressReference: IETF RFC 3315 Section 22.14 "Rapid Commit Option"A client MAY include this option in a Solicit message if the clientis prepared to perform the Solicit-Reply message exchange describedin section 17.1.1.A server MUST include this option in a Reply message sent in responseto a Solicit message when completing the Solicit-Reply messageexchange.

step 1. Configure client to send DHCPv6 Request with both IA_NA and IA_PDoptionsstep 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the serverstep 3. Verify that the server assigns an address to the clientstep 4. Verify that the address assigned by the server is the same as theclient's original address

step 1. Configure client to send DHCPv6 Request with both IA_NA and IA_TAoptionsstep 2. Restart DHCPv6 on LAN without sending DHCPv6 Release to the serverstep 3. Verify that the server assigns an address to the clientstep 4. Verify that the address assigned by the server is the same as theclient's original address

step 1. Configure a relay agent on the LAN to send to DHCPv6 messages to theAll_DHCP_Servers multicast addressstep 2. Restart DHCPv6 on the client without sending a Release to the serverstep 3. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 20 "Relay Agent Behavior"The relay agent MAY be configured to use a list of destinationaddresses, which MAY include unicast addresses, the All_DHCP_Serversmulticast address, or other addresses selected by the networkadministrator.

step 1. Configure a relay agent on the LAN to send DHCPv6 messages to theserver's global unicast addressstep 2. Restart DHCPv6 on the client without sending a Release to the serverstep 3. Verify that the server assigns an address to the clientReference: IETF RFC 3315 Section 20 "Relay Agent Behavior"The relay agent MAY be configured to use a list of destinationaddresses, which MAY include unicast addresses, the All_DHCP_Serversmulticast address, or other addresses selected by the networkadministrator.

step 1. Configure a relay agent on the LAN to send DHCPv6 messages to theserver's global unicast addressstep 2. Configure a relay agent to include the Interface-Id (18) option inRelay-Forward messagesstep 3. Restart DHCPv6 on the client without sending a Release to the serverstep 4. Verify that the server sends a Relay-Reply message to the relayagentstep 5. Verify that the Relay-Reply message includes the originalInterface-Id (18) option value included by the relay agentstep 6. Wait for DHCPv6 transaction to completeReference: IETF RFC 3315 Section 22.18 "Interface-Id Option"The server MUST copy the Interface-Id option from the Relay-Forwardmessage into the Relay-Reply message the server sends to the relayagent in response to the Relay-Forward message.  This option MUST NOTappear in any message except a Relay-Forward or Relay-Reply message.

step 1. Turn off PPP LCP Echo-Reply on PPPoE serverstep 2. PPP client should send an LCP Echo-Requeststep 3. PPP client will not receive an LCP Echo-Replystep 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 upNOTE: Most PPPoE clients will terminate the existing PPPoE session afterseveral LCP Echo-Requests have failed. However, some routers willsimply initiate a new PPPoE session without sending a PADT. Thistest case does not FAIL the test if the existing PPPoE session is notterminated before starting a new PPPoE session. However, a warningwill be issued.NOTE: The amount of time the test waits to recover the PPP basedlink can be configured by adjusting the testvar pppRestartTimeout.This variable contains the number of milliseconds to wait forPPP based protocols to recover. The default is 300000 (300 seconds).NOTE: By default, CDRouter will still respond to ICMP EchoRequests during this test. This allows the test to verify failureoccurs because of PPP and not the ICMP Echo Replies. However, youcan configure CDRouter to also ignore ICMP Echo Requests duringthis test by setting the testvar pppFailUsesICMP to yes:testvar pppFailUsesICMP yes

step 1. Check the current PPPoE session is establishedstep 2. Terminate the current PPP session using LCP Terminatestep 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discoverystep 4. Verify PPPoE client brings new PPPoE session upNOTE: The amount of time the test waits to recover the PPP basedlink can be configured by adjusting the testvar pppRestartTimeout.This variable contains the number of milliseconds to wait forPPP based protocols to recover. The default is 300000 (300 seconds).

step 1. Send 5 LCP Echo-Requestsstep 2. Verify LCP Echo-Replies are receivedstep 3. Verify LCP Echo-Request data is echoed back in response

step 1. Terminate the current PPP session using LCP Terminatestep 2. Check for Magic Number in LCP Configure Requeststep 3. Wait for LCP Echo Request and verify Magic Number is the samestep 4. Send LCP Echo Requeststep 5. Verify Magic Number in LCP Echo Response is the sameRFC 1548 The Point-to-Point Protocol5.8 Echo-Request and Echo-ReplyNOTE: CDRouter does not fail this test if the PPPoE PPP clientdoes not send an LCP Echo Request. Some clients do notuse LCP Echo Requests automtically.

step 1. Terminate the current PPP session using LCP Terminatestep 2. Check for Interface Identifier in IPv6CP Configure Requeststep 3. Verify PPPoE link is restablishedReference: RFC 5072 IP Version 6 over PPP5.  Stateless Autoconfiguration and Link-Local AddressesThe interface identifier of IPv6 unicast addresses [5] of a PPPinterface SHOULD be negotiated in the IPV6CP phase of the PPPconnection setup (see Section 4.1).

step 1. Terminate the current PPP session using LCP Terminatestep 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discoverystep 3. Verify PPPoE client brings new PPPoE session upstep 4. Reject any PAP or CHAP authentication attemptsstep 5. Wait 60 seconds, continuing to reject PPP authenticationstep 6. Accept PPP authentication after 60 secondsstep 7. Send pings from LAN side to WAN side to force link to reestablishstep 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 basedlink can be configured by adjusting the testvar pppRestartTimeout.This variable contains the number of milliseconds to wait forPPP based protocols to recover. The default is 300000 (300 seconds).

step 1. Send LCP Configure-Request to PPP peerstep 2. Verify peer resends LCP configurationstep 3. Verify the configuration is the samestep 4. If the PPPoE link is terminated, issue ping to reestablish linkstep 5. Verify ping succeeds from LAN to WANNOTE: Renegotiating LCP can cause some PPP implementations to terminatethe PPP link or the PPPoE link. This test does not fail the DUT if thishappens, but it does issue a warning if the PPPoE session is restarted.NOTE: The amount of time the test waits to recover the PPP basedlink can be configured by adjusting the testvar pppRestartTimeout.This variable contains the number of milliseconds to wait forPPP based protocols to recover. The default is 300000 (300 seconds).

step 1. Send out LCP Echo-Request with length 4096, but no datastep 2. Peer may respond or drop LCP Echo-Requeststep 3. Verify PPP is still functioning using ICMP EchoNOTE: This test checks that the device under test behaves gracefullywhen it receives PPP options with a bad length. Some devices maystill respond to the LCP Echo-Request, but it is not considered a failure ifthe device does not respond.

step 1. Terminate the current PPP session using LCP Terminatestep 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discoverystep 3. Do not respond to the PADR packet from clientstep 4. Continue to ignore any PPPoE packets from the client untilthe client sends a new PADI packetstep 5. Restore PPPoE server to normal operationstep 6. Verify PPPoE client session recoversReference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)Section 8. Other ConsiderationsFrom RFC 2516 "If the Host is waiting to receive a PADS packet, asimilar timeout mechanism SHOULD be used, with the Host re-sendingthe PADR.  After a specified number of retries, the Host SHOULDthen resend a PADI packet."NOTE: The amount of time the test waits to recover the PPP basedlink can be configured by adjusting the testvar pppRestartTimeout.This variable contains the number of milliseconds to wait forPPP based protocols to recover. The default is 300000 (300 seconds).

step 1. Configure PPPoE server to use AC-Cookie Tag in PADO responsesstep 2. Terminate the current PPP session using LCP Terminatestep 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discoverystep 4. Send AC-Cookie Tag in PADOstep 5. Verify PADR from client contains AC-Cookie with the same cookie dataReference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)Appendix A. AC-CookieFrom RFC 2516 "If a Host receives this TAG, it MUST return the TAGunmodified in the following PADR."

step 1. Configure PPPoE server to use Relay-Session-Id in PADO responsesstep 2. Terminate the current PPP session using LCP Terminatestep 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discoverystep 4. If the PADI already contains a Relay-Session-Id from an actualPPPoE Relay server, configure the PPPoE server to use the sametag valuestep 5. Send Relay-Session-Id Tag in PADOstep 6. Verify PADR from client contains Relay-Session-Id tag with the same cookie dataReference: RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)Appendix A. Relay-Session-IdFrom RFC 2516 "If either the Host or Access Concentrator receives this TAG theyMUST include it unmodified in any discovery packet they send as a response."NOTE: Normally, CDRouter does not expect a PPPoE relay server to be presentbetween the PPPoE client and CDRouter. However, this test does check foran existing Relay-Session-Id in the PADI and will use this tag valuefor the test instead of generating a unique value. This allows the testto work with an existing PPPoE relay server on the WAN.

step 1. Listen for IPv6 RA from DUTstep 2. Verify RA contains 6to4 prefix based on public IPv4 WANstep 3. Verify 6to4 prefix contains a valid lifetimeReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Determine the DUT's LAN side IPv6 global addressstep 2. Send ICMPv6 Echo Request to the DUT's global IPv6 addressstep 3. Verify ICMPv6 Echo Response is received from the global IPv6 addressReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Listen for IPv6 RA from DUTstep 2. Verify RA contains 6to4 prefix based on public IPv4 WANstep 3. Verify advertised 6to4 prefix includes the expected SLA IDReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix AllocationRFC 3056 defines a 16 bit "SLA ID" field for subnetting. Most DUT's allowthe SLA ID to be arbitrarily configured. This test verifies that the DUTadvertises the expected SLA ID. The expected SLA can be configured usingthe testvar "ipv6LanSubnetId" which must be a hex string with four or lesscharacters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Forward IPv6 UDP to IPv6 address on 6to4 network that maps toremoteHost IPv4step 2. Verify remoteHost IPv4 on the WAN received tunneled IPv6 packetstep 3. Verify return IPv6 UDP traffic is forwarded back from remoteHost IPv4Reference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 5.1 Simple scenario - all sites work the same

step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 networkstep 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packetstep 3. Verify return IPv6 UDP traffic is forwarded back from relay serverReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 5.2 Mixed scenario with relay to native IPv6

step 1. Forward IPv6 UDP to remoteHostv6 address on non-6to4 networkstep 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packetsetp 3. Verify IPv4 src address of tunneled IPv6 traffic matches WANIPv4 addressReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 5.2 Mixed scenario with relay to native IPv6

step 1. Forward IPv6 UDP to remoteHostv6 addressstep 2. Verify 6to4 relay server on the WAN received tunneled IPv6 packetsetp 3. Verify 'do not fragment' flag is not set on IPv4 headerReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 4. Maximum Transmission UnitThe IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulatingIPv4 header.

step 1. Configure 6to4 Relay server to use an IPv4 MTU of 252step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP datastep 3. Verify 6to4 relay server on the WAN received tunneled IPv6 packetstep 4. Send same UDP data back through 6to4 relay serverstep 5. 6to4 relay server will fragment the IPv4 packetstep 6. Verify UDP data is sent to original IPv6 LAN clientReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 4. Maximum Transmission Unit

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IP addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6to4 prefix based on new public WAN IPstep 5. Verify 6to4 prefix contains a valid lifetimestep 6. Bring down WAN linkstep 7. Bring up WAN link with new original IP addressReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IPv4 addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6to4 prefix based on new public WAN IPv4step 5. Verify 6to4 prefix contains a valid lifetimestep 6. Ping DUT's new IPv6 global addressstep 7. Verify IPv6 ping responsestep 8. Bring down WAN linkstep 9. Bring up WAN link with new original IPv4 addressReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IPv4 addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6to4 prefix based on new public WAN IPv4step 5. Verify 6to4 prefix contains a valid lifetimestep 6. Forward IPv6 traffic from LAN to remoteHostv6step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 addressstep 8. Bring down WAN linkstep 9. Bring up WAN link with new original IPv4 addressReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Bring down WAN linkstep 2. Listen for IPv6 RA from DUTstep 3. Verify either the RA does not contain previous 6to4 prefixor the advertised 6to4 prefix preferred lifetime is now 0step 4. Bring up WAN linkstep 5. Listen for IPv6 RA from DUTstep 6. Verify the RA contains the expected 6to4 prefixReference: RFC 3056Connection of IPv6 Domains via IPv4 Clouds

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address on the LAN containsa 6to4 prefix based on public IPv4 WANReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix Allocation

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address on the LAN containsa 6to4 prefix which includes the expected SLA IDReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix AllocationRFC 3056 defines a 16 bit "SLA ID" field for subnetting. MostDUT's allow the SLA ID to be arbitrarily configured. This testverifies that the DUT uses the expected SLA ID. The expected SLAcan be configured using the testvar "ipv6LanSubnetId" which mustbe a hex string with four or less characters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Listen for IPv6 RA from DUTstep 2. Verify RA contains 6rd prefix based on public IPv4 WANstep 3. Verify 6rd prefix contains a valid lifetimeReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Determine the DUT's LAN side IPv6 global address basedstep 2. Send ICMPv6 Echo Request to the DUT's global IPv6 addressstep 3. Verify ICMPv6 Echo Response is received from the global IPv6 addressReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Listen for IPv6 RA from DUTstep 2. Verify RA contains 6rd prefix based on public IPv4 WANstep 3. Verify advertised 6rd prefix includes the expected subnet IDReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)Note: The expected subnet ID bits can be configured using the testvaripv6LanSubnetId. The ipv6LanSubnetId testvar is a variable length stringof hex characters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Forward IPv6 UDP to IPv6 address on 6rd network that maps tonew WAN side IPv4 gateway based on testvar wanIspNextIpstep 2. Verify new gateway on the WAN receives tunneled IPv6 packetstep 3. Verify return IPv6 UDP traffic is forwarded back from new IPv4 gatewayReference: RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)IPv6 communication between customer sites of a same ISP is directacross the ISP IPv4 infrastructure: when a CPE sees that the IPv6destination address of an outgoing packet starts with its own 6rdrelay ISPv6 prefix, it takes the 32 bits that follow this prefix asIPv4 destination of the encapsulating packet.NOTE: The testvar wanIspNextIp must be properly configured in orderfor this test to work correctly. Both wanIspNextIp and wanIspAssignIpmust be in the same WAN network.

step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd networkstep 2. Verify 6rd relay server on the WAN received tunneled IPv6 packetstep 3. Verify return IPv6 UDP traffic is forwarded back from relay serverReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Forward IPv6 UDP to remoteHostv6 address on non-6rd networkstep 2. Verify 6rd relay server on the WAN received tunneled IPv6 packetsetp 3. Verify IPv4 src address of tunneled IPv6 traffic matches WANIPv4 addressReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Forward IPv6 UDP to remoteHostv6 addressstep 2. Verify 6rd relay server on the WAN received tunneled IPv6 packetsetp 3. Verify 'do not fragment' flag is not set on IPv4 headerReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)Reference: RFC 3056 Connection of IPv6 Domains via IPv4 CloudsSection 4. Maximum Transmission UnitThe IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulatingIPv4 header.

step 1. Configure 6rd Relay server to use an IPv4 MTU of 252step 2. Forward IPv6 UDP to remoteHostv6 address with 1000 bytes of UDP datastep 3. Verify 6rd relay server on the WAN received tunneled IPv6 packetstep 4. Send same UDP data back through 6rd relay serverstep 5. 6rd relay server will fragment the IPv4 packetstep 6. Verify UDP data is sent to original IPv6 LAN clientReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IP addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6rd prefix based on new public WAN IPstep 5. Verify 6rd prefix contains a valid lifetimestep 6. Bring down WAN linkstep 7. Bring up WAN link with new original IP addressReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IPv4 addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6rd prefix based on new public WAN IPv4step 5. Verify 6rd prefix contains a valid lifetimestep 6. Ping DUT's new IPv6 global addressstep 7. Verify IPv6 ping responsestep 8. Bring down WAN linkstep 9. Bring up WAN link with new original IPv4 addressReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Bring down WAN linkstep 2. Bring up WAN link with new external IPv4 addressstep 3. Listen for IPv6 RA from DUTstep 4. Verify RA contains 6rd prefix based on new public WAN IPv4step 5. Verify 6rd prefix contains a valid lifetimestep 6. Forward IPv6 traffic from LAN to remoteHostv6step 7. Verify traffic is forwarded and src IPv4 of tunneled packets matched new IPv4 addressstep 8. Bring down WAN linkstep 9. Bring up WAN link with new original IPv4 addressReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Bring down WAN linkstep 2. Listen for IPv6 RA from DUTstep 3. Verify either the RA does not contain previous 6rd prefixor the advertised 6rd prefix preferred lifetime is now 0step 4. Bring up WAN linkstep 5. Listen for IPv6 RA from DUTstep 6. Verify the RA contains the expected 6rd prefixReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address on the LAN containsa 6rd prefix based on public IPv4 WANReference: RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

step 1. Check existing DHCPv6 bindings on the LAN side of the CPEstep 2. Verify whether or not a non-temporary address binding existsstep 3. Verify that the non-temporary address on the LAN containsa 6rd prefix which includes the expected SLA IDReference: RFC 3056Connection of IPv6 Domains via IPv4 CloudsSection 2. IPv6 Prefix AllocationRFC 3056 defines a 16 bit "SLA ID" field for subnetting. MostDUT's allow the SLA ID to be arbitrarily configured. This testverifies that the DUT uses the expected SLA ID. The expected SLAcan be configured using the testvar "ipv6LanSubnetId" which mustbe a hex string with four or less characters. Examples:testvar ipv6LanSubnetId fffftestvar ipv6LanSubnetId 1

step 1. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destinationstep 2. Verify ICMPv6 Echo Reply is received

step 1. Configure additional lan hoststep 2. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 1step 3. Verify ICMPv6 Echo Reply is receivedstep 4. Initiate an outbound ICMPv6 Echo Request to a WAN destination from host 2step 5. Verify ICMPv6 Echo Reply is received

step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's global IPv6 addressstep 2. Verify ICMPv6 Echo Reply is received

step 1. Initiate an outbound ICMPv6 Echo Request to the router's LAN side link-local addressstep 2. Verify ICMPv6 Echo Reply is received

step 1. Determine expected DUT global addressstep 2. Initiate an outbound ICMPv6 Echo Request to the DUT's global address from the LANstep 3. Verify response is receivedstep 4. Initiate an inbound ICMPv6 Echo Request to the DUT's global address from the WANstep 5. Verify the device behaves as expected.Note: the testvar ipv6WanPingRespond is used to determine if pinging the WAN-side of the DUTis expcted to work or not.  It defaults to "no" which signifies that the device will notrespond to IPv6 pings on its WAN interface.

step 1. Initiate an outbound ICMPv6 Ping to ff02::2 from the link-local IPv6 addressstep 2. Verify ICMPv6 Echo Reply is received

step 1. Initiaite an outbound ICMPv6 Ping to ff02::2 from the global-prefixstep 2. Verify ICMPv6 Echo Reply is received

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 Responsestep 3. Verify the Echo Response is from the DUTstep 4. Continue waiting until the DUT responds, or timeout

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 Responsestep 3. Verify the Echo Response is from the DUTstep 4. Continue waiting until the DUT responds, or timeout

step 1. Set the IP Hop Limit of outbound packets to 1step 2. Forward an IPv6 packet from a LAN client to the WANstep 3. Verify ICMPv6 Time Exceeded packet is sent to initial LAN hoststep 4. Verify the ICMPv6 Time Exceeded packet contains the IP header of the original packetReference:RFC 2463

step 1. Forward a UDP packet from a LAN client to the WANstep 2. Verify packet is received on WAN sidestep 3. Send ICMPv6 Time Exceeded packet with original UDP packet as datastep 4. Verify ICMPv6 Time Exceeded packet is received by LAN hoststep 5. Verify the contents of the original IP packet includedin the ICMPv6 Time Exceeded packet

step 1. Forward a UDP packet from a LAN client to the WANstep 2. Verify packet is received on WAN sidestep 3. Send ICMPv6 Destination Unreachable packet with original UDP packet as datastep 4. Verify ICMPv6 Destination Unreachable is received by LAN hoststep 5. Verify the contents of the original IPv6 packet includedin the ICMPv6 Destination Unreachable packet

step 1. Forward a UDP packet from a LAN client to the WANstep 2. Verify packet is received on WAN sidestep 3. Send ICMPv6 Packet Too Big packet with MTU size 1280step 4. Verify ICMPv6 Packet Too Big is received by LAN hoststep 5. Verify the received MTU in Packet Too Big message is unchanged

step 1. Forward a UDP packet from a LAN client to the WANstep 2. Verify packet is received on WAN sidestep 3. Send ICMPv6 Parameter Problem packet with pointer value of 40step 4. Verify ICMPv6 Parameter Problem is received by LAN hoststep 5. Verify the pointer value is unchangedstep 6. Verify the contents of the include IPv6 packet in the ICMPv6 packet

step 1. Send 1500 byte UDP packetstep 2. Check for an ICMPv6 Packet Too Big packet with code = 0step 3. Repeat process 2 more times until an ICMPv6 Packet Too Bigis received, or all 3 packets are sentstep 4. If an ICMPv6 Packet Too Big packet was sent, verify thatthe code value is 0 and verify the MTU value in the ICMP headerstep 5. Reduce the UDP packet size by 1 byte and repeat the processuntil no ICMPv6 Packet Too Big packet is sentstep 6. When a packet size is found that does not generate anICMPv6 Packet Too Big message,verify packets can beforwarded using this packet sizestep 7. Verify the final MTU size is the same as the MTU sizereported in the ICMPv6 Packet Too Big packetReference: RFC 1981: Path MTU Discovery for IP version 6NOTE: This test starts with an initial MTU of 1500. If the WAN interfacealready supports this MTU (DHCP), then this test will pass withoutexercising the real part of Path MTU Discovery. If the interfacehas VLANs enabled, the initial MTU will be 1496 bytes.NOTE: Some devices rate limit the number of ICMP packets that may besent. This test will send 3 UDP packets over a 15 second windowin order to generate an ICMP Packet Too Big packet. If therouter under test uses rate limiting on ICMP packets, it must allowat least one ICMP packet every 10 seconds.

step 1. Send a Router Solicitation from LAN sidestep 2. Verify a Router Advertisement with an MTU option isreceived on LAN sidestep 3. Send 1500 byte UDP packetstep 4. Check for an ICMPv6 Packet Too Big packetstep 5. Repeat process 2 more times until an ICMPv6 Packet Too Bigis received, or all 3 packets are sentstep 6. If an ICMPv6 Packet Too Big packet was sent, verify thatthe MTU value is less than or equal to the MTU optioncontained in the Router Advertisement.step 7. Reduce the UDP packet size by 1 byte and repeat the processuntil no ICMPv6 Packet Too Big packet is sentstep 8. Verify the final MTU size is less than or equal to the MTUoption contained in the Router Advertisement.Reference: RFC 1981: Path MTU Discovery for IP version 6NOTE: This test starts with an initial MTU of 1500. If the WAN interfacealready supports this MTU (DHCP), then this test will pass withoutexercising the real part of Path MTU Discovery. If the interfacehas VLANs enabled, the initial MTU will be 1496 bytes.NOTE: Some devices rate limit the number of ICMP packets that may besent. This test will send 3 UDP packets over a 15 second windowin order to generate an ICMP Packet Too Big packet. If therouter under test uses rate limiting on ICMP packets, it must allowat least one ICMP packet every 10 seconds.

step 1. Initiate a WAN TCP connection to the DUT's global IPv6 address management portstep 2. Verify the connection is not established

step 1. Initiate a WAN TCP connection to a LAN client addressstep 2. Verify the connection is not established

step 1. Send TCP SYN packets from WAN to each port of the LAN Client in the port scan rangestep 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 ofmilliseconds to wait in between the sending of each packet:testvar portScanDelay 100NOTE: The list of closed and open ports can be configured using the'ipv6FirewallTcpClosedPorts' and 'ipv6FirewallTcpOpenPorts' testvars:testvar ipv6FirewallTcpClosedPorts "2323"testvar ipv6FirewallTcpOpenPorts "22 443"

step 1. Send UDP packets from WAN to each port of the LAN Client in the port scan rangestep 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 ofmilliseconds to wait in between the sending of each packet:testvar portScanDelay 100NOTE: The list of closed and open ports can be configured using the'ipv6FirewallTcpClosedPorts' and 'ipv6FirewallTcpOpenPorts' testvars:testvar ipv6FirewallUdpClosedPorts "2323"testvar ipv6FirewallUdpOpenPorts "22 443"

step 1. Set the IPv6 fragmentation size to 56 bytesstep 2. Send TCP SYN packets from WAN to each port in the port scan rangeof the LAN Clientstep 3. Verify packets are not forwarded to LAN Clientstep 4. Verify the router does not accept the TCP connection orsend a RST for the TCP connection unless the port hasbeen configured as an open or closed portstep 5. Do not flag ports that have port forwarding configuredNOTE: The speed of the scan can be adjusted using the 'portScanDelay'testvar. By default, it is set to 1. The value indicates the number ofmilliseconds to wait in between the sending of each packet:testvar portScanDelay 100NOTE: The list of closed and open ports can be configured using the'firewallTcpClosedPorts' and 'firewallTclOpenPorts' testvars:testvar ipv6FirewallTcpClosedPorts "2323"testvar ipv6FirewallTcpOpenPorts "22 443"

step 1. Send a TCP SYN from LAN host to IP address on WANstep 2. Send a TCP SYN from the WAN host to the original LAN hostusing the same TCP source portstep 3. If the router blocks simultaneous TCP SYNs(testvar 'natSimultaneousTcp' is set to no), verify the TCPSYN from the WAN is droppedORIf the router supports simultaneous TCP SYNs(testvar 'natSimultaneousTcp' is set to yes), verify the TCPSYN from the WAN is forwarded to the LANstep 4. Repeat step 1 using new TCP port numbersstep 5. Send a TCP SYN from the WAN host to the original LAN hostusing a new TCP source portstep 6. Verify the TCP SYN from the WAN is droppedNOTE: This test verifies that the firewall only allows TCP packetsfor established TCP sessions. If simultaneous TCP open is supported throughthe firewall, this test will verify that TCP SYN packets from the WAN areforwarded to the LAN. If simultaneous TCP open through the firewall isnot supported, the test will verify that no TCP SYN packets are allowedfrom 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.

step 1. Configure a variety of invalid source addresses for trafficstep 2. Send traffic with these addresses to the WANstep 3. Verify packets are not forwardedReference: RFC 6092 Section 3.1 "Stateless Filters"REC-1: Packets bearing multicast source addresses in their outer IPv6headers MUST NOT be forwarded or transmitted on any interface.REC-2: Packets bearing multicast destination addresses in their outerIPv6 headers of equal or narrower scope (see "IPv6 Scoped AddressArchitecture" [RFC4007]) than the configured scope boundary level ofthe gateway MUST NOT be forwarded in any direction.  The DEFAULTscope boundary level SHOULD be organization-local scope, and itSHOULD be configurable by the network administrator.

Step 1. Create a new vnode on the RemoteHostv6Step 2. Send UDP traffic to the LAN with forbidden sources from vnodeStep 3. Verify traffic is not forwarded onto the LANReference: RFC 6092 Section 3.1 "Stateless Filters"REC-1: Packets bearing multicast source addresses in their outer IPv6headers MUST NOT be forwarded or transmitted on any interface.REC-2: Packets bearing multicast destination addresses in their outerIPv6 headers of equal or narrower scope (see "IPv6 Scoped AddressArchitecture" [RFC4007]) than the configured scope boundary level ofthe gateway MUST NOT be forwarded in any direction.  The DEFAULTscope boundary level SHOULD be organization-local scope, and itSHOULD be configurable by the network administrator.

step 1. Create a new LAN clientstep 2. Assign a different global prefix to the LANstep 3. Send traffic to the WAN from the martian source addressstep 4. Verify traffic is not forwardedReference: RFC 6092 Section 3.1 "Stateless Filters"REC-5: Outbound packets MUST NOT be forwarded if the source addressin their outer IPv6 header does not have a unicast prefix configuredfor use by globally reachable nodes on the interior network.

step 1. Create a new stack on the remoteHoststep 2. Assign the stack the same global prefix as is used on the LANstep 3. Send traffic to the LAN from the remote stackstep 4. Verify traffic is NOT forwarded to the LANReference: RFC 6092 Section 3.1 "Stateless Filters"REC-6: Inbound packets MUST NOT be forwarded if the source address intheir outer IPv6 header has a global unicast prefix assigned for useby globally reachable nodes on the interior network.

step 1. Send traffic from the LAN to the WAN with a link-local source addressstep 2. Verify traffic is not forwarded to the WANReference: RFC 6092 Section 3.1 "Stateless Filters"REC-7: By DEFAULT, packets with unique local source and/ordestination addresses [RFC4193] SHOULD NOT be forwarded to or fromthe exterior network.

step 1. Initiate a new UDP session with the device to allow inbound trafficstep 2. Configure a new stack on the WAN with a link-local prefix as the sourcestep 3. Send traffic from this new stack to the LANstep 3. Verify traffic is not forwarded to the LANReference: RFC 6092 Section 3.1 "Stateless Filters"REC-7: By DEFAULT, packets with unique local source and/ordestination addresses [RFC4193] SHOULD NOT be forwarded to or fromthe exterior network.

step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT'sglobal IPv6 addressstep 2. Verify that the query is received by either the primary or backupDNS server on the WANstep 3. Verify that the DNS response is received by the LAN clientstep 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to theDUT's global IPv6 addressstep 5. Verify that a DNS response is not received by the remote host on theWAN that initiated the original requestReference: RFC 6092 Section 3.1 "Stateless Filters"REC-8: By DEFAULT, inbound DNS queries received on exteriorinterfaces MUST NOT be processed by any integrated DNS resolvingserver.

step 1. Start new DHCPv6 client on WAN interfacestep 2. Verify new client does not obtain an IPv6 address via DHCPv6 fromthe DUTstep 3. Send three pings from LAN to WAN to verify that the DUT is stilloperating properlyReference: RFC 6092 Section 3.1 "Stateless Filters"REC-9: Inbound DHCPv6 discovery packets [RFC3315] received onexterior interfaces MUST NOT be processed by any integrated DHCPv6server or relay agent.

step 1. Send IPv6 UDP packet from LAN to WANstep 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable messagestep 3. Verify ICMPv6 Destination Unreachable message is received on the LANstep 4. Send UDP response from WAN to LANstep 5. Verify UDP response is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092Simple Security in IPv6 Gateway CPEREC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6"Destination Unreachable" and "Packet Too Big" messages containingUDP headers that match the flow state record.REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a UDP flow.

step 1. Establish TCP connection from LAN to WANstep 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connectionstep 3. Verify ICMPv6 Destination Unreachable message is received on the LANstep 4. Send TCP data segment from WAN to LAN for the sessionstep 5. Verify TCP data segment is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092Simple Security in IPv6 Gateway CPEREC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6"Destination Unreachable" and "Packet Too Big" messages containingTCP headers that match the flow state record.REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a TCP flow.

step 1. Send IPv6 UDP packet from LAN to WANstep 2. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big messagestep 3. Verify ICMPv6 Too Big message is received on the LANstep 4. Send UDP response from WAN to LANstep 5. Verify UDP response is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092Simple Security in IPv6 Gateway CPEREC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6"Destination Unreachable" and "Packet Too Big" messages containingUDP headers that match the flow state record.REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a UDP flow.

step 1. Establish TCP connection from LAN to WANstep 2. Send an ICMPv6 Packet Too Big message from the WAN for the connectionstep 3. Verify ICMPv6 Packet Too Big message is received on the LANstep 4. Send TCP data segment from WAN to LAN for the sessionstep 5. Verify TCP data segment is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092Simple Security in IPv6 Gateway CPEREC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6"Destination Unreachable" and "Packet Too Big" messages containingTCP headers that match the flow state record.REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a TCP flow.

step 1. Configure the DUT to block outbound access from the LAN to specific TCP portsstep 2. Send a TCP SYN packet from the LAN to each blocked portstep 3. Verify the DUT does not forward TCP packets to any of the blocked portsThe firewallOutBlockedTcpPorts testvar is used to determine the list of TCP ports that the DUT has been configured to block access to.

step 1. Configure the DUT to block outbound access from the LAN to specific UDP portsstep 2. Send a UDP packet from the LAN to each blocked portstep 3. Verify the DUT does not forward UDP packets to any of the blocked portsThe firewallOutBlockedUdpPorts testvar is used to determine the list of UDP ports that the DUT has been configured to block access to.

step 1. Configure the DUT to block outbound access from the LAN to specific IP Protocol typesstep 2. Send an IP packet from the LAN to the WAN for each blocked IP protocolstep 3. Verify the DUT does not forward any of the blocked IP protocolsThe firewallOutBlockedIpProtos testvar is used to determine the list of IP Protocol typesthat the DUT has been configured to block access to.

step 1. Initiate an outbound TCP connection to HTTP server over IPv6step 2. Verify the TCP connection is establishedstep 3. Verify the IPv6 source address on the WAN side is the LAN client's addressstep 4. Send HTTP GET request to serverstep 5. Verify HTTP response is receivedstep 6. Close TCP connection from LAN side

step 1. Initiate an outbound TCP connection to HTTPS server over IPv6step 2. Verify the TCP connection is establishedstep 3. Verify the IPv6 source address on the WAN side is the LAN client's addressstep 4. Verify the TLS session is establishedstep 5. Send HTTPS GET request to serverstep 6. Verify HTTPS response is receivedstep 7. Close TCP connection from LAN side

step 1. Enable a DNS server on the IPv6 remoteHoststep 2. Initiate an AAAA IPv6 DNS query to the IPv6 remoteHoststep 3. Verify the query is received by real DNS server on the WAN sidestep 4. Send a return response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case. The DNS relay or proxy must understand IPv6 DNStype AAAA lookups.Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses

step 1. Initiate an outbound TCP connection to FTP server portstep 2. Verify the connection is establishedstep 3. Send the FTP EPRT command using all upper case lettersstep 4. Verify router translates EPRT command using router's addressstep 5. Initiate inbound TCP connection for FTP data connectionstep 6. Verify inbound TCP connection is establishedstep 7. Close both connectionsReference: RFC 2428 FTP Extensions for IPv6 and NATs

step 1. Initiate an outbound TCP connection to SMTP serverstep 2. Send email message using SMTP serverstep 3. Verify SMTP server correctly receives email messagestep 4. Close SMTP session from LAN sideReference:RFC 821 Simple Mail Transfer Protocol

step 1. Initiate an outbound TCP connection to POP3 serverstep 2. Retreive email messages using POP3 protocolstep 3. Verify POP3 server correctly returns email messagesstep 4. Close POP3 session from LAN sideReference:RFC 1939 Post Office Protocol Version 3

step 1. Startup a TFTP server on the WANstep 2. Initiate an outbound TFTP connection to TFTP server from LANstep 3. Send TFTP GET to receive file via TFTPstep 4. Verify TFTP server correctly returns file via TFTPstep 5. Close TFTP session from LAN sideReference:RFC 1350 TFTP Protocol Version 2

step 1. Initiate an outbound NTP connection to NTP serverstep 2. Verify NTP request is sent to the WANstep 3. Verify NTP response is sent to LAN client

step 1. Initiate an outbound STUN Binding Request to remoteHoststep 2. Verify STUN Binding Response is receivedstep 3. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6address of the STUN clientReference: RFC 3489 STUN

step 1. Configure STUN server and client to use authenticationstep 2. Initiate an outbound STUN Binding Request to remoteHoststep 3. STUN server should sent back a 401 Binding Error Responsestep 4. STUN client retransmits Binding Request using message-integrity attributestep 5. Verify STUN Binding Response is receivedstep 6. Verify the STUN MAPPED-ADDRESS matches the expected global IPv6address of the STUN clientReference: RFC 3489 STUN

step 1. Forward an IPv6 packet from a LAN client to the WANstep 2. Verify the Hop Limit of the packet is decremented by 1Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) SpecificationSection 3. IPv6 Header FormatNOTE: Decremented by 1 by each node that forwards the packet.

step 1. Set the IPv6 Hop Limit of outbound packets to 1step 2. Forward an IPv6 packet from a LAN client to the WANstep 3. Verify the packet is not forwardedstep 4. Repeat the test with a Hop Limit of 0Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) SpecificationSection 3. IPv6 Header FormatNOTE: The packet is discarded if Hop Limit is decremented to zero.

step 1. Forward an IP packet from a LAN client to another LAN clientstep 2. Forward packet using router's MAC addressstep 3. Verify packet is forwarded back out the LAN interfaceNOTE: The router may send an ICMP Redirect back to the originator.

step 1. Initiate an outbound UDP connection with UDP data length of 4step 2. Verify packets are received on the WAN interfacestep 3. Continue forwarding until the maximum unfragmented packet length is reachedNOTE: Some routers will stop forwarding IP traffic while they renew theirWAN side IPv4/IPv6 address. This can cause this test to fail.NOTE: Some routers allow static configuration of the MTU size. This maydefault to 1492 even for routers running DHCP on the WAN side.NOTE: This test will stop if the number of max failures is reached. Thisvalue may be configured using testvar forwardingMaxFailures. Setting thisvalue to 0 will test each packet size regardless of the result.testvar forwardingMaxFailures 20

step 1. Initiate an outbound UDP connection with UDP data length of 4step 2. Verify packet is received on the WAN interfacestep 3. Forward a return packet from the WAN to the LANstep 4. Verify packets are received on the LAN interfacestep 5. Continue forwarding until the maximum unfragmented packet length is reachedNOTE: Some routers will stop forwarding IP traffic while they renew theirWAN side IPv6/IPv6 address. This can cause this test to fail.NOTE: Some routers allow static configuration of the MTU size. This maydefault to 1492 even for routers running DHCP on the WAN side.NOTE: This test will stop if the number of max failures is reached. Thisvalue may be configured using testvar forwardingMaxFailures. Setting thisvalue to 0 will test each packet size regardless of the result.testvar forwardingMaxFailures 20

step 1. Forward an IPv6 packet from a LAN client to the WAN that utilizesthe maximum supported jumbo mtu of both interfacesstep 2. Verify the Hop Limit of the packet is decremented by 1Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) SpecificationSection 3. IPv6 Header FormatNOTE: Decremented by 1 by each node that forwards the packet.NOTE: The maximum jumbo packet size is configured using the testvarjumboMtu.

step 1. Set the IPv6 Hop Limit of outbound packets to 1step 2. Forward an IPv6 packet from a LAN client to the WAN that utilizesthe maximum supported jumbo mtu of both interfacesstep 3. Verify the packet is not forwardedstep 4. Repeat the test with a Hop Limit of 0Reference: RFC 2640 Internet Protocol, Version 6 (IPv6) SpecificationSection 3. IPv6 Header FormatNOTE: The packet is discarded if Hop Limit is decremented to zero.NOTE: The maximum jumbo packet size is configured using the testvarjumboMtu.

step 1. Forward an IP packet from a LAN client to another LAN client thatutilizes the maximum supported jumbo mtu of both interfacesstep 2. Forward packet using router's MAC addressstep 3. Verify packet is forwarded back out the LAN interfaceNOTE: The router may send an ICMP Redirect back to the originator.NOTE: The maximum jumbo packet size is configured using the testvarjumboMtu.

step 1. Initiate an outbound UDP connection with UDP packet thatutilizes the maximum supported standard mtu of both interfacesstep 2. Verify packets are received on the WAN interfacestep 3. Continue forwarding until the maximum unfragmented packet length isreached, i.e. maximum supported jumbo mtu of both interfacesNOTE: Some routers will stop forwarding IP traffic while they renew theirWAN side IPv4/IPv6 address. This can cause this test to fail.NOTE: The maximum jumbo packet size is configured using the testvarjumboMtu.NOTE: This test will stop if the number of max failures is reached. Thisvalue may be configured using testvar forwardingMaxFailures. Setting thisvalue to 0 will test each packet size regardless of the result.testvar forwardingMaxFailures 20

step 1. Determine the size of the client DHCPv6 address poolstep 2. Create a new client for each available address within the poolstep 3. Verify the client obtains an IPv6 address via autoconfiguration or DHCPv6step 4. Verify there are no address conflictsstep 5. Verify each client can establish an outbound HTTP connectionstep 6. Verify each client can send/receive data over the connectionstep 7. Close each TCP connectionNOTE: The DHCPv6 address pool size is set in your configuration file usingthe 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addressesremains in use through the test run for a host on the LAN side. This testwill attempt to create clients for the pool size - 1. If you are usingmultiple LAN interfaces, the number of DHCPv6 clients from each interfacewill also be subtracted from the DHCPv6 pool size.

step 1. Determine the size of the client DHCPv6 address poolstep 2. Determine the maximum number of TCP connections to create foreach clientstep 3. Create a new client for each available address within the poolstep 4. Verify the client obtains an IPv6 address via autoconf or DHCPv6step 5. Verify there are no address conflictsstep 6. Verify each client can establish X outbound HTTP connections toport 80, where X is the number of TCP connections per DHCPv6 clientto create. Each connection is to a unique IP address.step 7. Verify each client can send/receive data over each connectionstep 8. Close each TCP connectionNOTE: The DHCPv6 address pool size is set in your configuration file usingthe 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addressesremains in use through the test run for a host on the LAN side. This testwill attempt to create clients for the pool size - 1. If you are usingmultiple LAN interfaces, the number of DHCPv6 clients from each interfacewill also be subtracted from the DHCPv6 pool size.NOTE: The maximum number of TCP connections per host is set in yourconfiguration file using the testvar 'scaleTcpConnsPerHost'. If this entryis not included in your configuration file, it defaults to 5.

step 1. Determine the size of the client DHCPv6 address poolstep 2. Determine the maximum number of TCP connections to create foreach clientstep 3. Create a new client for each available address within the poolstep 4. Verify the client obtains an IPv6 address via autoconf or DHCPv6step 5. Verify there are no address conflictsstep 6. Verify each client can establish 1 outbound UDP connectionstep 7. Verify each client can send/receive data over each connectionNOTE: The DHCPv6 address pool size is set in your configuration file usingthe 'ipv6DhcpClientStart' and 'ipv6DhcpClientEnd' testvars. One of the addressesremains in use through the test run for a host on the LAN side. This testwill attempt to create clients for the pool size - 1. If you are usingmultiple LAN interfaces, the number of DHCPv6 clients from each interfacewill also be subtracted from the DHCPv6 pool size.

step 1. Initiate an outbound TCP connection to HTTP serverstep 2. Verify the connection is establishedstep 3. Send HTTP GET request to serverstep 4. Verify HTTP response is receivedstep 5. Verify the IPv4 source address on the WAN side is original LAN addressstep 6. Close TCP connection from LAN sideReference: RFC 6333 Section 4.2 "CPE"A DS-Lite CPE SHOULD NOT operate a NAT function between an internalinterface and a B4 interface, as the NAT function will be performedby the AFTR in the service provider's network.  This will avoidaccidentally operating in a double-NAT environment.

step 1. Send a DHCPREQUEST for the current IP addressstep 2. Verify DHCP server sends DHCPACKstep 3. Verify the gateway address is the router's LAN IPv4 addressReference: RFC 6333 Section 4.2 "CPE"A DS-Lite CPE SHOULD NOT operate a NAT function between an internalinterface and a B4 interface, as the NAT function will be performedby the AFTR in the service provider's network.  This will avoidaccidentally 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 homehosts.  It SHOULD also advertise itself as a DNS server in the DHCPOption 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxyto accept DNS IPv4 requests from home hosts and send them using IPv6to the service provider DNS servers, as described in Section 5.5.

step 1. Send a DHCPREQUEST for the current IP addressstep 2. Verify DHCP server sends DHCPACKstep 3. Verify the DNS server address is the router's LAN IPv4 addressReference: RFC 6333 Section 4.2 "CPE"A DS-Lite CPE SHOULD NOT operate a NAT function between an internalinterface and a B4 interface, as the NAT function will be performedby the AFTR in the service provider's network.  This will avoidaccidentally 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 homehosts.  It SHOULD also advertise itself as a DNS server in the DHCPOption 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxyto accept DNS IPv4 requests from home hosts and send them using IPv6to the service provider DNS servers, as described in Section 5.5.

step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496step 2. Verify the packet is received on the WANstep 3. Verify the packet results in IPv6 fragments and no IPv4 fragmentsReference: RFC 6333 Section 5.3 "Fragmentation and Reassembly"Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4traffic over IPv6 will reduce the effective MTU of the datagram.Unfortunately, path MTU discovery [RFC1191] is not a reliable methodto deal with this problem.A solution to deal with this problem is for the service provider toincrease the MTU size of all the links between the B4 element and theAFTR elements by at least 40 bytes to accommodate both the IPv6encapsulation header and the IPv4 datagram without fragmenting theIPv6 packet.However, as not all service providers will be able to increase theirlink MTU, the B4 element MUST perform fragmentation and reassembly ifthe outgoing link MTU cannot accommodate the extra IPv6 header.  Theoriginal IPv4 packet is not oversized.  The packet is oversized afterthe IPv6 encapsulation.  The inner IPv4 packet MUST NOT befragmented.  Fragmentation MUST happen after the encapsulation of theIPv6 packet.  Reassembly MUST happen before the decapsulation of theIPv4 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 encapsulatesthe original packet, and subsequently fragments theresulting IPv6 tunnel packet into IPv6 fragments that donot exceed the Path MTU to the tunnel exit-point.

step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496step 2. Verify an ICMP unreachable with code 4 is received on the LANstep 3. Forward an additional IPv4 packet from a LAN client to the WAN with same sizestep 4. Verify packet is not forwarded to the WANReference: RFC 6333 Section 5.3 "Fragmentation and Reassembly"Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4traffic over IPv6 will reduce the effective MTU of the datagram.Unfortunately, path MTU discovery [RFC1191] is not a reliable methodto deal with this problem.A solution to deal with this problem is for the service provider toincrease the MTU size of all the links between the B4 element and theAFTR elements by at least 40 bytes to accommodate both the IPv6encapsulation header and the IPv4 datagram without fragmenting theIPv6 packet.However, as not all service providers will be able to increase theirlink MTU, the B4 element MUST perform fragmentation and reassembly ifthe outgoing link MTU cannot accommodate the extra IPv6 header.  Theoriginal IPv4 packet is not oversized.  The packet is oversized afterthe IPv6 encapsulation.  The inner IPv4 packet MUST NOT befragmented.  Fragmentation MUST happen after the encapsulation of theIPv6 packet.  Reassembly MUST happen before the decapsulation of theIPv4 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 thepacket and returns an ICMP message.  The ICMP message hasthe type = "unreachable", the code = "packet too big", andthe recommended MTU size field set to the size of thetunnel MTU - see sections 6.7 and 8.3.

step 1. Forward an IPv4 packet from a LAN client to the WAN with packet size 1496step 2. Verify packet is not forwarded to the WANReference: RFC 6333 Section 5.3 "Fragmentation and Reassembly"Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4traffic over IPv6 will reduce the effective MTU of the datagram.Unfortunately, path MTU discovery [RFC1191] is not a reliable methodto deal with this problem.A solution to deal with this problem is for the service provider toincrease the MTU size of all the links between the B4 element and theAFTR elements by at least 40 bytes to accommodate both the IPv6encapsulation header and the IPv4 datagram without fragmenting theIPv6 packet.However, as not all service providers will be able to increase theirlink MTU, the B4 element MUST perform fragmentation and reassembly ifthe outgoing link MTU cannot accommodate the extra IPv6 header.  Theoriginal IPv4 packet is not oversized.  The packet is oversized afterthe IPv6 encapsulation.  The inner IPv4 packet MUST NOT befragmented.  Fragmentation MUST happen after the encapsulation of theIPv6 packet.  Reassembly MUST happen before the decapsulation of theIPv4 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 thepacket and returns an ICMP message.  The ICMP message hasthe type = "unreachable", the code = "packet too big", andthe recommended MTU size field set to the size of thetunnel MTU - see sections 6.7 and 8.3.

step 1. Initiate a DNS query to the router's LAN ip addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Verify the DNS query is using IPv6 and not IPv4step 5. Send a return response back to LANstep 6. Verify the response is received by the LAN clientNOTE: The router must support some type of DNS relay or proxy topass 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 serverthrough DHCPv6 (or other similar method over IPv6).  As DHCPv6 onlydefines an option to get the IPv6 address of such a DNS recursiveserver, the B4 element cannot easily discover the IPv4 address ofsuch a recursive DNS server, and as such will have to perform all DNSresolution over IPv6.

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 receivedReference: RFC 6333 Section 6.5 "Well-Known IPv4 Address"The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved byIANA to configure the IPv4-in-IPv6 tunnel.  That address can then beused to report ICMP problems and will appear in traceroute outputs.

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 receivedReference: 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 addressis often necessary when the B4 element is sourcing IPv4 datagramsdirectly over the tunnel.  In order to avoid conflicts with any otheraddress, 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 forthe AFTR element, and 192.0.0.2 is reserved for the B4 element.  If aservice provider has a special configuration that prevents the B4element from using 192.0.0.2, the B4 element MAY use any otheraddresses within the 192.0.0.0/29 range.Note: A range of addresses has been reserved for this purpose.  Theintent is to accommodate nodes implementing multiple B4 elements.

step 1. Initiate a DNS lookup for a new unique hostname from LAN clientstep 2. Return DNS response with TTL set to 0 from WAN DNS serverstep 3. Change the IP address on the DNS server for the new hostnamestep 4. Initiate a new DNS lookup for the same hostnamestep 5. Verify a new DNS request is sent to the primary or backupDNS serversReference: RFC 1035Section 3.2.1 FormatNOTE: Zero values are interpreted to mean that the RR can only beused for the transaction in progress, and should not be cached.

step 1. Initiate a DNS lookup for a new unique hostname from LAN clientstep 2. Return DNS response with TTL set to 0 from WAN DNS serverstep 3. Verify the returned TTL from the DNS proxy is 0Reference: RFC 1035Section 3.2.1 FormatNOTE: Zero values are interpreted to mean that the RR can only beused for the transaction in progress, and should not be cached.

step 1. Initiate an AAAA IPv6 DNS query to the router's LAN ip addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send a return response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case. The DNS relay or proxy must understand IPv6 DNStype AAAA lookups.Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses

step 1. Initiate an AAAA IPv6 DNS query to the router's LAN ip addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send an empty return response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case. The DNS relay or proxy must understand IPv6DNS type AAAA lookups.Reference: RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses

step 1. Verify DNS error codes from 1 - 15step 2. For each error code, configure the primary DNS server toreturn the error code, and the backup to return the normalresponsestep 3. All responses will have the authoritative bit setstep 4. Send 3 DNS queries for a new hostname to router's lanIpstep 5. Verify a valid DNS response is received if the errorcode is expected to trigger DNS failoverstep 6. Configure the primary DNS server back to normal operationand configure the backup to return the DNS errorstep 7. Send 3 DNS queries for a new hostname to router's lanIpstep 8. Verify a valid DNS response is received if the errorcode is expected to trigger DNS failoverNOTE: This test sets up the failover to happen from primary tobackup in the first part and then backup to primary. This isrequired for implmentations that maybe load balancing DNS acrossthe DNS servers or may have already failed all future requests tothe primary or backup.NOTE: Most DNS clients that support multiple DNS servers (primaryand backup) use some type of failover for certain DNS error codes.The behavior for each error code is implementation dependent. Thelist of error codes that will cause DNS failover can be configuredusing the testvar 'dnsFailoverErrorCodes'. If no DNS error codes willcause failover, the testvar should be configured with the keyword 'none'.Example:testvar dnsFailoverNonAuth "2 4 5"Example with no failover support:testvar dnsFailoverNonAuth noneNOTE: Unix OSes based on bind will normally failover if DNS errorcodes 2, 4, or 5 are received. Windows based OSes will normally failoveron all DNS error codes except 3 (No Such Name).

step 1. Verify DNS error codes from 1 - 15step 2. For each error code, configure the primary DNS server toreturn the error code, and the backup to return the normalresponsestep 3. All responses will have the authoritative bit setstep 4. Send 3 DNS queries for a new hostname to router's lanIpstep 5. Verify a valid DNS response is received if the errorcode is expected to trigger DNS failoverstep 6. Confgiure the primary DNS server back to normal operationand configure the backup to return the DNS errorstep 7. Send 3 DNS queries for a new hostname to router's lanIpstep 8. Verify a valid DNS response is received if the errorcode is expected to trigger DNS failoverNOTE: This test sets up the failover to happen from primary tobackup in the first part and then backup to primary. This is requiredfor implmentations that maybe load balancing DNS across the DNS serversor may have already failed all future requests to the primary or backup.NOTE: Most DNS clients that support multiple DNS servers (primaryand backup) use some type of failover for certain DNS error codes.The behavior for each error code is implementation dependent. The listof error codes that will cause DNS failover can be configured using thetestvar 'dnsFailoverAuth'. If no DNS error codes will cause failover, thetestvar should be configured with the keyword 'none'.Example:testvar dnsFailoverAuth "2 4 5"Example with no failover support:testvar dnsFailoverAuth noneNOTE: Unix OSes based on bind will normally failover if DNS errorcodes 2, 4, or 5 are received. Windows based OSes will normally failoveron all DNS error codes except 3 (No Such Name).

step 1. Initiate a reverse DNS query to the router's LAN ip addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send a return response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case.

step 1. Initiate a reverse DNS query to the router's LAN ip addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send a return response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case.

step 1. Create a new primary and backup DNS serverstep 2. Terminate the WAN link and bring back upstep 3. Issue DNS query from LAN clientstep 4. Verify LAN client receives response from new DNS serversstep 5. Terminate the WAN link and bring back up with original DNS serversNOTE: This test is only run when the WAN mode is dynamic.NOTE: The amount of time to wait before checking that DNS has been updatedafter the WAN link is restored can be configured using the testvar'dnsFailoverDelay'. The default is 10 seconds.

step 1. Initiate a DNS lookup for a new unique hostname from LAN clientstep 2. Return DNS response with multiple IPv4 answers from WAN DNS serverstep 3. Verify LAN client learns all IPv4 answers from DNS lookupReference: RFC 1035

step 1. Verify initial DNS lookup is workingstep 2. Disable all DNS serversstep 3. Initiate 3 DNS lookups for new domains which should failstep 4. Enable all DNS serversstep 5. Verify DNS looks start working againNOTE: Zero values are interpreted to mean that the RR can only beused for the transaction in progress, and should not be cached.

step 1. Initiate a DNS lookup for a new unique hostname from LAN clientstep 2. Return DNS response with TTL set to 0 from WAN DNS serverstep 3. Change the IP address on the DNS server for the new hostnamestep 4. Initiate a new DNS lookup for the same hostnamestep 5. Verify a new DNS request is sent to the primary or backupDNS serversReference: RFC 1035Section 3.2.1 FormatNOTE: Zero values are interpreted to mean that the RR can only beused for the transaction in progress, and should not be cached.

step 1. Configure a DNS entry with 200 IPv4 matching records thatrequires a UDP response slightly less than 4096step 2. Initiate a DNS lookup for a new unique hostname from LAN clientusing EDNS0 option announcing a UDP buffer size of 4096step 3. Return DNS response with multiple IPv4 answers from WAN DNS serverstep 4. Verify LAN client learns all IPv4 answers from DNS lookupReference: RFC 2671 Extension Mechanisms for DNS (EDNS0)

step 1. Initiate a DNS lookup for a unique hostname from LAN clientusing EDNS0 option announcing a UDP buffer size of 4096step 2. Verify DNS response contains EDNS0 optionstep 3. Configure a DNS entry with enough matching IPv4 records thatrequires 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 clientusing EDNS0 option announcing a UDP buffer size of 4096step 5. Return DNS response with multiple IPv4 answers from WAN DNS serverstep 6. Verify LAN client learns all IPv4 answers from DNS lookupReference: RFC 2671 Extension Mechanisms for DNS (EDNS0)

step 1. Initiate a DNS TXT query to the router's LAN IPv4 addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send a return TXT response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case.Reference: RFC 1035 Domain names - implementation and specification

step 1. Initiate a DNS SPF query to the router's LAN IPv4 addressstep 2. Verify the query is received by real DNS server on the WAN sidestep 3. The query may be received by the primary or backup DNS serverstep 4. Send a return SPF response back to LANstep 5. Verify the response is received by LAN clientNOTE: The router must support some type of DNS relay or proxy topass this test case.Reference: RFC 4408Sender Policy Framework (SPF) forAuthorizing Use of Domains in E-Mail, Version 1

step 1. Send an IPv6 DNS server status request from LAN clientstep 2. Verify the DNS proxy does not forward the request to thereal DNS serverNOTE: Scanning tools including nmap utilize DNS server statusrequests when probing a host.Reference: draft-hall-status-opcode-00-1Section 6 Security Considerations

step 1. Initiate a DNSKEY query to the router's LAN IPv6 addressstep 2. The query may be received by the primary or backup DNS serverstep 3. Send a DNSKEY response back to LANstep 4. Verify the response is received by LAN client and all fields are correctstep 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queriesNOTE: The router must support some type of DNS relay or proxy topass this test case.Reference: RFC 4034Resource Records for the DNS Security Extensions

step 1. Initiate a DNSKEY query to the router's LAN IPv6 addressstep 2. The query may be received by the primary or backup DNS serverstep 3. Send a large RRSIG response (greater than 1220 bytes) back to LANstep 4. Verify full response is received by LAN client and all fields are correctNOTE: The router must support some type of DNS relay or proxy topass this test case.Reference: RFC 4035Section 4.1 EDNS Support

step 1. Perform a DNS lookup on a hostname from the LAN via IPv6step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS serverstep 3. Change the address on the WAN DNS server for the new hostnamestep 4. Wait half the TTL value of the responsestep 5. Perform a DNS lookup on the same hostname from the LANstep 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns cached response from step 2 and does not forward the queryto the WAN DNS server.  If supportsDnsCaching is no, verify DUT'sDNS proxy forwards the query to the WAN DNS server.step 7. Wait long enough for the TTL value of the response from step 2to have elapsedstep 8. Perform a DNS lookup on the same hostname from the LANstep 9. Verify DUT's DNS proxy forwards the query to the WAN DNS serverReference: RFC 1035 Domain Names - Implementation and SpecificationSection 4.1.3 Resource Record format

step 1. Set up new web server on WAN side using IPv6 free network addressstep 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. Verify TCP connection is openedstep 5. Send HTTP GET from LAN client to new server for requested URLstep 6. URL is considered blocked if one of the following occurs:a. The LAN client does not receive a page from the webserverb. 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 URLstep 8. Verify that each configured non-filtered URL returns a valid webpageNOTE: 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 establishmentof the TCP connection in step 4, using a proxy to return a non-200 HTTPstatus code in step 6, or using a proxy to return a 200 HTTP status codein step 6 with alternate webpage text indicating that the page wasadmninistratively blocked. The testvar 'urlFilterBlockedText' should beconfigured with a portion of the expected text returned when a page isblocked by the CPE.

step 1. Set up new web server on WAN side using IPv6 free network addressstep 2. Resolve only domain IPv6 addresses for non-filtered URLs using AAAAlookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. Verify TCP connection is openedstep 5. Send HTTP GET from LAN client to new server for requested URLstep 6. URL is considered blocked if one of the following occurs:a. The LAN client does not receive a page from the webserverb. 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 URLstep 8. Verify that each configured non-filtered URL returns a valid webpageNOTE: 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 establishmentof the TCP connection in step 4, using a proxy to return a non-200 HTTPstatus code in step 6, or using a proxy to return a 200 HTTP status codein step 6 with alternate webpage text indicating that the page wasadmninistratively blocked. The testvar 'urlFilterBlockedText' should beconfigured with a portion of the expected text returned when a page isblocked by the CPE.

step 1. Set up new web server on WAN side using IPv6 free network addressstep 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. Verify TCP connection is openedstep 5. Send HTTP HEAD from LAN client to new server for requested URLstep 6. URL is considered blocked if one of the following occurs:a. The LAN client does not receive a page from the webserverb. 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 URLstep 8. Verify that each configured non-filtered URL returns a valid webpageNOTE: 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 establishmentof the TCP connection in step 4, using a proxy to return a non-200 HTTPstatus code in step 6, or using a proxy to return a 200 HTTP status codein step 6 with alternate webpage text indicating that the page wasadmninistratively blocked. The testvar 'urlFilterBlockedText' should beconfigured with a portion of the expected text returned when a page isblocked by the CPE.

step 1. Set up new web server on WAN side using IPv6 free network addressstep 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. Verify TCP connection is openedstep 5. Send HTTP POST from LAN client to new server for requested URLstep 6. URL is considered blocked if one of the following occurs:a. The LAN client does not receive a page from the webserverb. 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 URLstep 8. Verify that each configured non-filtered URL returns a valid webpageNOTE: 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 establishmentof the TCP connection in step 4, using a proxy to return a non-200 HTTPstatus code in step 6, or using a proxy to return a 200 HTTP status codein step 6 with alternate webpage text indicating that the page wasadmninistratively blocked. The testvar 'urlFilterBlockedText' should beconfigured with a portion of the expected text returned when a page isblocked by the CPE.

step 1. Set up new web server on WAN side using IPv6 free network addressstep 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. Verify TCP connection is openedstep 5. Send HTTP GET from LAN client to new server for requested URLstep 6. Use one of the filtered URLs as the cookie datastep 7. Verify webserver does return a responsestep 8. Repeat for each configured allowed URLNOTE: 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.

step 1. Set up new HTTPS server on WAN side using IPv6 free network addressstep 2. Resolve domain IPv6 address using DNS AAAA lookup from LAN clientstep 3. Initiate IPv6 TCP connection to web server from LAN clientstep 4. If TCP connection is not established, skip to step 9step 5. Verify TCP connection is openedstep 6.  Establish SSL connection to serverstep 7.  Send HTTPS GET from LAN client to new server for requested URLstep 8.  URL is considered blocked if one of the following occurs:a. The LAN client does not receive a page from the webserverb. 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 URLstep 10. Verify that each configured non-filtered URL returns a valid webpageNOTE: 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 establishmentof the TCP connection in step 4, using a proxy to return a non-200 HTTPstatus code in step 8, or using a proxy to return a 200 HTTP status codein step 8 with alternate webpage text indicating that the page wasadmninistratively blocked. The testvar 'urlFilterBlockedText' should beconfigured with a portion of the expected text returned when a page isblocked by the CPE.

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv1/2 Membership Report packet on the LAN interfacestep 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interfacestep 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the groupwith an empty source list.step 5. Repeat test using an MLDv1 Leave packet or MLDv2 Memebership Reportto leave the multicast groupstep 6. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the groupwith an empty source list.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: Some routers may send an MLD query on the LAN interface after theMLD Leave from the LAN client. The MLD Leave may not be sent on theWAN interface until the LAN side has made multiple queries.The amount of time this test case should wait before expecting theMLD Leave on the WAN interface may be configured by setting thetestvar 'ipv6MulticastCacheTimeout'.Example:testvar ipv6MulticastCacheTimeout 30

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Send a UDP packet to the multicast group from the WANstep 4. Verify the multicast packet is received on the LANstep 5. Verify the TTL is decremented by the expected IP hop countNOTE: This test will work with either a multicast pass through implementationor 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 IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: The testvar ipv6MulticastJoinDelay can be used to control how longthe test waits to verify the multicast traffic after receiving theMLD report. The default value is 2 seconds.testvar ipv6MulticastJoinDelay 2

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the WAN interfacestep 3. Forward a multicast UDP packet from the LAN with UDP length 4step 4. Verify the packet is received on the LAN interfacestep 5. Repeat for all packet sizes up to the max MTUNOTE: This test will work with either a multicast pass through implementationor a multicast proxy implementation.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: The testvar ipv6MulticastJoinDelay can be used to control how longthe test waits to verify the multicast traffic after receiving theMLD report. The default value is 2 seconds.testvar ipv6MulticastJoinDelay 2NOTE: If the device does not support forwarding multiast trafficto the WAN, this test case may be skipped by settingthe testvar supportsIPv6MulticastOut to no.For example,testvar supportsIPv6MulticastOut no

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Forward a multicast UDP packet from the WAN with UDP length 4step 4. Verify the packet is received on the LAN interfacestep 5. Repeat for all packet sizes up to the max MTUNOTE: This test will work with either a multicast pass through implementationor a multicast proxy implementation.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: The testvar ipv6MulticastJoinDelay can be used to control how longthe test waits to verify the multicast traffic after receiving theMLD report. The default value is 2 seconds.testvar ipv6MulticastJoinDelay 2

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Wait up to mldQueryInterval seconds for a general MLD Query on the LANstep 3. Repeat for 2 queriesNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Allocate a multicast group that has no members on the LANstep 3. Forward UDP multicast packet from WAN to LAN using groupstep 4. Verify the packet is not received on the LANNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Send a UDP packet to the multicast group from the WANstep 4. Verify the multicast packet is received on the LANstep 5. Send a MLD Leave packet on the LAN interface for groupstep 6. Wait for the multicast cache to expirestep 7. Forward UDP multicast packet from WAN to LAN using groupstep 8. Verify the packet is not received on the LANNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Send a UDP packet to the multicast group from the WANstep 4. Verify the multicast packet is received on the LANstep 5. Wait for the multicast group to expirestep 6. Forward UDP multicast packet from WAN to LAN using groupstep 7. Verify the packet is not received on the LANNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: The amount of time it takes the multicast group to expire isbased on the mldQueryInterval, mldRobustnessVariable, andmldQueryResponseInterval. These can all be configured using thefollowing testvars:testvar mldQueryInterval 125testvar mldRobustnessVariable 2testvar mldQueryResponseInterval 10

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Wait up to 10 seconds for MLD membership report on the WANstep 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 forthe multicast groupNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Wait up to 10 seconds for MLD membership report on the WANstep 4. Issue an MLD Membership query to ff02::1 on WAN for specific group addressstep 5. Verify router's WAN side responds with MLD membership report forthe multicast groupNOTE: This test will work with a multicast proxy implementation only.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv1/2 Membership Report packet on the LAN interfacestep 3. Send an MLDv2 Leave or MLDv2 Memebership packet on the LAN interfaceto leave the multicast groupstep 4. Verify an MLDv1/2 Query packet is sent on the LAN interfaceto the specific multicast group. If mldFastLeave is setto 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 IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: If the device supports MLD Fast Leave, the testvar mldFastLeaveshould be set to yes. In this case, the test case will verify thatno group specific MLD query is sent after the MLD Leave.

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv1/2 Membership Report packet on the LAN interfacestep 3. Verify an MLDv1/2 Membership Report packet is received on the WAN interfacestep 4. For MLDv2, verify group record is CHANGE_TO_EXCLUDE_MODE for the groupwith an empty source list.step 5. Let group member on the LAN age out. No responses will sent to MLDqueries and no MLD Leave will be sent.step 6. Verify MLD leave or MLDv2 membership report is received for the groupon the WAN interfacestep 7. For MLDv2, verify group record is CHANGE_TO_INCLUDE_MODE for the groupwith an empty source list.NOTE: This test will work with either a multicast pass through implementationor a multicast proxy implementation.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: The amount of time it takes the multicast group to expire isbased on the mldQueryInterval, mldRobustnessVariable, andmldQueryResponseInterval. These can all be configured using thefollowing testvars:testvar mldQueryInterval 125testvar mldRobustnessVariable 2testvar mldQueryResponseInterval 10

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Join mldMaxGroups multicast groups on the LAN interfacestep 3. Forward a multicast UDP packet from the WAN to each groupstep 4. Verify each group is received on the LAN interfacestep 5. Send a MLD Leave for each multicast groupNOTE: This test will work with either a multicast pass through implementationor a multicast proxy implementation.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6NOTE: You can slow down the rate at which CDRouter will join each groupby configuring the testvar ipv6MulticastScaleDelay. It defaults to 1millisecond.testvar ipv6MulticastScaleDelay 1

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Check the testvar ipv6IptvChannelRange to determine the number of channelsstep 3. For each channel, join the multicast group on the LANstep 4. Verify the MLDv1 or MLDv2 report is received in the WANstep 5. Start sending multicast data on the WAN for the new groupstep 6. Verify the LAN side starts to receive the multicast datastep 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelaystep 8. Leave the multicast group on the LAN using MLDv1/2step 9. Switch to the next channel or exit if too many failures have occuredNOTE: There are a few test variables that can control the number of channelsand speed of this test.The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to waitbetween each channel change.The testvar ipv6IptvChannelRange specifies the total number of channel changes toattempt.The testvar ipv6IptvMaxFailures is used to stop the test after a specific numberof failures. When testing a large number of channels, it can be usefulto stop the test earily is many channels start failing.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv1/2 Query on the WAN to allow device to detect MLD versionstep 2. Check the testvar ipv6IptvChannelRange to determine the number of channelsstep 3. For each channel, join the multicast group on the LANstep 4. Verify the MLDv1 or MLDv2 report is received in the WANstep 5. Leave any previous multicast group for the last channelstep 6. Start sending multicast data on the WAN for the new groupstep 7. Verify the LAN side starts to receive the multicast datastep 8. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelaystep 9. Switch to the next channel or exit if too many failures have occuredNOTE: There are a few test variables that can control the number of channelsand speed of this test.The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to waitbetween each channel change.The testvar ipv6IptvChannelRange specifies the total number of channel changes toattempt.The testvar ipv6IptvMaxFailures is used to stop the test after a specific numberof failures. When testing a large number of channels, it can be usefulto stop the test earily is many channels start failing.Reference: RFC 2710 Multicast Listener Discovery for IPv6Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv2 Membership Report packet on the LAN interfacewith ALLOW_NEW_SOURCES record containing specific sourcestep 3. Verify an MLDv2 Membership Report packet is received on the WAN interfacestep 4. Verify group record is ALLOW_NEW_SOURCES for the groupwith a matching source list.step 5. Verify multicast forwarding from WAN to LAN for new group usingthe specific source address.step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast groupstep 7. Verify group record is BLOCK_OLD_SOURCES for the groupwith a matching source list.Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv2 Membership Report packet on the LAN interfacewith ALLOW_NEW_SOURCES record containing specific sourcestep 3. Verify an MLDv2 Membership Report packet is received on the WAN interfacestep 4. Verify group record is ALLOW_NEW_SOURCES for the groupwith a matching source list.step 5. Verify multicast forwarding fails from WAN to LAN for new group usingthe different source address.step 6. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast groupstep 7. Verify group record is BLOCK_OLD_SOURCES for the groupwith a matching source list.Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Send an MLDv2 Membership Report packet on the LAN interfacewith ALLOW_NEW_SOURCES record containing specific sourcestep 3. Verify an MLDv2 Membership Report packet is received on the WAN interfacestep 4. Verify group record is ALLOW_NEW_SOURCES for the groupwith a matching source list.step 5. Verify multicast forwarding from WAN to LAN for new group usingthe specific source address.step 6. Verify multicast forwarding fails from WAN to LAN for a different groupusing the same specific source address.step 7. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast groupstep 8. Verify group record is BLOCK_OLD_SOURCES for the groupwith a matching source list.Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Create a new server on the WAN for a multicast sourcestep 3. Send an MLDv2 Membership Report packet on the LAN interfacewith ALLOW_NEW_SOURCES record containing multiple specific sourcestep 4. Verify an MLDv2 Membership Report packet is received on the WAN interfacestep 5. Verify group record is ALLOW_NEW_SOURCES for the groupwith a matching source list.step 6. Verify multicast forwarding from WAN to LAN for new group usingthe specific source address from source address 1.step 7. Verify multicast forwarding from WAN to LAN for new group usingthe specific source address from source address 2.step 8. Continue test using an MLDv2 BLOCK_OLD_SOURCES to leave the multicast groupstep 9. Verify group record is BLOCK_OLD_SOURCES for the groupwith a matching source list.Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Wait up to 10 seconds for MLD membership report on the WANstep 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 forthe multicast groupReference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Join a multicast group on the LAN interfacestep 3. Wait up to 10 seconds for MLD membership report on the WANstep 4. Issue an MLD Membership query on WAN for specific group addressstep 5. Verify router's WAN side responds with MLD membership report forthe multicast groupReference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 1. Join a multicast group on the LAN interfacestep 2. Wait up to 10 seconds for MLD membership report on the WANstep 3. Issue an MLD Membership query on WAN for specific group addressstep 4. Verify router's WAN side responds with MLD membership report forthe multicast groupReference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Join mldMaxGroups multicast groups on the LAN interface usingmultiple group records in a single MLDv2 membership reportstep 3. Forward a multicast UDP packet from the WAN to each groupstep 4. Verify each group is received on the LAN interfacestep 5. Send a MLD Leave for each multicast groupReference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Send an MLDv2 Query on the WAN to allow device to detect MLD versionstep 2. Check the testvar ipv6IptvChannelRange to determine the number of channelsstep 3. For each channel, join the multicast group on the LANstep 4. Verify the MLDv2 report is received in the WANstep 5. Start sending multicast data on the WAN for the new groupstep 6. Verify the LAN side starts to receive the multicast datastep 7. Wait for a small delay determined by testvar ipv6IptvChannelChangeDelaystep 8. Send new MLDv2 report to leave current channel and join next channelor exit if too many failures have occuredNOTE: There are a few test variables that can control the number of channelsand speed of this test.The testvar ipv6IptvChannelChangeDelay specifies a delay in milliseconds to waitbetween each channel change.The testvar ipv6IptvChannelRange specifies the total number of channel changes toattempt.The testvar ipv6IptvMaxFailures is used to stop the test after a specific numberof failures. When testing a large number of channels, it can be usefulto stop the test earily is many channels start failing.Reference: RFC 3810 Multicast Listener Discovery Version 2 for IPv6

step 1. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 2. Verify at least one Router Advertisement contains a valid uniquelocal prefix that matches the expected unique local prefixconfigured using the testvar ipv6LanUlaPrefixstep 3. Verify that the unique local prefix discovered in Step 2 containsa valid lifetimeReferences: IETF RFC 4861 - Neighbor Discovery for IPv6Section 4.6.2 "Prefix Information"IETF RFC 4193 - Unique Local IPv6 Unicast AddressesNOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 2. Verify at least one Router Advertisement contains a valid uniquelocal prefix that matches the expected unique local prefixconfigured using the testvar ipv6LanUlaPrefixstep 3. Verify that the unique local prefix discovered in Step 2 containsa valid lifetimestep 4. Verify that the DUT includes a Route Information option for theunqiue local prefix discovered in Step 2References: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement L-3:An IPv6 CE router MUST advertise itself as a router for thedelegated prefix(es) (and ULA prefix if configured to provideULA addressing) using the "Route Information Option" specifiedin Section 2.3 of [RFC4191].  This advertisement isindependent of having or not having IPv6 connectivity on theWAN interface.NOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 2. Verify at least one Router Advertisement contains a valid uniquelocal prefix that matches the expected unique local prefixconfigured using the testvar ipv6LanUlaPrefixstep 3. Verify that the unique local prefix discovered in Step 2 containsa valid lifetimestep 4. Check the autonomous address-configuration flag (A bit) in theRouter Advertisement received in Step 1step 5. If the DUT is configured to provide global addresses via DHCPv6 onthe LAN, the A bit should not be set; if autoconfiguration is usedinstead, the A bit should be setstep 6. Verify that the prefix discovered in Step 2 has the on-link flag(L bit) setReferences: IETF RFC 4861 - Neighbor Discovery for IPv6Section 4.6.2 "Prefix Information"IETF RFC 4193 - Unique Local IPv6 Unicast AddressesNOTE: This test is designed to work with DUT's that support only a singleLAN mode for address autoconfiguration, either DHCPv6 or autoconfiguration.DUT configurations in which both modes are enabled simultaneously (wherethe 'A' and 'M' bits are both set) are not currently supported by this test.NOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Send a Neighbor Solicitation on the LAN for the DUT's IPv6 uniquelocal addressstep 2. Wait for a Neighbor Advertisement from the DUTstep 3. Verify fields of Neighbor AdvertisementReference: IETF RFC 4861 - Neighbor Discovery for IPv6

step 1. Send a Router Solicitation from the WANstep 2. Wait to see if DUT sends a Router Advertisement on the WANstep 3. Verify that Router Advertisement does not contain any unique localprefixesNOTE: The testvar ipv6ExpectRAonWan determines if this test shouldexpect to see Router Advertisements from the DUT on the WANReference: RFC 4861 - Neighbor Discovery for IPv6

step 1. Bring down WAN linkstep 2. Listen for IPv6 Router Advertisements on the LAN from DUTstep 3. Verify that the Router Advertisement contains a valid prefixinformation option for the expected unique local prefixstep 4. Bring up WAN linkReference: IETF RFC 6204 - IPv6 CE Router RequirementsSection 4.3: LAN-Side ConfigurationNOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Bring down WAN linkstep 2. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 3. Verify that the Router Advertisement contains a valid prefixinformation option for the expected unique local prefixstep 4. Verify that the Router Advertisement contains a valid routeinformation option for the expected unique local prefixstep 5. Bring up WAN linkReference: IETF RFC 6204 - IPv6 CE Router RequirementsSection 4.3: LAN-Side ConfigurationNOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Bring down WAN linkstep 2. Listen for Router Advertisements on the LAN for up to one RouterAdvertisement intervalstep 3. Verify that the Router Advertisement contains only prefixinformation options for unique local prefixesstep 4. Verify that the advertised Router Lifetime is not greater than 0step 5. Bring up WAN linkReference: IETF RFC 6204 - IPv6 CE Router Requirements, Requirement ULA-5:An IPv6 CE router MUST NOT advertise itself as a defaultrouter with a Router Lifetime greater than zero whenever allof its configured and delegated prefixes are ULA prefixes.NOTE: The testvar ipv6LanUlaPrefix must be configured to match theexpected unique local prefix advertised by the DUT.

step 1. Initiate an outbound ICMPv6 Echo Request to the DUT's IPv6 uniquelocal addressstep 2. Verify ICMPv6 Echo Reply is receivedstep 3. Verify the IPv6 source address is a unique local address

step 1. Initiaite an outbound ICMPv6 Ping to ff02::2 from the LAN client'sunique local addressstep 2. Verify ICMPv6 Echo Reply is received

step 1. Send an ICMPv6 Echo Request from the LAN client's unique localaddress to the All-Nodes Multicast group (ff02::1)step 2. Wait for an ICMPv6 Echo Responsestep 3. Verify the Echo Response is from the DUTstep 4. Continue waiting until the DUT responds, or timeout

step 1. Force the LAN client to transmit using its IPv6 unique local addressstep 2. Forward an IPv6 packet from the LAN client to the IPv6 remote hoston the WANstep 3. Verify the packet is not forwarded

step 1. Force the LAN client to transmit using its IPv6 global addressstep 2. Create a new IPv6 host on the WAN with only unique local addressstep 3. Forward an IPv6 packet from the LAN client to the new IPv6 host onthe WANstep 4. Verify the packet is not forwarded

step 1. Create a new IPv6 host on the WAN with only unique local addressstep 2. Forward an IPv6 packet from the new host on the WAN to the LANclient using the LAN client's global address as the destinationaddressstep 3. Verify the packet is not forwarded

step 1. Set the IPv6 remote host on the WAN to send using its global addressstep 2. Forward an IPv6 packet from the new host on the WAN to the LANclient using the LAN client's unique local address as the destinationaddressstep 3. Verify the packet is not forwarded

step 1. Find all configured IPv6 static routes with next hops on the LAN interfacestep 2. Create new gateways for each next hop on the LANstep 3. Send ICMPv6 Echo Request to a host within the static route from the LAN hoststep 4. Verify that the host in the static route reponds with ICMPv6 Echo ReplyNOTE: When configuring static routes on the CPE device, CDRouter expectsthat the next hop or gateway address is not contained within any LAN-sideDHCPv6 address pools. CDRouter will create a new host for each next hopaddress.

step 1. Find all configured IPv6 static routes with next hops on the LAN interfacestep 2. Create new gateways for each nexthop on the LANstep 3. Send ICMPv6 Echo Request from host in static route network to the WAN side remoteHoststep 4. Verify that the remoteHost on the WAN receives the ICMPv6 Echo Requeststep 5. Verify the WAN host ICMPv6 Echo Reply is received by the host in static route networkNOTE: When configuring static routes on the CPE device, CDRouter expectsthat the next hop or gateway address is not contained within any LAN-sideDHCPv6 address pools. CDRouter will create a new host for each next hopaddress.

step 1. Find all configured IPv6 static routes with next hops on the WAN interfacestep 2. Create new gateways for each next hop on the WAN if not the ipv6WanIspIpstep 3. Send ICMPv6 Echo Request to a host within the static route from the LAN hoststep 4. Verify that the host in the static route receives the ICMPv6 Echo Request

step 1. Find all configured IPv6 static routes with next hops on the WAN interfacestep 2. Create new gateways for each next hop on the WAN if not the wanIspIpstep 3. Send ICMPv6 Echo Request to a host within the static route from the LAN hoststep 4. Verify that the host in the static route reponds with ICMPv6 Echo ReplyNOTE: This test is intended to test static routes that are configured on the CPEdevice 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 willnot 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.

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 0 secondsPrefix Information Option:Type             = 3L-flag           = 0A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.1 RA Prefix Information Option L-FlagPart A: 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 RA2 on the WAN network.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 0 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.1 RA Prefix Information Option L-FlagPart B: 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 RA3 on the WAN network.RA3IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 0A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 EchoRequest to TR1.NOTE: This test may be omitted if the DUT does not implement anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.1 RA Prefix Information Option L-FlagPart C: 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 RA4 on the WAN network.RA4IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.1 RA Prefix Information Option L-FlagPart D: L-flag = 1 with Default Router

Purpose: Verify that the DUT supports the DHCPv6 Reconfigure Accept Option.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 1O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 serverreplies with Advertise and Reply messages respectively.DHCPv6 Solicit Message           DHCPv6 Request MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 1             Message Type     = 3Reconfigure Accept Option:       Reconfigure Accept Option:Option Code      = 20            Option Code      = 20Option Length    = 0             Option Length    = 0IA_PD Option:                    IA_PD Option:Option Code      = 25             Option Code     = 25IA_PD Prefix Option:Option Code      = 26Pref. Lifetime   = 600Valid Lifetime   = 600Prefix Length    = 60IPv6 Prefix      = PF1DHCPv6 Advertise Message         DHCPv6 Reply MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 2             Message Type     = 7Reconfigure Accept Option:       Reconfigure Accept Option:Option Code      = 20            Option Code      = 20Option Length    = 0             Option Length    = 0IA_PD Option:                    IA_PD Option:Option-Code      = 25             Option-Code     = 25IA_PD Prefix Option:             IA_PD Prefix Option:Option Code      = 26             Option Code     = 26Pref. Lifetime   = 600            Pref. Lifetime  = 600Valid Lifetime   = 600            Valid Lifetime  = 600Prefix Length    = 60             Prefix Length   = 60IPv6 Prefix      = PF1            IPv6 Prefix     = PF1step 4. The DUT must transmit an Echo Reply to TR1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.2 DHCPv6 Option: Reconfigure Accept Option

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 1O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 exchangeincluding an IA_NA option in the Request message.DHCPv6 Solicit Message           DHCPv6 Request MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 1             Message Type     = 3IA_NA Option:                    IA_NA Option:Option Code      = 3             Option Code      = 3IA Address Option:Option Code      = 5IPv6 Address     = PF2::100DHCPv6 Advertise Message         DHCPv6 Reply MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 2             Message Type     = 7IA_NA Option:                    IA_NA Option:Option Code      = 3             Option Code      = 3IA Address Option:               IA_NA Address Option:Option Code      = 5             Option Code      = 5IPv6 Address     = PF2::100      IPv6 Address     = PF2::100Pref. Lifetime   = 600Valid Lifetime   = 600step 5. The DUT must transmit an Echo Reply to TN3.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.3 RA M-Flag is Set

Purpose: Verify that the DUT supports the weak host model.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Enable DHCPv6-PD and wait 20 seconds to let the DUT perform theDHCPv6-PD process and assign addresses to TN1 on the LAN network.The DHCP server replies to all the DUT's messages with valid DHCPmessages.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 addressof the DUT LAN global address.NOTE: The subnet ID of the DUT's LAN global address in step 3 willbe computed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.4 Weak Host Model

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively.step 4. The DUT must respond to the Echo Request from TN3 with an EchoReply.NOTE: Because the intent of the test is to verify that prefix delegationoccurs, the Echo Request in step 3 will be sent to the DUT's global PF1address.NOTE: If the testvar cpeRebootMode is set to "skip", this test will notbe run.  If the testvar cpeRebootMode is set to "reboot", the CPE will berestarted at the end of the test, either using the testvar RestartDUT orby prompting the user.NOTE: The subnet ID of the DUT's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix DelegationPart A: 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 RA2 on the WAN network.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 1O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively.step 4. The DUT must respond to the Echo Request from TN3 with an EchoReply.NOTE: Because the intent of the test is to verify that prefix delegationoccurs, the Echo Request in step 3 will be sent to the DUT's global PF1address.NOTE: The subnet ID of the DUT's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix DelegationPart B: 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 RA3 on the WAN network.RA3IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively.step 4. The DUT must respond to the Echo Request from TN3 with an EchoReply.NOTE: Because the intent of the test is to verify that prefix delegationoccurs, the Echo Request in step 3 will be sent to the DUT's global PF1address.NOTE: If the testvar cpeRebootMode is set to "skip", this test will notbe run.  If the testvar cpeRebootMode is set to "reboot", the CPE will berestarted at the end of the test, either using the testvar RestartDUT orby prompting the user.NOTE: The subnet ID of the DUT's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix DelegationPart C: 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 RA4 on the WAN network.RA4IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 1O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively.step 4. The DUT must respond to the Echo Request from TN3 with an EchoReply.NOTE: Because the intent of the test is to verify that prefix delegationoccurs, the Echo Request in step 3 will be sent to the DUT's global PF1address.NOTE: The subnet ID of the DUT's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.5 RA M and O Flags Effect on DHCP Prefix DelegationPart D: M-Flag = 1, O-Flag = 1

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 1O-flag           = 0Router Lifetime  = 600 secondsstep 2. Observe the packets transmitted on the WAN.step 3. TN3 transmits an Echo Request to the DUT's global address withprefix PF1.step 4. Observe the packets transmitted on the WAN.Observable Results:step 2. The DUT must follow the DHCPv6 message procedure defined in theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively. The DUT must perform DAD on its WANinterface.DHCPv6 Solicit Message           DHCPv6 Request MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 1             Message Type     = 3IA_NA Option:                    IA_PD Option:Option Code      = 3             Option Code      = 25IA_PD Option:                    IA_PD Prefix Option:Option Code      = 25            Option Code      = 26Pref. Lifetime   = 600Valid Lifetime   = 600Prefix Length    = 60IPv6 Prefix      = PF1DHCPv6 Advertise Message         DHCPv6 Reply MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 2             Message Type     = 7IA_PD Option:                    IA_PD Option:Option-Code      = 25             Option-Code     = 25IA_PD Prefix Option:             IA_PD Prefix Option:Option Code      = 26             Option Code     = 26Pref. Lifetime   = 600            Pref. Lifetime  = 600Valid Lifetime   = 600            Valid Lifetime  = 600Prefix Length    = 60             Prefix Length   = 60IPv6 Prefix      = PF1            IPv6 Prefix     = PF1NS1IPv6 Header:Next Header      = 58Source Address   = Unspecified address (::)Dest. Address    = Solicited multicast of the DUT's tentativeglobal addressHop Limit        = 255Neighbor Solicitation:Target Address   = The DUT's tentative global addressstep 4. The DUT must transmit and Echo Reply to TN3.NOTE: If the testvar cpeRebootMode is set to "skip", this test will notbe run.  If the testvar cpeRebootMode is set to "reboot", the CPE will berestarted at the end of the test, either using the testvar RestartDUT orby prompting the user.NOTE: The subnet ID of the DUT's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.6 No Global Address is Configured

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 0Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit and Requestmessages. The DHCPv6 server replies with Advertise and Replymessages respectively.DHCPv6 Solicit Message           DHCPv6 Request MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 1             Message Type     = 3IA_PD Option:                    IA_PD Option:Option Code      = 25            Option Code      = 25IA_PD Prefix Option:             IA_PD Prefix Option:Option Code      = 26            Option Code      = 26Pref. Lifetime   = 600           Pref. Lifetime   = 600Valid Lifetime   = 600           Valid Lifetime   = 600Prefix Length    = <64           Prefix Length    = <64IPv6 Prefix      = PF1           IPv6 Prefix      = PF1DHCPv6 Advertise Message         DHCPv6 Reply MessageIPv6 Header:                     IPv6 Header:Next Header      = 17            Next Header      = 17DHCPv6:                          DHCPv6:Message Type     = 2             Message Type     = 7IA_PD Option:                    IA_PD Option:Option-Code      = 25             Option-Code     = 25IA_PD Prefix Option:             IA_PD Prefix Option:Option Code      = 26             Option Code     = 26Pref. Lifetime   = 600            Pref. Lifetime  = 600Valid Lifetime   = 600            Valid Lifetime  = 600Prefix Length    = 64             Prefix Length   = 64IPv6 Prefix      = PF1            IPv6 Prefix     = PF1step 4. The DUT must forward the Echo Request to TN1 and Echo Reply from TN1TN3.The prefix destination address of the Echo Request must be PF1 whichhas a prefix length of 64.Possible Problems:This test may be omitted if the DUT does not implement anapplication for sending ICMPv6 Echo Requests.NOTE: The subnet ID of the TN1's global address in step 3 will becomputed using the value of the testvar ipv6LanSubnetId.  Thedefault is to use a subnet ID of 1.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.7 Different DHCPv6 Prefix Size for Hint

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.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to let the DUT perform the DHCPv6-PD process andassign addresses to the LAN side hosts with prefix PF1.step 3. TN3 transmits an Echo Request to an address that was not assigned tothe 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 toTN3. The code field must be set to "0".Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.1.8 Prevent Forwarding Loops

Purpose: Verify that the DUT assigns /64 addresses from prefix delegation tothe LAN interfaces.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD processand 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.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1step 6. The DUT must forward the Echo Request to TN3.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.1 Assign /64 Prefixes to LAN InterfacesPart A: Prefix Length of /64

Purpose: Verify that the DUT assigns /64 addresses from prefix delegation tothe LAN interfaces.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 48Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD processand 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.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1step 6. The DUT must forward the Echo Request to TN3.NOTE: The subnet ID of the DUT's expected LAN prefix in step 4will 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.02CPE.Conf.2.1 Assign /64 Prefixes to LAN InterfacesPart B: Prefix Length of /48

Purpose: Verify that the DUT assigns /64 addresses from prefix delegation tothe LAN interfaces.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 56Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD processand 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.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1step 6. The DUT must forward the Echo Request to TN3.NOTE: The subnet ID of the DUT's expected LAN prefix in step 4will 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.02CPE.Conf.2.1 Assign /64 Prefixes to LAN InterfacesPart C: Prefix Length of /56

Purpose: Verify that the DUT advertises itself as a router for the delegatedprefix 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                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD processand 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.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1Route Information Option:Type             = 24Prefix Length    = 64Prefix Lifetime  = 600Prefix           = PF1step 6. The DUT must forward the Echo Request to TN3.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.2 RA Route Information OptionPart A: Having WAN Connectivity

Purpose: Verify that the DUT advertises itself as a router for the delegatedprefix 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                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PDprocess and assign address to the LAN side hosts.  TheIA_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.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 0 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1Route Information Option:Type             = 24Prefix Length    = 64Prefix Lifetime  = 600Prefix           = PF1Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.2 RA Route Information OptionPart B: Without WAN Connectivity

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                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsstep 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 tothe Router Solicitation.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 0 secondsReference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.3 No Prefixes DelegatedPart 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 on the WAN network.RA1                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 30Pref. Lifetime   = 30Prefix           = PF1step 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 inresponse to the Router Solicitation.RA3IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1step 7. The DUT must transmit RA2 with Router Lifetime of 0 in response tothe Router Solicitation.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 0 secondsNOTE: The subnet ID of the DUT's expected LAN prefix in step 4will 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 2is dictated by the testvar dhcpv6IAValidLifetime.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.3 No Prefixes DelegatedPart B: Delegated Prefix Expired

Purpose: Verify that the DUT makes each LAN interface an advertising interface.Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1                                  RS1IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                  Dest. Address    = ff02::2M-flag           = 0               Router Solicitation:O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 2. Wait 20 seconds to allow the DUT to perform the DHCPv6-PD processand 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 andL flags of the Prefix Information option must be set to 1.RA2IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 1Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF1NOTE: The subnet ID of the DUT's expected LAN prefix in step 4will 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.02CPE.Conf.2.4 Advertising to Each LAN Interface

Purpose: Verify that the DUT properly advertises RA when the delegated prefix changed. Procedure:step 1. TR1 transmits RA1 on the WAN network.RA1IPv6 Header:Next Header      = 58Router Advertisement:M-flag           = 0O-flag           = 0Router Lifetime  = 600 secondsPrefix Information Option:Type             = 3L-flag           = 1A-flag           = 1Prefix Length    = 64Valid Lifetime   = 600Pref. Lifetime   = 600Prefix           = PF2step 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 PF4to the DUT.Reply Message 1IPv6 Header:Next Header      = 17DHCPv6:Message Type     = 7IA_PD Option:Option Code      = 25IA_PD Prefix Option:Option Code      = 26Pref. Lifetime   = 600Valid Lifetime   = 600Prefix Length    = 60Prefix           = PF4step 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 theDHCPv6 basic message exchange. The DUT transmits Solicit messageand Request message. The DHCPv6 server replies with Advertisemessage 1 and Reply message 1 respectively.The prefix is PF1.Advertise Message 1                  Reply Message 1IPv6 Header:                         IPv6 Header:Next Header      = 17                Next Header      = 17DHCPv6:                              DHCPv6:Message Type     = 2                 Message Type     = 7IA_PD Option:                        IA_PD Option:Option Code      = 25                Option Code      = 25IA_PD Prefix Option:                 IA_PD Prefix Option:Option Code      = 26                Option Code      = 26Pref. Lifetime   = 60                Pref. Lifetime   = 60Valid Lifetime   = 60                Valid Lifetime   = 60Prefix Length    = 60                Prefix Length    = 60Prefix           = PF1               Prefix           = PF1step 4. The DUT must forward the Echo Request to TN3. The DUT must forwardthe Echo Reply from TN3 to TN1.step 6. The DUT must transmit a properly formatted Renew message.Renew MessageIPv6 Header:Next Header      = 17DHCPv6:Message Type     = 5Servier Identifier Option:DUID             = DHCPv6 server's DUIDClient Identifier Option:DUID             = DUT's DUIDIA_PD Option:Option Code      = 25IA_PD PRefix Option:Option Code      = 26Pref. Lifetime   = 600Valid Lifetime   = 600Prefix Length    = 60IPv6 Prefix      = PF1step 9. The DUT must not forward the Echo Request to TN1. The DUT must sendan ICMP Destination Unreachable message, code 5 to TR1.step 11. The DUT must forward the Echo Request to TN1. The DUT must forwardthe Echo Reply from TN1 to TN3.NOTE: The subnet ID of TN1's PF1/PF4 global address in step 8/10will 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 2is dictated by the testvar dhcpv6IAValidLifetime.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.2.5 Delegated Prefix Changed

Purpose: Verify that the DUT properly selects default source address.Procedure:step 1. TR1 transmits RA1 and RA2 on the WAN network.RA1                                  RA2IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                Router Advertisement:M-flag           = 0                 M-flag           = 0O-flag           = 0                 O-flag           = 0Router Lifetime  = 600 seconds       Router Lifetime  = 600 secondsPrefix Information Option:           Prefix Information Option:Type             = 3                 Type             = 3L-flag           = 1                 L-flag           = 1A-flag           = 1                 A-flag           = 1Prefix Length    = 64                Prefix Length    = 64Valid Lifetime   = 600               Valid Lifetime   = 600Pref. Lifetime   = 600               Pref. Lifetime   = 600Prefix           = PF4               Prefix           = PF2step 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 sourceaddress.NOTE: This test may be omitted if the DUT does not implement anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 3.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.3.1 Default Source Address SelectionPart A: 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                                  RA2IPv6 Header:                         IPv6 Header:Next Header      = 58                Next Header      = 58Router Advertisement:                Router Advertisement:M-flag           = 0                 M-flag           = 0O-flag           = 0                 O-flag           = 0Router Lifetime  = 600 seconds       Router Lifetime  = 600 secondsPrefix Information Option:           Prefix Information Option:Type             = 3                 Type             = 3L-flag           = 1                 L-flag           = 1A-flag           = 1                 A-flag           = 1Prefix Length    = 64                Prefix Length    = 64Valid Lifetime   = 600               Valid Lifetime   = 600Pref. Lifetime   = 600               Pref. Lifetime   = 600Prefix           = PF4               Prefix           = PF2step 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 sourceaddress.NOTE: This test may be omitted if the DUT does not implement anapplication for sending ICMPv6 Echo Requests.NOTE: If the testvar interactiveTestMode is set to "skip", this test willnot be run.  If the testvar interactiveTestMode is set to "prompt", theuser will be prompted to cause the DUT to send the ICMPv6 Echo Request instep 4.Reference: IPv6 Forum CE Router Conformance Test Specification, Rev 1.02CPE.Conf.3.1 Default Source Address SelectionPart B: Avoid Deprecated Addresses

step 1. Send a REGISTER from LAN client to SIP proxy on WANstep 2. Verify the LAN client's registration is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txt

step 1. Configure the SIP client and server to use shortheader formatsstep 2. Send a REGISTER from LAN client to SIP proxy on WANstep 3. Verify the LAN client's registration is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtSection 3.1 Outgoing SIP Message ManglingRFC 3261 SIP: Session Initiation ProtocolSection 20 Header Fields

step 1. Register SIP client with SIP proxy on WANstep 2. Initiate an outbound call to remote SIP destinationstep 3. Verify the outbound call is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtSection 3.1 Outgoing SIP Message ManglingRFC 3261 SIP: Session Initiation ProtocolSection 20 Header Fields

step 1. Configure SIP client and server to use short formatfor all SIP headersstep 2. Register SIP client with SIP proxy on WANstep 3. Initiate an outbound call to remote SIP destinationstep 4. Verify the outbound call is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtSection 3.1 Outgoing SIP Message ManglingRFC 3261 SIP: Session Initiation ProtocolSection 20 Header Fields

step 1. Register SIP client with SIP proxy on WANstep 2. Initiate an inbound call to LAN side SIP destinationstep 3. Verify the inbound call is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtSection 3.1 Outgoing SIP Message ManglingRFC 3261 SIP: Session Initiation ProtocolSection 20 Header Fields

step 1. Configure SIP client and server to use short formatfor all SIP headersstep 2. Register SIP client with SIP proxy on WANstep 3. Initiate an inbound call to LAN side SIP destinationstep 4. Verify the inbound call is successfulReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtReference:A SIP Application Level Gateway for Network Address TranslationIETF Draft draft-biggs-sip-nat-00.txtSection 3.1 Outgoing SIP Message ManglingRFC 3261 SIP: Session Initiation ProtocolSection 20 Header Fields

step 1. Read all the configured trigger portsstep 2. For each port, verify that none of the public triggered portsare currently open on the WAN side.step 3. Initiate a TCP or UDP session from the LAN to the WAN sideusing the triggered port as the destination port.step 4. Verify the TCP or UDP session is createdstep 5. For each public port that should now be triggered, opena connection from the WAN to the LAN using the publicport as the destination port and the router's nat IP addressas the destination IP addressstep 5. Verify a connection can be estabished for each public portstep 6. Close down each public portstep 7. Close down the original LAN side connection used for the triggerstep 8. Repeat for each configured port triggerNOTE: Up to 4096 trigger ports can be configured in your configurationfile. For example,testvar triggerName1                  net2phone-1testvar triggerAddrType1              ipv6testvar triggerPort1                  6801testvar triggerType1                  udptestvar triggerPublic1                30000testvar triggerPublicType1            bothtestvar triggerName2                  app1testvar triggerAddrType2              ipv6testvar triggerPort2                  20000testvar triggerType2                  udptestvar triggerPublic2                20001-20010testvar triggerPublicType2            udpNOTE: Many routers will not time out the triggered port connection onceit is open. This will cause this test to fail if it is executed morethan 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 portin the Public range.A delay can be configured between each trigger port. This is sometimesrequired for port trigger implementations using Smart ALGs. To configurethe delay, configure the testvar 'portTriggerDelay' with the number ofmilliseconds.A delay can also be configured before a trigger port is verified as beingopen with WAN to LAN traffic. This is sometimes required forimplemenatations that have a delay associated with processing the outboundtrigger packet. To configure the delay, configure the testvar'portTriggerOpenDelay' with the number of milliseconds.Examples:testvar portTriggerDelay 5000testvar portTriggerOpenDelay 1000

step 1. Read all the configured trigger portsstep 2. Create a second DHCP LAN clientstep 3. Initiate a TCP or UDP session from the LAN to the WAN sideusing the triggered port as the destination portstep 4. Verify the TCP or UDP session is createdstep 5. For each public port that should now be triggered, opena connection from the WAN to the LAN using the publicport as the destination port and the router's nat IP addressas the destination IP address.step 6. Verify a connection can be estabished for each public portstep 7. Close down each public portstep 8. Close down the original LAN side connection used for the triggerstep 9. Wait for port mappings to be aged outstep 10. Repeat from step 2. using the second LAN clientstep 11. Repeat for each configured port triggerNOTE: The port mapping aging time for trigger ports is configuredusing the portTriggerTimeout variable in your config file. Yourrouter must support the aging of trigger ports in order to run thistest.NOTE: Up to 4096 trigger ports can be configured in your configurationfile. For example,testvar triggerName1                  net2phone-1testvar triggerAddrType1              ipv6testvar triggerPort1                  6801testvar triggerType1                  udptestvar triggerPublic1                30000testvar triggerPublicType1            bothNOTE: Many routers will not time out the triggered port connection onceit is open. This will cause this test to fail if it is executed morethan 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 portin the Public range.A delay can be configured between each trigger port. This is sometimesrequired for port trigger implementations using Smart ALGs. To configurethe delay, configure the testvar 'portTriggerDelay' with the number ofmilliseconds.A delay can also be configured before a trigger port is verified as beingopen with WAN to LAN traffic. This is sometimes required forimplemenatations that have a delay associated with processing the outboundtrigger packet. To configure the delay, configure the testvar'portTriggerOpenDelay' with the number of milliseconds.Examples:testvar portTriggerDelay 5000testvar portTriggerOpenDelay 1000

step 1. Forward a packet with a node-local multicast source address from LAN to WANstep 2. Verify packet in Step 1 is not forwarded to the WANstep 3. Repeat steps 1 and 2 with a site-local multicast source addressstep 4. Repeat steps 1 and 2 with a global multicast source addressstep 5. Forward a packet with a node-local multicast source address from WAN to LANstep 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 addressstep 8. Repeat steps 5 and 6 with a global multicast source addressReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-1: Packets bearing multicast source addresses in their outer IPv6headers MUST NOT be forwarded or transmitted on any interface.

step 1. Forward a packet with a node-local multicast destinationaddress from WAN to LANstep 2. Verify packet in Step 1 is not forwarded to the LANstep 3. Forward a packet with a node-local multicast destinationaddress from LAN to WANstep 4. Verify packet in Step 3 is not forwarded to the WANstep 5. Repeat steps 1-4 with a link-local multicast destinationaddressstep 6. Repeat steps 1-4 with a site-local multicast destinationaddressstep 7. Repeat steps 1-4 with a organization-local multicastdestination addressReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-2: Packets bearing multicast destination addresses in their outerIPv6 headers of equal or narrower scope (see "IPv6 Scoped AddressArchitecture" [RFC4007]) than the configured scope boundary level ofthe gateway MUST NOT be forwarded in any direction.  The DEFAULTscope boundary level SHOULD be organization-local scope, and itSHOULD be configurable by the network administrator.IETF RFC 2464 Section 7: Address Mapping -- MulticastAn IPv6 packet with a multicast destination address DST, consistingof the sixteen octets DST[1] through DST[16], is transmitted to theEthernet multicast address whose first two octets are the value 3333hexadecimal and whose last four octets are the last four octets ofDST.IETF RFC 6085 Section 3: Receiving IPv6 Multicast PacketsAn IPv6 node receiving an IPv6 packet with a multicast destinationaddress and an Ethernet link-layer unicast address MUST NOT drop thepacket as a result of the use of this form of address mapping.

step 1. Forward a packet with a non-routable source address from LAN to WANstep 2. Verify packet in Step 1 is not forwarded to the WANstep 3. Forward a packet with a non-routable destination address from LAN to WANstep 4. Verify packet in Step 3 is not forwarded to the WANstep 5. Repeat steps 1 through 4 for various well known non-routable addressesReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-3: Packets bearing source and/or destination addresses forbiddento appear in the outer headers of packets transmitted over the publicInternet MUST NOT be forwarded.  In particular, site-local addressesare deprecated by [RFC3879], and [RFC5156] explicitly forbids the useof address blocks of types IPv4-Mapped Addresses, IPv4-CompatibleAddresses, Documentation Prefix, and Overlay Routable CryptographicHash IDentifiers (ORCHID).

step 1. Forward a packet with routing extension header type 0 from LAN to WANstep 2. Verify packet in Step 1 is not forwarded to the WANReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-4: Packets bearing deprecated extension headers prior to theirfirst upper-layer-protocol header SHOULD NOT be forwarded ortransmitted on any interface.  In particular, all packets withrouting extension header type 0 [RFC2460] preceding the first upper-layer-protocol header MUST NOT be forwarded.  See [RFC5095] foradditional background.

step 1. Create a new LAN clientstep 2. Assign a different global prefix to the LANstep 3. Send traffic to the WAN from the martian source addressstep 4. Verify traffic is not forwardedReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-5: Outbound packets MUST NOT be forwarded if the source addressin their outer IPv6 header does not have a unicast prefix configuredfor use by globally reachable nodes on the interior network.

step 1. Create a new stack on the remoteHoststep 2. Assign the stack the same global prefix as is used on the LANstep 3. Send traffic to the LAN from the remote stackstep 4. Verify traffic is NOT forwarded to the LANReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-6: Inbound packets MUST NOT be forwarded if the source address intheir outer IPv6 header has a global unicast prefix assigned for useby globally reachable nodes on the interior network.

step 1. Send traffic from the LAN to the WAN with a unique-local source addressstep 2. Verify traffic is not forwarded to the WANstep 3. Initiate a new UDP session with the device to allow inbound trafficstep 4. Configure a new stack on the WAN with a unique-local prefix as the sourcestep 5. Send traffic from this new stack to the LANstep 6. Verify traffic is not forwarded to the LANReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-7: By DEFAULT, packets with unique local source and/ordestination addresses [RFC4193] SHOULD NOT be forwarded to or fromthe exterior network.

step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the DUT'sglobal IPv6 addressstep 2. Verify that the query is received by either the primary or backupDNS server on the WANstep 3. Verify that the DNS response is received by the LAN clientstep 4. Initiate an AAAA IPv6 DNS query from a remote host on the WAN to theDUT's global IPv6 addressstep 5. Verify that a DNS response is not received by the remote host on theWAN that initiated the original requestReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-8: By DEFAULT, inbound DNS queries received on exteriorinterfaces MUST NOT be processed by any integrated DNS resolvingserver.

step 1. Start new DHCPv6 client on WAN interfacestep 2. Verify new client does not obtain an IPv6 address via DHCPv6 fromthe DUTstep 3. Send three pings from LAN to WAN to verify that the DUT is stilloperating properlyReference:IETF RFC 6092 Section 3.1: Stateless FiltersCertain kinds of IPv6 packets MUST NOT be forwarded in eitherdirection by residential Internet gateways regardless of networkstate.  These include packets with multicast source addresses,packets to destinations with certain non-routable and/or reservedprefixes, and packets with deprecated extension headers.Other stateless filters are recommended to implement ingressfiltering (see [RFC2827] and [RFC3704]), to enforce multicast scopeboundaries, and to isolate certain local network services from thepublic Internet.REC-9: Inbound DHCPv6 discovery packets [RFC3315] received onexterior interfaces MUST NOT be processed by any integrated DHCPv6server or relay agent.

step 1. Send UDP message from LAN client to WAN serverstep 2. Verify UDP message is received by WAN serverstep 3. Send ICMPv6 Destination Unreachable message from WANserver to LAN client containing a different UDP port thanthe UDP message sent by the LAN client in step 1.step 4. Verify the DUT does not forward the ICMPv6 message to theLAN clientstep 5. Repeat steps 3 and 4 with an ICMPv6 Packet Too BigmessageReference:IETF RFC 6092 Section 3.2.1: Internet Control and ManagementRecommendations for filtering ICMPv6 messages in firewall devices aredescribed separately in [RFC4890] and apply to residential gateways,with the additional recommendation that incoming "DestinationUnreachable" and "Packet Too Big" error messages that don't match anyfiltering state should be dropped.REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "DestinationUnreachable" and "Packet Too Big" messages containing IP headers thatdo not match generic upper-layer transport state records.

step 1. Initiate LAN client UDP ping to WAN serverstep 2. Verify LAN client receives responsestep 3. Wait 115 secondsstep 4. Initiate WAN client UDP ping on same connection as step 1from WAN sidestep 5. Verify WAN client receives a responseReference:IETF RFC 6092 Section 3.2.2: Upper Layer Transport ProtocolsResidential IPv6 gateways are not expected to prohibit the use ofapplications to be developed using future upper-layer transportprotocols.  In particular, transport protocols not otherwisediscussed in subsequent sections of this document are expected to betreated consistently, i.e., as having connection-free semantics andno special requirements to inspect the transport headers.In general, upper-layer transport filter state records are expectedto be created when an interior endpoint sends a packet to an exterioraddress.  The filter allocates (or reuses) a record for the durationof communications, with an idle timer to delete the state record whenno further communications are detected.One key aspect of how a packet filter behaves is the way it evaluatesthe exterior address of an endpoint when applying a filtering rule.A gateway is said to have "endpoint-independent filtering" behaviorwhen the exterior address is not evaluated when matching a packetwith a flow.  A gateway is said to have "address-dependent filtering"behavior when the exterior address of a packet is required to matchthe exterior address for its flow.REC-12: Filter state records for generic upper-layer transportprotocols MUST NOT be deleted or recycled until an idle timer notless than two minutes has expired without having forwarded a packetmatching the state in some configurable amount of time.  By DEFAULT,the idle timer for such state records is five minutes.

step 1. Initiate LAN client UDP ping to WAN serverstep 2. Verify LAN client receives responsestep 3. Wait natUdpTimeout - 10 secondsstep 4. Send UDP ping on same connection from WAN sidestep 5. Verify WAN client receives responseReference:IETF RFC 6092 Section 3.2.3: UDP Filters"Network Address Translation (NAT) Behavioral Requirements forUnicast UDP" [RFC4787] defines the terminology and best currentpractice for stateful filtering of UDP applications in IPv4 with NAT,which serves as the model for behavioral requirements for simple UDPsecurity in IPv6 gateways, notwithstanding the requirements relatedspecifically to network address translation.An interior endpoint initiates a UDP flow through a stateful packetfilter by sending a packet to an exterior address.  The filterallocates (or reuses) a filter state record for the duration of theflow.  The state record defines the interior and exterior IPaddresses and ports used between all packets in the flow.State records for UDP flows remain active while they are in use andare only abandoned after an idle period of some time.REC-14: A state record for a UDP flow where both source anddestination 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.

step 1. Initiate a LAN client UDP ping to WAN serverstep 2. Verify LAN client receives responsestep 3. Wait natUdpTimeout/2 secondsstep 4. Initiate a LAN client UDP ping to WAN serverstep 5. Verify LAN client receives a responsestep 6. Wait natUdpTimeout - 10 secondsstep 7. Initiate a WAN server UDP ping to LAN clientstep 8. Verify WAN server received a responseReference:IETF RFC 6092 Section 3.2.3: UDP FiltersAs [RFC4787] notes, outbound refresh is necessary for allowing theinterior endpoint to keep the state record alive.  Inbound refreshmay be useful for applications with no outbound UDP traffic.However, allowing inbound refresh can allow an attacker in theexterior or a misbehaving application to keep a state record aliveindefinitely.  This could be a security risk.  Also, if the processis repeated with different ports, over time, it could use up all thestate record memory and resources in the filter.REC-16: A state record for a UDP flow MUST be refreshed when a packetis forwarded from the interior to the exterior, and it MAY berefreshed when a packet is forwarded in the reverse direction.

step 1. Forward a UDP packet from a LAN client to the WANstep 2. Forward a packet back from the WAN to the same LAN clientstep 3. Verify packet is receivedFor Full-Cone NATstep 4. Forward a packet using a different source port but same IP address from the WANstep 5. Verify the packet is forwarded to the LANstep 6. Forward a packet using a different IPv4 address and same source portstep 7. Verify the packet is forwarded to the LANstep 8. Forward a packet usuing the same IPv4 address and same source portstep 9. Verify the packet is forwarded to the LANFor Address-Restricted NATstep 4. Forward a packet using a different IPv4 address and same source portstep 5. Verify the packet is not forwarded to the LANstep 6. Forward a packet using a different source port but same IP address from the WANstep 7. Verify the packet is forwarded to the LANstep 8. Forward a packet usuing the same IPv4 address and same source portstep 9. Verify the packet is forwarded to the LANFor Port-Restricted NATstep 4. Forward a packet using a different source port but same IP address from the WANstep 5. Verify the packet is not forwarded to the LANstep 6. Forward a packet using the same source port and IP address from the WANstep 7. Verify the packet is forwarded to the LANReference:IETF RFC 6092 Section 3.2.3: UDP FiltersAs described in Section 5 of [RFC4787], the connection-free semanticsof UDP pose a difficulty for packet filters in trying to recognizewhich packets comprise an application flow and which are unsolicited.Various strategies have been used in IPv4/NAT gateways with differingeffects.REC-17: If application transparency is most important, then astateful packet filter SHOULD have "endpoint-independent filtering"behavior for UDP.  If a more stringent filtering behavior is mostimportant, then a filter SHOULD have "address-dependent filtering"behavior.  The filtering behavior MAY be an option configurable bythe network administrator, and it MAY be independent of the filteringbehavior for TCP and other protocols.  Filtering behavior SHOULD beendpoint independent by DEFAULT in gateways intended for provisioningwithout service-provider management.

step 1. Send IPv6 UDP packet from LAN to WANstep 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable messagestep 3. Verify ICMPv6 Destination Unreachable message is received on the LANstep 4. Send IPv6 UDP packet from LAN to WANstep 5. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big messagestep 6. Verify ICMPv6 Too Big message is received on the LANReference:IETF RFC 6092 Section 3.2.3: UDP FiltersApplication mechanisms may depend on the reception of ICMPv6 errormessages triggered by the transmission of UDP messages.  One suchmechanism 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 containingUDP headers that match the flow state record.

step 1. Send IPv6 UDP packet from LAN to WANstep 2. Verify UDP packet is received on the WAN and return an ICMPv6 Destination Unreachable messagestep 3. Verify ICMPv6 Destination Unreachable message is received on the LANstep 4. Send UDP response from WAN to LANstep 5. Verify UDP response is received on LAN since IPv6 firewall state is still presentstep 6. Send IPv6 UDP packet from LAN to WANstep 7. Verify UDP packet is received on the WAN and return an ICMPv6 Packet Too Big messagestep 8. Verify ICMPv6 Too Big message is received on the LANstep 9. Send UDP response from WAN to LANstep 10. Verify UDP response is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092 Section 3.2.3: UDP FiltersApplication mechanisms may depend on the reception of ICMPv6 errormessages triggered by the transmission of UDP messages.  One suchmechanism is path MTU discovery [RFC1981].REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a UDP flow.

step 1. Forward UDP packet from LAN to WANstep 2. Verify UDP packet in step 1 is forwarded to the WANstep 3. Forward matching UDP-Lite packet from WAN to LANstep 4. Verify UDP-Lite packet in step 3 is not forwarded to theLANstep 5. Forward UDP-Lite packet from LAN to WANstep 6. Verify UDP-Lite packet in step 5 is forwarded to the WANstep 7. Forward matching UDP packet from WAN to LANstep 8. Verify UDP packet in step 7 is not forwarded to the LANReference:IETF RFC 6092 Section 3.2.3: UDP FiltersApplication mechanisms may depend on the reception of ICMPv6 errormessages triggered by the transmission of UDP messages.  One suchmechanism is path MTU discovery [RFC1981].REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way asUDP flows, except that the upper-layer transport protocol identifierfor UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOTmatch UDP-Lite state records, and vice versa.

step 1. Forward UDP packet with IPv6 Authentication Header fromLAN to WANstep 2. Verify UDP packet is forwarded to the WANstep 3. Forward UDP packet with IPv6 Authentication Header fromWAN to LANstep 4. Verify UDP packet is forwarded to the LANReference:IETF RFC 6092 Section 3.2.4: IPSec and Internet Key Exchange (IKE)The Internet Protocol security (IPsec) suite offers greaterflexibility and better overall security than the simple security ofstateful 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 NOTprohibit the forwarding of packets, to and from legitimate nodeaddresses, with destination extension headers of type "AuthenticationHeader (AH)" [RFC4302] in their outer IP extension header chain.

step 1. Initiate an outbound TCP session from LAN client to WANserverstep 2. Verify session initiation is successfulstep 3. Terminate TCP session from LAN sidestep 4. Verify session is terminated successfullyReference:IETF RFC 6092 Section 3.3.1: TCP FiltersAn interior endpoint initiates a TCP flow through a stateful packetfilter by sending a SYN packet.  The filter allocates (or reuses) afilter state record for the flow.  The state record defines theinterior and exterior IP addresses and ports used for forwarding allpackets for that flow.Some peer-to-peer applications use an alternate method of connectioninitiation termed "simultaneous-open" ([RFC0793], Figure 8) totraverse stateful filters.  In the simultaneous-open mode ofoperation, both peers send SYN packets for the same TCP flow.  TheSYN packets cross in the network.  Upon receiving the other end's SYNpacket, each end responds with a SYN-ACK packet, which also cross inthe network.  The connection is established at each endpoint once theSYN-ACK packets are received.To provide stateful packet filtering service for TCP, it is necessaryfor a filter to receive, process, and forward all packets for a flowthat 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 inboundflows.  In particular, both the normal TCP 3-way handshake mode ofoperation and the simultaneous-open mode of operation MUST besupported.NOTE: This test case only verifies that the normal TCP 3-wayhandshake mode is supported.

step 1. Configure TCP LAN client and TCP WAN server to use a TCPwindow size of 10 bytesstep 2. Configure LAN client and WAN server to be in anestablished TCP sessionstep 3. Transmit 20 bytes of TCP data from LAN client to WANserverstep 4. Verify WAN server receives 20 bytes of TCP datastep 5. Transmit 20 bytes of TCP data from WAN server to LANclientstep 6. Verify LAN client receives 20 bytes of TCP datastep 7. Terminate TCP session from LAN sideReference:IETF RFC 6092 Section 3.3.1: TCP FiltersIt is possible to reconstruct enough of the state of a TCP flow toallow forwarding between an interior and exterior node, even when thefilter starts operating after TCP enters the established state.  Inthis case, because the filter has not seen the TCP window-scaleoption, it is not possible for the filter to enforce the TCP windowinvariant by dropping out-of-window segments.REC-32: The TCP window invariant MUST NOT be enforced on flows forwhich the filter did not detect whether the window-scale option (see[RFC1323]) was sent in the 3-way handshake or simultaneous-open.

step 1. Forward a TCP packet from a LAN client to the WANstep 2. Forward a packet back from the WAN to the same LAN clientstep 3. Verify packet is receivedFor Full-Cone NATstep 4. Forward a packet using a different source port but same IP address from the WANstep 5. Verify the packet is forwarded to the LANstep 6. Forward a packet using a different IPv4 address and same source portstep 7. Verify the packet is forwarded to the LANstep 8. Forward a packet usuing the same IPv4 address and same source portstep 9. Verify the packet is forwarded to the LANFor Address-Restricted NATstep 4. Forward a packet using a different IPv4 address and same source portstep 5. Verify the packet is not forwarded to the LANstep 6. Forward a packet using a different source port but same IP address from the WANstep 7. Verify the packet is forwarded to the LANstep 8. Forward a packet usuing the same IPv4 address and same source portstep 9. Verify the packet is forwarded to the LANFor Port-Restricted NATstep 4. Forward a packet using a different source port but same IP address from the WANstep 5. Verify the packet is not forwarded to the LANstep 6. Forward a packet using the same source port and IP address from the WANstep 7. Verify the packet is forwarded to the LANReference:IETF RFC 6092 Section 3.3.1: TCP FiltersA stateful filter can allow an existing state record to be reused byan externally initiated flow if its security policy permits.  Severaldifferent policies are possible, as described in [RFC4787] andextended in [RFC5382].REC-33: If application transparency is most important, then astateful packet filter SHOULD have "endpoint-independent filtering"behavior for TCP.  If a more stringent filtering behavior is mostimportant, then a filter SHOULD have "address-dependent filtering"behavior.  The filtering behavior MAY be an option configurable bythe network administrator, and it MAY be independent of the filteringbehavior for UDP and other protocols.  Filtering behavior SHOULD beendpoint independent by DEFAULT in gateways intended for provisioningwithout service-provider management.

step 1. Initiate an unsolicited inbound TCP session from WANserver to LAN clientstep 2. Verify WAN server receives an ICMPv6 DestinationUnreachable message with error code 1Reference:IETF RFC 6092 Section 3.3.1: TCP FiltersIf an inbound SYN packet is filtered, either because a correspondingstate record does not exist or because of the filter's normalbehavior, a filter has two basic choices: to discard the packetsilently, or to signal an error to the sender.  Signaling an errorthrough ICMPv6 messages allows the sender to detect that the SYN didnot reach the intended destination.  Discarding the packet, on theother hand, allows applications to perform simultaneous-open morereliably.  A more detailed discussion of this issue can be found in[RFC5382], but the basic outcome of it is that filters need to waiton 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 withdestination administratively prohibited) to any unsolicited inboundSYN packet after waiting at least 6 seconds without first forwardingthe associated outbound SYN or SYN/ACK from the interior peer.

step 1. Initiate an outbound TCP session from LAN client to WANserverstep 2. Verify session initiation is successfulstep 3. Allow TCP session to idle for 2 hoursstep 4. Transfer TCP data from WAN server to LAN clientstep 5. Verify LAN client receives TCP datastep 6. Terminate TCP session from LAN sideReference:IETF RFC 6092 Section 3.3.1: TCP FiltersA TCP filter maintains state associated with in-progress connectionsand established flows.  Because of this, a filter is susceptible to aresource-exhaustion attack whereby an attacker (or virus) on theinterior attempts to cause the filter to exhaust its capacity forcreating state records.  To defend against such attacks, a filterneeds to abandon unused state records after a sufficiently longperiod of idleness.A common method used for TCP filters in IPv4/NAT gateways is toabandon preferentially flow state records for crashed endpoints,followed by closed flows and partially open flows.  A gateway cancheck 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 RSTpacket in response.  If the gateway cannot determine whether theendpoint is active, then the associated state record needs to beretained 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-timeoutthat accommodates all applications.  However, a large idle-timeoutmotivated by recommendations in [RFC1122] and [RFC4294] can reducethe chances of abandoning a live flow.TCP flows can stay in the established phase indefinitely withoutexchanging packets.  Some end-hosts can be configured to send keep-alive packets on such idle flows; by default, such packets are sentevery two hours, if enabled [RFC1122].  Consequently, a filter thatwaits for slightly over two hours can detect idle flows with keep-alive packets being sent at the default rate.  TCP flows in thepartially open or closing phases, on the other hand, can stay idlefor at most four minutes while waiting for in-flight packets to bedelivered [RFC1122].The "established flow idle-timeout" for a stateful packet filter isdefined as the minimum time a TCP flow in the established phase mustremain idle before the filter considers the associated state record acandidate for collection.  The "transitory flow idle-timeout" for afilter is defined as the minimum time a TCP flow in the partiallyopen or closing phases must remain idle before the filter considersthe associated state record a candidate for collection.  TCP flows inthe 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 TCPflow are active, then it MAY abandon the state record if it has beenidle for some time.  In such cases, the value of the "establishedflow idle-timeout" MUST NOT be less than two hours four minutes, asdiscussed 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.

step 1. Establish TCP connection from LAN to WANstep 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connectionstep 3. Verify ICMPv6 Destination Unreachable message is received on the LANstep 4. Send an ICMPv6 Packet Too Big message from the WAN for the connectionstep 5. Verify ICMPv6 Packet Too Big message is received on the LANReference:IETF RFC 6092 Section 3.3.1: TCP FiltersBehavior for handling RST packets or TCP flows in the TIME-WAIT stateis left unspecified.  A gateway MAY hold state for a flow in theTIME-WAIT state to accommodate retransmissions of the last ACK.However, since the TIME-WAIT state is commonly encountered byinterior endpoints properly closing the TCP flow, holding state for aclosed flow can limit the throughput of flows through a gateway withlimited resources.  [RFC1337] discusses hazards associated withTIME-WAIT assassination.The handling of non-SYN packets for which there is no active staterecord is left unspecified.  Such packets can be received if thegateway abandons a live flow, or abandons a flow in the TIME-WAITstate before the four-minute TIME-WAIT period expires.  The decisioneither to discard or to respond with an ICMPv6 "DestinationUnreachable" error code 1 (Communication with destinationadministratively prohibited) is left up to the implementation.Behavior for notifying endpoints when abandoning live flows is leftunspecified.  When a gateway abandons a live flow, for example due toa timeout expiring, the filter MAY send a TCP RST packet to eachendpoint on behalf of the other.  Sending a RST notification allowsendpoint applications to recover more quickly; however, notifyingendpoints might not always be possible if, for example, state recordsare lost due to power interruption.Several TCP mechanisms depend on the reception of ICMPv6 errormessages triggered by the transmission of TCP segments.  One suchmechanism is path MTU discovery, which is required for correctoperation of TCP.REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6"Destination Unreachable" and "Packet Too Big" messages containingTCP headers that match the flow state record.

step 1. Establish TCP connection from LAN to WANstep 2. Send an ICMPv6 Destination Unreachable message from the WAN for the connectionstep 3. Send TCP data segment from WAN to LAN for the sessionstep 4. Verify TCP data segment is received on LAN since IPv6 firewall state is still presentstep 5. Send an ICMPv6 Packet Too Big message from the WAN for the connectionstep 6. Send TCP data segment from WAN to LAN for the sessionstep 7. Verify TCP data segment is received on LAN since IPv6 firewall state is still presentReference:IETF RFC 6092 Section 3.3.1: TCP FiltersBehavior for handling RST packets or TCP flows in the TIME-WAIT stateis left unspecified.  A gateway MAY hold state for a flow in theTIME-WAIT state to accommodate retransmissions of the last ACK.However, since the TIME-WAIT state is commonly encountered byinterior endpoints properly closing the TCP flow, holding state for aclosed flow can limit the throughput of flows through a gateway withlimited resources.  [RFC1337] discusses hazards associated withTIME-WAIT assassination.The handling of non-SYN packets for which there is no active staterecord is left unspecified.  Such packets can be received if thegateway abandons a live flow, or abandons a flow in the TIME-WAITstate before the four-minute TIME-WAIT period expires.  The decisioneither to discard or to respond with an ICMPv6 "DestinationUnreachable" error code 1 (Communication with destinationadministratively prohibited) is left up to the implementation.Behavior for notifying endpoints when abandoning live flows is leftunspecified.  When a gateway abandons a live flow, for example due toa timeout expiring, the filter MAY send a TCP RST packet to eachendpoint on behalf of the other.  Sending a RST notification allowsendpoint applications to recover more quickly; however, notifyingendpoints might not always be possible if, for example, state recordsare lost due to power interruption.Several TCP mechanisms depend on the reception of ICMPv6 errormessages triggered by the transmission of TCP segments.  One suchmechanism is path MTU discovery, which is required for correctoperation of TCP.REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for a TCP flow.

step 1. Initiate SCTP association from LAN client to WAN serverstep 2. Verify association initiation is successfulstep 3. Terminate SCTP association from LAN sidestep 4. Verify association is terminated successfulReference:IETF RFC 6092 Section 3.3.2: SCTP FiltersBecause Stream Control Transmission Protocol (SCTP) [RFC4960] flowscan be terminated at multiple network addresses, IPv6 simple securityfunctions cannot achieve full transparency for SCTP applications.  Inmultipath traversal scenarios, full transparency requirescoordination between all the packet filter processes in the variouspaths between the endpoint network addresses.  Such coordination isnot "simple", and it is, therefore, beyond the scope of thisrecommendation.However, some SCTP applications are capable of tolerating theinherent unipath restriction of IPv6 simple security, even inmultipath traversal scenarios.  They expect connection-orientedfiltering behaviors similar to those for TCP, but at the level ofSCTP associations, not stream connections.  This section describesspecific recommendations for SCTP filtering for such traversalscenarios.An interior endpoint initiates SCTP associations through a statefulpacket filter by sending a packet comprising a single INIT chunk.The filter allocates (or reuses) a filter state record for theassociation.  The state record defines the interior and exterior IPaddresses and the observed verification tag used for forwardingpackets in that association.Some peer-to-peer SCTP applications use an alternate method ofassociation initiation, termed "simultaneous-open", to traversestateful filters.  In the simultaneous-open mode of operation, bothpeers send INIT chunks at the same time to establish an association.Upon receiving the other end's INIT chunk, each end responds with anINIT-ACK packet, which is expected to traverse the same path inreverse.  Because only one SCTP association may exist between any twonetwork addresses, one of the peers in the simultaneous-open mode ofoperation will send an ERROR or ABORT chunk along with the INIT-ACKchunk.  The association is established at each endpoint once anINIT-ACK chunk without an ERROR or ABORT chunk is received at oneend.To provide stateful packet filtering service for SCTP, it isnecessary for a filter to receive, process, and forward all packetsfor an association that conform to valid transitions of the SCTPstate machine ([RFC4960], Figure 3).REC-38: All valid sequences of SCTP packets (defined in [RFC4960])MUST be forwarded for outbound associations and explicitly permittedinbound associations.  In particular, both the normal SCTPassociation establishment and the simultaneous-open mode of operationMUST be supported.NOTE: This test case only verifies that the normal SCTPassociation establishment is supported.

step 1. Initiate an unsolicited inbound SCTP association from WANclient to LAN serverstep 2. Verify WAN client receives ICMPv6 Destination Unreachablemessage with error code 1Reference:IETF RFC 6092 Section 3.3.2: SCTP FiltersIf an inbound INIT packet is filtered, either because a correspondingstate record does not exist or because of the filter's normalbehavior, a filter has two basic choices: to discard the packetsilently, or to signal an error to the sender.  Signaling an errorthrough ICMPv6 messages allows the sender to detect that the INITpacket did not reach the intended destination.  Discarding thepacket, on the other hand, allows applications to performsimultaneous-open more reliably.  Delays in signaling errors canprevent 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 withdestination administratively prohibited), to any unsolicited inboundINIT packet after waiting at least 6 seconds without first forwardingthe associated outbound INIT from the interior peer.

step 1. Initiate an outbound SCTP association from LAN client toWAN serverstep 2. Verify association initiation is successfulstep 3. Allow association to idle for 2 hoursstep 4. Transmit SCTP data from WAN server to LAN clientstep 5. Verify LAN client receives SCTP datastep 6. Terminate SCTP association from LAN clientstep 7. Verify association is terminated successfullyReference:IETF RFC 6092 Section 3.3.2: SCTP FiltersAn SCTP filter maintains state associated with in-progress andestablished associations.  Because of this, a filter is susceptibleto a resource-exhaustion attack whereby an attacker (or virus) on theinterior attempts to cause the filter to exhaust its capacity forcreating state records.  To defend against such attacks, a filterneeds to abandon unused state records after a sufficiently longperiod of idleness.A common method used for TCP filters in IPv4/NAT gateways is toabandon preferentially sessions for crashed endpoints, followed byclosed associations and partially opened associations.  A similarmethod is an option for SCTP filters in IPv6 gateways.  A gateway cancheck if an endpoint for an association has crashed by sendingHEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If thegateway cannot determine whether the endpoint is active, then theassociated state record needs to be retained until the SCTPassociation 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-timeoutthat accommodates all applications.  However, a large idle-timeoutmotivated by recommendations in [RFC4294] can reduce the chancesof abandoning a live association.SCTP associations can stay in the ESTABLISHED state indefinitelywithout exchanging packets.  Some end-hosts can be configured to sendHEARTBEAT chunks on such idle associations, but [RFC4960] does notspecify (or even suggest) a default time interval.  A filter thatwaits for slightly over two hours can detect idle associations withHEARTBEAT packets being sent at the same rate as most hosts use forTCP keep-alive, which is a reasonably similar system for thispurpose.  SCTP associations in the partially open or closing states,on the other hand, can stay idle for at most four minutes whilewaiting for in-flight packets to be delivered (assuming the suggestedSCTP protocol parameter values in Section 15 of [RFC4960]).The "established association idle-timeout" for a stateful packetfilter is defined as the minimum time an SCTP association in theestablished phase must remain idle before the filter considers thecorresponding state record a candidate for collection.  The"transitory association idle-timeout" for a filter is defined as theminimum time an SCTP association in the partially open or closingphases must remain idle before the filter considers the correspondingstate record a candidate for collection.REC-40: If a gateway cannot determine whether the endpoints of anSCTP association are active, then it MAY abandon the state record ifit has been idle for some time.  In such cases, the value of the"established association idle-timeout" MUST NOT be less thantwo hours four minutes.

step 1. Disable SCTP WAN server on port Astep 2. Initiate an outbound SCTP association from LAN client toWAN server on port Astep 3. Wait 230 secondsstep 4. Enable SCTP WAN server on port Astep 5. Wait 5 secondsstep 6. Verify association initiation from step 2 is successfulstep 7. Terminate SCTP association from LAN sidestep 8. Verify association is terminated successfulReference:IETF RFC 6092 Section 3.3.2: SCTP FiltersAn SCTP filter maintains state associated with in-progress andestablished associations.  Because of this, a filter is susceptibleto a resource-exhaustion attack whereby an attacker (or virus) on theinterior attempts to cause the filter to exhaust its capacity forcreating state records.  To defend against such attacks, a filterneeds to abandon unused state records after a sufficiently longperiod of idleness.A common method used for TCP filters in IPv4/NAT gateways is toabandon preferentially sessions for crashed endpoints, followed byclosed associations and partially opened associations.  A similarmethod is an option for SCTP filters in IPv6 gateways.  A gateway cancheck if an endpoint for an association has crashed by sendingHEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If thegateway cannot determine whether the endpoint is active, then theassociated state record needs to be retained until the SCTPassociation 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-timeoutthat accommodates all applications.  However, a large idle-timeoutmotivated by recommendations in [RFC4294] can reduce the chancesof abandoning a live association.SCTP associations can stay in the ESTABLISHED state indefinitelywithout exchanging packets.  Some end-hosts can be configured to sendHEARTBEAT chunks on such idle associations, but [RFC4960] does notspecify (or even suggest) a default time interval.  A filter thatwaits for slightly over two hours can detect idle associations withHEARTBEAT packets being sent at the same rate as most hosts use forTCP keep-alive, which is a reasonably similar system for thispurpose.  SCTP associations in the partially open or closing states,on the other hand, can stay idle for at most four minutes whilewaiting for in-flight packets to be delivered (assuming the suggestedSCTP protocol parameter values in Section 15 of [RFC4960]).The "established association idle-timeout" for a stateful packetfilter is defined as the minimum time an SCTP association in theestablished phase must remain idle before the filter considers thecorresponding state record a candidate for collection.  The"transitory association idle-timeout" for a filter is defined as theminimum time an SCTP association in the partially open or closingphases must remain idle before the filter considers the correspondingstate record a candidate for collection.REC-40: If a gateway cannot determine whether the endpoints of anSCTP association are active, then it MAY abandon the state recordif it has been idle for some time.  [...] The value of the"transitory association idle-timeout" MUST NOT be less than fourminutes.  The value of the idle-timeouts MAY be configurable bythe network administrator.

step 1. Initiate an outbound SCTP association from LAN client toWAN serverstep 2. Verify association initiation is successfulstep 3. Forward an ICMPv6 Destination Unreachable message from LANclient to WAN serverstep 4. Verify message is received by WAN serverstep 5. Forward an ICMPv6 Destination Unreachable message from WANserver to LAN clientstep 6. Verify message is received by LAN clientstep 7. Forward an ICMPv6 Packet Too Big message from LAN clientto WAN serverstep 8. Verify message is received by WAN serverstep 9. Forward an ICMPv6 Packet Too Big message from WAN serverto LAN clientstep 10. Verify message is received by LAN clientstep 11. Terminate SCTP association from LAN sidestep 12. Verify association is terminated successfulReference:IETF RFC 6092 Section 3.3.2: SCTP FiltersBehavior for handling ERROR and ABORT packets is left unspecified.  Agateway MAY hold state for an association after its closing phaseshave completed to accommodate retransmissions of its final SHUTDOWNACK packets.  However, holding state for a closed association canlimit the throughput of associations traversing a gateway withlimited resources.  The discussion in [RFC1337] regarding the hazardsof TIME-WAIT assassination is relevant.The handling of inbound non-INIT packets for which there is no activestate record is left unspecified.  Such packets can be received ifthe gateway abandons a live flow, or abandons an association in theclosing states before the transitory association idle-timeoutexpires.  The decision either to discard or to respond with an ICMPv6"Destination Unreachable" error code 1 (Communication withdestination administratively prohibited) is left to theimplementation.Behavior for notifying endpoints when abandoning live associations isleft unspecified.  When a gateway abandons a live association, forexample due to a timeout expiring, the filter MAY send an ABORTpacket to each endpoint on behalf of the other.  Sending an ABORTnotification allows endpoint applications to recover more quickly;however, notifying endpoints might not always be possible if, forexample, state records are lost due to power interruption.Several SCTP mechanisms depend on the reception of ICMPv6 errormessages triggered by the transmission of SCTP packets.REC-41: If a gateway forwards an SCTP association, it MUST alsoforward ICMPv6 "Destination Unreachable" and "Packet Too Big"messages containing SCTP headers that match the association staterecord.

step 1. Initiate an outbound SCTP association from LAN client to WAN serverstep 2. Verify association initiation is successfulstep 3. Forward an ICMPv6 Destination Unreachable message from LANclient to WAN serverstep 4. Transmit SCTP data from WAN server to LAN clientstep 5. Verify LAN client receives SCTP datastep 6. Verify SCTP association is still establishedstep 7. Forward an ICMPv6 Destination Unreachable message from WANserver to LAN clientstep 8. Transmit SCTP data from WAN server to LAN clientstep 9. Verify LAN client receives SCTP datastep 10. Verify SCTP association is still establishedstep 11. Forward an ICMPv6 Packet Too Big message from LAN clientto WAN serverstep 12. Transmit SCTP data from WAN server to LAN clientstep 13. Verify LAN client receives SCTP datastep 14. Verify SCTP association is still establishedstep 15. Forward an ICMPv6 Packet Too Big message from WAN serverto LAN clientstep 16. Transmit SCTP data from WAN server to LAN clientstep 17. Verify LAN client receives SCTP datastep 18. Verify SCTP association is still establishedstep 19. Transmit SCTP data from WAN server to LAN clientstep 20. Verify LAN client receives SCTP datastep 21. Verify SCTP association is still establishedstep 22. Terminate SCTP association from LAN sidestep 23. Verify association is terminated successfulReference:IETF RFC 6092 Section 3.3.2: SCTP FiltersBehavior for handling ERROR and ABORT packets is left unspecified.  Agateway MAY hold state for an association after its closing phaseshave completed to accommodate retransmissions of its final SHUTDOWNACK packets.  However, holding state for a closed association canlimit the throughput of associations traversing a gateway withlimited resources.  The discussion in [RFC1337] regarding the hazardsof TIME-WAIT assassination is relevant.The handling of inbound non-INIT packets for which there is no activestate record is left unspecified.  Such packets can be received ifthe gateway abandons a live flow, or abandons an association in theclosing states before the transitory association idle-timeoutexpires.  The decision either to discard or to respond with an ICMPv6"Destination Unreachable" error code 1 (Communication withdestination administratively prohibited) is left to theimplementation.Behavior for notifying endpoints when abandoning live associations isleft unspecified.  When a gateway abandons a live association, forexample due to a timeout expiring, the filter MAY send an ABORTpacket to each endpoint on behalf of the other.  Sending an ABORTnotification allows endpoint applications to recover more quickly;however, notifying endpoints might not always be possible if, forexample, state records are lost due to power interruption.Several SCTP mechanisms depend on the reception of ICMPv6 errormessages triggered by the transmission of SCTP packets.REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate thestate record for an SCTP association.

step 1. Listen for RIPng reply from LAN side IP address of routerstep 2. Verify RIPng versionstep 3. Verify source address of RIPng replyNOTE: This test is only run if the 'supportsRIPng' configurationis set to 'yes'.Reference:IETF RFC 2080 Section 2.3: Timers

step 1. Start new IPv6 client on LAN interfacestep 2. Announce new RIPng route with metric 1 from new IPv6 clientstep 3. Forward from original LAN client to IP address within thenew RIPng route rangestep 4. Verify the packet is forwarded to the new IPv6 clientReference:IETF RFC 2080 Section 2.4.2: Response Messages

step 1. Send RIPng Request from new UDP src port to RIPng destination addressstep 2. Verify router returns a RIPng responsestep 3. Verify the response is sent to the correct UDP portstep 4. Verify the response is sent using unicast IP destinationIETF RFC 2080 Section 2.4.1: Request Messages

step 1. Start 2 new IPv6 clients on LAN interface (R1 and R2)step 2. Announce new RIPng route with metric 10 from R1step 3. Announce same RIPng route with metric 9 from R2step 4. Forward from original LAN client to IP address within thenew RIng route rangestep 5. Verify the packet is forwarded to R2Reference:IETF RFC 2080 Section 2.4.2: Response Messages

step 1. Start new IPv6 client on LAN interfacestep 2. Announce new RIPng route with metric 16 from new IPv6 clientstep 3. Forward from original LAN client to IP address within thenew RIPng route rangestep 4. Verify the packet is not forwarded to the new IPv6 clientstep 5. Verify the packet is forwarded to WAN sideReference:IETF RFC 2080 Section 2.4.2: Response Messages

step 1. Start new IPv6 client on LAN interfacestep 2. Announce new RIPng route with metric 1 from new IPv6 clientstep 3. Wait for new RIPng updatestep 4. Verify route is not announced (split horizon) or announced asunreachable (poison reverse)Reference:IETF RFC 2080 Section 2.5.2: Generating Response Messages

step 1. Listen for RIPng updates for 1 minutestep 2. Verify default route (/0) is announced as reachableReference:IETF RFC 2080 Section 2.2: Addressing Considerations

step 1. Start a new IPv6 client on LAN interfacestep 2. Announce new RIPng routes with metric 1 from new IPv6 clientNOTE: The 'ripMaxRoutes' variable in your configuration filedetermines the number of RIPng routes that are announced.step 3. Forward from original LAN client to IP address within theeach new route rangestep 4. Verify packets are forwarded for each new routeReference:IETF RFC 2080 Section 2.1: Message Format

step 1. Announce new RIPng route with metric 1 from WAN sidestep 2. Wait for new RIPng update on the LANstep 3. Verify new route is announced on the LANstep 4. Forward packet from LAN to new IP destinationstep 5. Verify packet is forwarded to WAN sideNOTE: This test is only enabled when testvar ripAcceptWanUpdateis set to yes. The default is no.testvar ripAcceptWanUpdate yesReference:IETF RFC 2080 Section 2.4.2: Response Messages

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 thenew RIng route rangestep 4. Verify the packet is forwarded to R2Reference:IETF RFC 2080 Section 2.1.1: Next Hop