L2 transparency – IPv6¶
This task verifies IPv6 header integrity, i.e. checks that IPv6 packets are not dropped or blocked in the network.
This task also verifies transparency for a number of IPv6 protocols:
Multicast Listener Discovery (MLD), Versions 1 and 2
ICMPv6 with packet types
Router Solicitation
Router Advertisement
Neighbor Solicitation
Neighbor Advertisement
ICMPv6 Echo
DHCPv6 Solicit
The link is considered IPv6 transparent if the IPv6 packets go through. No verification is done of packet content.
Test procedure and fail criteria¶
The test is divided into two parts corresponding to the above description.
IPv6 header integrity¶
In this part of the test, 10 IPv6 packets are sent with dummy payload. The flow label, hop limit, traffic class fields, and UDP ports are set to the same value (in the range 0 … 255) for each packet.
The test fails if any packet is dropped, or if the flow label, hop limit, traffic class fields, or UDP ports do not match between sender and receiver.
IPv6 protocol transparency¶
In this part of the test, a number of IPv6 protocols are tested for transparency. For each protocol, one packet is generated with correctly configured Ethernet and IPv6 headers, and it is checked that the messages pass transparently. The protocols tested are:
Protocol |
Messages |
---|---|
Multicast Listener Discovery Protocol, version 1 (MLD) |
MLD query and report messages |
Multicast Listener Discovery Protocol, version 2 (MLDv2) |
MLD query and report messages |
Neighbor Solicitation |
Neighbor Solicitation messages |
Neighbor Advertisement |
Neighbor Advertisement messages |
Router Solicitation |
Router Solicitation messages |
Router Advertisement |
Router Advertisement messages |
ICMPv6 Echo |
ICMPv6 Echo messages |
DHCPv6 Solicit |
DHCPv6 Solicit messages |
The test fails for a particular protocol if the message sent on that protocol does not pass transparently.
Limitations¶
This test can only be run on physical or VLAN interfaces (not bridges).
This test cannot be run through a routed (Layer 3) network.
Regarding use of the Test Agent management interface for this test, see here.
Parameters¶
General¶
Sender: The sender Test Agent interface.
Receiver: The receiver Test Agent interface.
Expected outcome for <protocol>: For each protocol, select Pass, Drop, or Don’t test. Default: Pass.
Wait for ready: Time to wait before starting this test step. The purpose of inserting a wait is to allow all Test Agents time to come online and acquire good time sync. Min: 1 min. Max: 24 hours. Default: “Don’t wait”, i.e. zero wait time.
Result metrics¶
Pass/fail on IPv6 header integrity, overall and for each IPv6 protocol