ETSI TS 102 517 V2.0.1 (2008-01)

Technical Specification
Methods for Testing and Specification (MTS);
Internet Protocol Testing (IPT): IPv6 Core Protocol;
Interoperability Test Suite (ITS)

2 ETSI TS 102 517 V2.0.1 (2008-01)

Reference
RTS/MTS-IPT-007[2]-IPv6-CorITS
Keywords
IP, IPv6, interoperability, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 102 517 V2.0.1 (2008-01)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
2.1 Normative references.6
3 Abbreviations.7
4 IPv6 Core Interoperability Test Specification.7
4.1 Introduction.7
4.2 Test Descriptions.8
4.2.1 Group 1 RFC 2460.8
4.2.1.1 Group 1.2 Process IPv6 Packet .8
4.2.1.1.1 Group 1.2.4 Process IPv6 Header.8
4.2.1.1.2 Group 1.2.6 Process Flow Label .10
4.2.1.2 Group 1.4 Extension Headers.11
4.2.1.2.1 Group 1.4.2 Process Extension Headers.11
4.2.1.2.2 Group 1.4.4 Routing Header.13
4.2.1.2.3 Group 1.4.5 Fragment Header .15
4.2.2 Group 2 RFC 2461.17
4.2.2.1 Group 2.1 Generate Neighbor Discovery Messages .17
4.2.2.1.1 Group 2.1.5 Generate Router Advertisement .17
4.2.2.1.2 Group 2.1.6 Generate Router Solicitation .24
4.2.2.1.3 Group 2.1.7 Generate Neighbor Advertisement .24
4.2.2.1.4 Group 2.1.8 Generate Redirect Message .25
4.2.2.2 Group 2.2 Process Neighbor Discovery Messages.26
4.2.2.2.1 Group 2.2.5 Process Router Advertisement.26
4.2.2.2.2 Group 2.2.6 Process Router Solicitation.31
4.2.2.2.3 Group 2.2.7 Process Neighbor Advertisement .35
4.2.2.2.4 Group 2.2.8 Process Neighbor Solicitation .35
4.2.2.3 Group 2.5 Next Hop Determination.37
4.2.2.4 Group 2.6 Neighbor Uneachability Detection.38
4.2.2.4.1 Group 2.6.6 Neighbor Reachability Determination.38
4.2.2.5 Group 2.7 Address Resolution .39
4.2.2.5.1 Group 2.7.1 Interface Initialization .41
4.2.3 Group 3 RFC 2462.44
4.2.3.1 Group 3.1 Initialize .44
4.2.3.1.1 Group 3.1.1 Configure Address.44
4.2.4 Group 4 RFC 2463.49
4.2.4.1 Group 4.1 ICMPv6 Functions .49
4.2.4.1.1 Group 4.1.1 Determine ICMPv6 Message Source Address .49
4.2.4.1.2 Group 4.1.2 ICMPv6 Error Messages .51
4.2.4.1.3 Group 4.1.3 Information Messages .54
4.2.5 Group 5 RFC 3513.55
4.2.5.1 Group 5.2 Address Architecture.55
4.2.5.2 Group 5.5 Unicast Addresses.58
4.2.5.2.1 Group 5.5.6 Link Local Unicast Addresses.59
4.2.5.3 Group 5.6 Anycast Addresses .60
4.2.5.4 Group 5.7 Multicast Addresses .60
4.2.5.4.1 Group 5.7.1 Pre-defined Multicast Addresses .60
4.2.5.4.2 Group 5.7.2 Node .61
4.2.6 Group 6 RFC 1981.62
4.2.6.1 Group 6.1 Discover PMTU.62
4.2.6.1.1 Group 6.1.1 Multicast PMTU Discovery .64
4.2.7 Group 7 RFC 2675.65
ETSI
4 ETSI TS 102 517 V2.0.1 (2008-01)
Annex A (informative): IPv6 Interoperability Test Purposes .67
Annex B (informative): Interoperability Testing Configurations.103
History .106

ETSI
5 ETSI TS 102 517 V2.0.1 (2008-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and
Specification (MTS).
ETSI
6 ETSI TS 102 517 V2.0.1 (2008-01)
1 Scope
The present document specifies the interoperability Test Descriptions (TDs) with integrated Test Purposes (TPs) for the
IPv6 Core standards. The TDs are presented in the tabular form specified in TS 102 424 [1] and the TPs are defined
using the TPLan notation also described in TS 102 424 [1]. The Test Suite Structure is based on the IETF RFCs which,
together, form the IPv6 Core specification and is reflected in the use of "Group/End Group" statements in the TPLan
code presented in annex A.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 102 424 (2005): "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Requirements of the NGN network to support Emergency
Communication from Citizen to Authority".
[2] IETF RFC 1981: "Path MTU Discovery for IP version 6".
[3] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification".
[4] IETF RFC 2461: "Neighbor Discovery for IP Version 6 (IPv6)".
[5] IETF RFC 2462: "IPv6 Stateless Address Autoconfiguration".
[6] IETF RFC 2463: "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification".
[7] IETF RFC 2675: "IPv6 Jumbograms".
[8] IETF RFC 3513: "Internet Protocol Version 6 (IPv6) Addressing Architecture".
ETSI
7 ETSI TS 102 517 V2.0.1 (2008-01)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
EUT Equipment Under Test
HS Host
i/f interface
LL Link Local
M/cast Multicast
MTU Maximum Transmission Unit
PMTU Path MTU
QE Qualified Equipment
RT RouTer
SL Site Local
TP Test Purpose
TD Test Description
TPLan Test Purpose Language
TSS Test Suite Structure
4 IPv6 Core Interoperability Test Specification
4.1 Introduction
The IPv6 Core Interoperability Test Descriptions (TDs) defined in the following clauses are derived from the Test
Purposes (TPs) specified in annex A.
ETSI
8 ETSI TS 102 517 V2.0.1 (2008-01)
4.2 Test Descriptions
4.2.1 Group 1 RFC 2460
4.2.1.1 Group 1.2 Process IPv6 Packet
4.2.1.1.1 Group 1.2.4 Process IPv6 Header
4.2.1.1.1.1 Group 1.2.4.4 Process Hop Limit
Test Description
Identifier: Test Purpose:
TD_COR_1002_01 TP_COR_1002_01
Summary: EUT decreases the Hop Limit field of a traversed IPv6 packet and forwards it
Roles: Router Configuration: CF_CORE_22
References: RQ_000_1002
with { QE1 'configured with a unique global unicast address '
and QE2 'configured with a unique global unicast address'
and EUT 'configured with two unique global unicast addresses on the link
connecting QE1 and EUT, and the link connecting QE2 and EUT, respectively' }

ensure that {
when { EUT receives 'a packet'
containing 'QE1 as source address and QE2 as destination address'
and containing 'Hop Limit > 1' }
then { EUT sends 'the packet with the Hop Limit decremented' to QE2 }
}
Pre-test conditions: EUT established as the default router for QE1
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with QE2 identified as the
destination and hop limit larger than 1
2 Check: Does protocol monitor on link2 show that the Echo Request was Yes No
sent from QE1 to QE2, with a decremented hop limit?
3 Check: Does QE1 receive an Echo Reply from QE2? Yes No
Observations:
Test Description
Identifier: Test Purpose:
TD_COR_1002_02 TP_COR_1002_02
Summary: EUT drops a traversed IPv6 packets with a zero Hop Limit and returns an ICMP error message to
the source
Roles: Configuration:
Router CF_CORE_22
References: RQ_000_1002
with { QE1 'configured with a unique global unicast address '
and QE2 'configured with a unique global unicast address'
and EUT 'configured with two unique global unicast addresses on the link
connecting QE1 and EUT, and on the link connecting QE2 and EUT, respectively' }

ensure that {
when { EUT receives 'a packet'
containing 'QE1 as source address and QE2 as destination address'
and containing 'Hop Limit = 0' }
then { EUT discards 'the packet'
and EUT sends 'an ICMP error message' to QE1 }
}
Pre-test conditions:
EUT established as the default router for QE1
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with QE2 identified as the
destination and hop limit of 1
2 Check: Does the protocol monitor on link2 show that the Echo Request No Yes
was sent from QE1 to QE2?
3 Check: Does the protocol monitor on link1 show that an ICMP error Yes No
message was sent from EUT to QE1?
Observations:
ETSI
9 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_1058_01 Test Purpose: TP_COR_1058_01
Summary: Discard packets if Hop Limit ≤ 1
Roles: Host, Router Configuration: CF_CORE_22
References:
RQ_000_1058
ensure that {
when { QE1 is requested to 'send a packet to QE2'
containing 'Routing header Type = 0'
and containing 'Segments Left value other than zero'
and containing 'Segments Left value not greater than the number of addresses
in the Routing header'
and containing 'an even "Hdr Ext Len" value'
and not containing 'multicast address as next address to be visited or IPv6 Destination'
and containing 'IPv6 hop limit ≤ 1'
and containing 'EUT as next routing hop' }
then { EUT sends 'ICMP "Time Exceeded" error message' to QE1
and EUT discards 'the packet' }
}
Pre-test conditions: EUT established as the default router for QE1
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- hop limit =1
- type 0 routing header
- EUT as next routing hop
- QE2 as final destination
2 Check: Does the protocol monitor on link2 show that the Echo Request No Yes
was sent from QE1 to QE2?
3 Check: Does the protocol monitor on link1 show that an ICMP 'Time Yes No
Exceeded' error message was sent from EUT to QE1?
Observations: A QE cannot send out any message with hop limit = 0, thus hop limit = 1 is chosen for this test.

Test Description
Identifier: Test Purpose:
TD_COR_1059_01 TP_COR_1059_01
Summary:
Process packets if Hop Limit > 1
Roles: Host, Router Configuration: CF_CORE_22
References: RQ_000_1059
ensure that {
when { QE1 is requested to 'send a packet to QE2'
containing 'Routing header Type = 0'
and containing 'Segments Left value other than zero'
and containing 'Segments Left value not greater than the number of addresses in
the Routing header'
and containing 'an even "Hdr Ext Len" value'
and not containing 'multicast address as next address to be visited or IPv6 Destination'
and containing 'IPv6 hop limit > 1'
and containing 'EUT as next routing hop' }
then { EUT sends 'the packet to QE2' }
}
Pre-test conditions: EUT established as the default router for QE1
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- hop limit >1
- type 0 routing header
- EUT as next routing hop
- QE2 as final destination
2 Check: Does the protocol monitor on link2 show that the Echo Request Yes No
was sent from QE1 to QE2?
Observations:
ETSI
10 ETSI TS 102 517 V2.0.1 (2008-01)
4.2.1.1.2 Group 1.2.6 Process Flow Label
Test Description
Identifier: Test Purpose:
TD_COR_1130_01 TP_COR_1130_01
Summary:
EUT detects two packets with different hop-by-hop option contents but the same source and
destination addresses and the same flow label
Roles: Host, Router Configuration: CF_CORE_22
References:
RQ_000_1130
with { QE1 'configured with a unique global unicast address '
and QE2 'configured with a unique global unicast address'
and EUT 'configured with two unique global unicast addresses on the link connecting QE1 and
EUT and, the link connecting QE2 and EUT, respectively' }

ensure that {
when { EUT receives 'two packets'
containing 'QE1 as source address and QE2 as destination address'
and containing 'a same flow label'
and containing 'different hop-by-hop options' }
then { EUT sends 'an ICMP parameter problem message' to QE1
and EUT discards 'the packets' }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations: This IOP test is practically impossible. One router cannot guarantee the arrival and processing of
two different packets at same time.

Test Description
Identifier: TD_COR_1130_02 Test Purpose: TP_COR_1130_02
Summary: EUT detects two packets with different routing header contents but the same source and destination
addresses and the same flow label
Roles: Host, Router Configuration: CF_CORE_22
References: RQ_000_1130
with { QE1 'configured with a unique global unicast address '
and QE2 'configured with a unique global unicast address'
and EUT 'configured with two unique global unicast addresses on the link connecting QE1 and
EUT and, the link connecting QE2 and EUT, respectively' }

ensure that {
when { EUT receives 'two packets'
containing 'QE1 as source address and QE2 as destination address'
and containing 'a same flow label'
and containing 'different hop-by-hop options' }
then { EUT sends 'an ICMP parameter problem message' to QE1
and EUT discards 'the packets'}
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations: This IOP test is practically impossible. One router cannot guarantee the arrival and processing of
two different packets at same time.

ETSI
11 ETSI TS 102 517 V2.0.1 (2008-01)
4.2.1.2 Group 1.4 Extension Headers
4.2.1.2.1 Group 1.4.2 Process Extension Headers
Test Description
Identifier: Test Purpose:
TD_COR_1004_01 TP_COR_1004_01
Summary: EUT does NOT process (modify) a Routing Header contained in a packet NOT destined for the EUT
Roles: Host, Router Configuration: CF_CORE_31
References: RQ_000_1004
with { QE1 'configured with a unique non link-local unicast address'
and QE2 'configured as a router with a unique non link-local unicast address'
and QE3 'configured with a unique non link-local unicast address'
and EUT 'configured with one unique non link-local unicast address on each link'
and EUT 'established as the default Router for QE1' }

ensure that {
when { EUT receives 'a packet' from QE1
containing 'an indication that QE2 is the destination'
and containing 'a Routing Header'
indicating 'QE2 as the first node to process the Routing Header
and QE3 as the final destination of the packet' }
then { EUT 'forwards the packet, with the Routing Header UNMODIFIED' to QE2}
}
Pre-test conditions: QE2 is configured as a Router
EUT established as the default router for QE1
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with QE3 identified as the final
destination, QE2 as an intermediate hop and normal routing tables
bypassed (ping6 -r QE2 QE3)
2 Check: Does protocol monitor show that the Echo Request was sent from Yes No
QE1 to QE3?
3 Check: Does QE1 receive an Echo Reply fromQE3? Yes No
Observations:
Test Description
Identifier: Test Purpose:
TD_COR_1004_02 TP_COR_1004_02
Summary: EUT does NOT process(remove) a Fragmentation Header contained in a packet NOT destined for
the EUT
Roles: Configuration:
Host, Router CF_CORE_22
References: RQ_000_1004
with { QE1 'configured with a non link-local unicast address'
and EUT 'configured with a unique non link-local unicast address on each link' }

ensure that {
when { EUT receives 'a packet' from QE1
containing 'an indication that QE2 is the destination'
and containing 'a Fragmentation Header' }
then { EUT 'forwards the packet with its Fragmentation Header' to QE2 }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations:
ETSI
12 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_1004_03 Test Purpose: TP_COR_1004_03
Summary: EUT does NOT process(modify or remove) a Destination Options Header in a packet NOT destined
for the EUT
Roles: Host, Router Configuration: CF_CORE_31
References: RQ_000_1004
with { QE1 'configured with a unique non link-local unicast address'
and QE2 'configured as a router with a unique non link-local unicast address'
and QE3 'configured with a unique global unicast address'
and EUT 'configured with a unique non link-local unicast address on each link' }

ensure that {
when { EUT receives 'a packet' from QE1
containing 'an indication that QE2 is the destination'
and containing 'a Destination Options Header' }
then { EUT 'forwards the packet, with the Destination Options Header UNMODIFIED'
to QE2 }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations:
In an interoperability testing environment it is almost (if not totally) impossible to reproduce the
conditions that would reliably cause the Destination Options Header to be used.

Test Description
Identifier: Test Purpose:
TD_COR_1005_01 TP_COR_1005_01
Summary:
EUT processes a Destination Options Header contained in a packet destined for the EUT
Roles: Host, Router Configuration: CF_CORE_11
References: RQ_000_1005
with { QE 'configured with a unique link-local address'
and EUT 'configured with a unique link-local address' }

ensure that {
when { EUT receives 'fragment packets of a Request that requires a Reply' from QE
containing 'a Fragmentaion Option in the Destination Options Header' }
-- A Destination Options Header can carry a Fragmentation option that
-- achieves the same results as a Fragmentation Header.--
-- The usage choice depends on the processing resources consumed--
then { EUT sends 'the expected Reply' to QE }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations: In an interoperability testing environment it is almost (if not totally) impossible to reproduce the
conditions that would reliably cause the Destination Options Header to be used.

ETSI
13 ETSI TS 102 517 V2.0.1 (2008-01)
4.2.1.2.2 Group 1.4.4 Routing Header
4.2.1.2.2.1 Group 1.4.4.2 Process Routing Header
Test Description
Identifier: TD_COR_1042_01 Test Purpose: TP_COR_1042_01
Summary: Discard packet and generate ICMP error message if packet size larger than MTU
Roles: Router Configuration: CF_CORE_22
References: RQ_000_1042
with { 'Link2 configured with a smaller MTU than Link1' }

ensure that {
when { QE1 is requested to 'send a packet larger than Link2 MTU to QE2'
containing 'EUT as next routing hop' }
then { EUT discards 'the packet'
and EUT sends 'ICMP "Packet too big" error message 'to QE1 }
}
Pre-test conditions:
PMTU of link1 is set to a value greater than PMTU of link2.
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- (PMTU of link2) < Echo Request packet size < (PMTU of link1)
- EUT is the next routing hop.
- QE2 is the final destination.
2 Check: Does the protocol monitor on Link2 show that the Echo Request Yes No
has NOT been forwarded to QE2? (EUT has discarded the Echo Request)
3 Check: Does the protocol monitor on Link1 show that EUT has sent an Yes No
ICMP 'Packet too big' error message to QE1?
Observations:
Test Description
Identifier: TD_COR_1049_01 Test Purpose: TP_COR_1049_01
Summary: Routing Header NOT processed until IPv6 header Dest. Addr. reached
Roles: Host, Router Configuration: CF_CORE_31
References: RQ_000_1004
with { EUT 'not included in the Routing Header vector (hop) list' }

ensure that {
when { QE1 is requested to 'send a packet to QE3'
containing 'QE2 as next routing hop'
and EUT 'is on the path to QE2' }
then { EUT ignores 'the routing header'
and EUT 'routes the packet to QE2' }
}
Pre-test conditions:
EUT is established as default router for all nodes
QE2 is a router
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- QE2 is the next routing hop
- QE3 is the final destination
2 Check: Does the protocol monitor on Link2 show that EUT forwarded the Yes No
Echo Request message to QE2 without changing the routing header?
Observations:
ETSI
14 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_1050_01 Test Purpose: TP_COR_1050_01
Summary: Routing Header IS processed when IPv6 header Dest. Addr. reached
Roles: Host, Router Configuration: CF_CORE_31
References:
RQ_000_1050
with { EUT 'included in the Routing Header vector (hop) list' }

ensure that {
when { QE1 is requested to 'send a packet to QE3'
containing 'EUT as next routing hop'
and QE2 'as subsequent routing hop' }
then { EUT 'processes the routing header'
and EUT 'routes the packet' to QE2 }
}
Pre-test conditions:
EUT is established as default router for all nodes
QE2 is a router
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- EUT is the next routing hop
- QE2 is the subsequent routing hop
- QE3 is the final destination
2 Use the protocol monitor on Link1 to record the original Echo Request sent
by QE1
3 Check: Does the protocol monitor on Link2 show that EUT forwarded the Yes No
Echo Request message to QE2?
4 Check: Does the protocol monitor on Link2 show that EUT has correctly Yes No
updated (*) the Headers (IPv6 header and Routing header) of the
forwarded Echo Request?
Observations: (*) EUT should have modified the original Echo Request packet as follow:
Swap the IPv6 Destination Address and the address of the next hop to be visited.
Decrement the segment left byte by 1

Test Description
Identifier: Test Purpose:
TD_COR_1055_01 TP_COR_1055_01
Summary:
Discard multicast packets
Roles: Host, Router Configuration: CF_CORE_31
References: RQ_000_1055
ensure that {
when { QE1 is requested to 'send a packet to QE3'
containing 'Routing header Type 0'
and containing 'a Segments Left Field value other than zero'
and containing 'an even "Hdr Ext Len" value'
and containing 'Segments Left Field not greater than the number of addresses
in the Routing header'
and containing 'EUT as next routing hop'
and containing 'QE2 multicast address as subsequent routing hop' }
then { EUT discards 'the packet' }
}
Pre-test conditions: EUT is established as default router for all nodes
QE2 is a router
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- EUT as next routing hop
- a multicast address of QE2 as subsequent routing hop
- QE3 as final destination
2 Check: Does the protocol monitor on Link2 show that EUT forwarded the No Yes
Echo Request message to QE2?
Observations: If the next routing hop to be visited is a multicast address the node should discard the packet.

ETSI
15 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_1056_01 Test Purpose: TP_COR_1056_01
Summary: Discard multicast packets
Roles: Host, Router Configuration: CF_CORE_22
References:
RQ_000_1056
ensure that {
when { QE1 is requested to 'send a packet to the multicast address of QE2'
containing 'Routing header Type 0'
and containing 'a Segments Left Field value other than zero'
and containing 'an even "Hdr Ext Len" value'
and containing 'Segments Left Field not greater than the number of addresses
in the Routing header'
and containing 'EUT as next hop in the routing header' }
then { EUT discards 'the packet' }
}
Pre-test conditions:
EUT is established as default router for all nodes
QE2 has a routable multicast address
Step Test Sequence Verdict
Pass Fail
1 Cause QE1 to send an Echo Request with the following properties:
- EUT is the next routing hop
- a multicast address of QE2 as final destination.
2 Check: Does the protocol monitor on Link2 show that EUT forwarded the No Yes
Echo Request message to QE2?
Observations: The multicast address used to address QE2 should be a routable address (multicast scope should
be site-local, organization-local, or global), not a link-local multicast address.

4.2.1.2.3 Group 1.4.5 Fragment Header
4.2.1.2.3.1 Group 1.4.5.1 Generate Fragmented Packets
Test Description
Identifier: TD_COR_1064_01 Test Purpose: TP_COR_1064_01
Summary: EUT fragments a packet larger than the available PMTU before sending it
Roles: Host, Router Configuration: CF_CORE_23
References: RQ_000_1064
with { 'the MTU on Link1 set greater than the MTU on Link2' }

ensure that {
when { EUT is requested to 'send a packet of greater length than
the MTU of Link2' to QE2 }
then { QE2 indicates 'receipt of the same data without any
modification' }
}
Pre-test conditions: MTU on the link between QE1 and the EUT set to a value greater than that on the link between QE1
and QE2
Step Test Sequence Verdict
Pass Fail
1 Cause EUT to send an Echo Request to QE2 with a packet size greater
than the MTU between QE1 and QE2 but less than the PMTU between
QE1 and EUT and with each octet set to the hexadecimal value 'F0'
2 Check: Does protocol monitor show that the Echo Request was sent from Yes No
EUT to QE2?
3 Check: Does EUT receive a Packet Too Big message from QE1 Yes No
4 Cause EUT to send an Echo Request to QE2 with a packet size greater
than the MTU between QE1 and QE2 but less than the PMTU between
QE1 and EUT and with each octet set to the hexadecimal value 'F0'
5 Check: Does protocol monitor show that the Echo Request was sent from Yes No
EUT to QE2?
6 Check: Does QE1 receive an Echo Reply from QE2 with the packet length Yes No
the same as the Echo Request and with each octet containing the
hexadecimal value 'F0'?
Observations:
ETSI
16 ETSI TS 102 517 V2.0.1 (2008-01)
4.2.1.2.3.2 Group 1.4.5.2 Process Fragmented Packets
Test Description
Identifier: Test Purpose:
TD_COR_1100_01 TP_COR_1100_01
Summary: EUT reassembles a fragmented packet of an original length less than 1 500 octets
Roles: Host, Router Configuration: CF_CORE_11
References: RQ_000_1100
with { 'the MTU on Link1 set to 1 400 octets' }

ensure that {
when { QE is requested to 'send data requiring a packet
length lesser than 1 500 octets' }
then { EUT indicates 'receipt of the same data without
modification' }
}
Pre-test conditions: MTU set to 1 400 octets on link1

Step Test Sequence Verdict
Pass Fail
1 Cause QE to send an Echo Request to EUT with a packet size of
1 450 octets and with each octet set to the hexadecimal value 'F0'
2 Check: Does protocol monitor show that the Echo Request was sent from Yes No
QE to EUT?
3 Check: Does QE receive an Echo Reply from EUT with the packet length Yes No
the same as the Echo Request and with each octet containing the
hexadecimal value 'F0'?
Observations:
Test Description
Identifier: Test Purpose:
TD_COR_1100_02 TP_COR_1100_02
Summary: EUT reassembles a fragmented packet of an original length equal to 1500 octets
Roles: Host, Router Configuration: CF_CORE_11
References: RQ_000_1100
with { 'the MTU on Link1 set to 1 400 octets' }

ensure that {
when { QE is requested to 'send data requiring a packet
length equal to 1 500 octets' }
then { EUT indicates 'receipt of the same data without
modification' }
}
Pre-test conditions: PMTU set to 1 400 octets on link1

Step Test Sequence Verdict
Pass Fail
1 Cause QE to send an Echo Request to EUT with a packet size of
1 500 octets and with each octet set to the hexadecimal value 'F0'
2 Check: Does protocol monitor show that the Echo Request was sent from Yes No
QE to EUT?
3 Check: Does QE receive an Echo Reply from EUT with a packet length of Yes No
1 500 octets with each octet containing the hexadecimal value 'F0'?
Observations:
ETSI
17 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_1101_01 Test Purpose: TP_COR_1101_01
Summary: EUT reassembles a fragmented packet of an original length greater than 1 500 octets
Roles: Host, Router Configuration: CF_CORE_11
References:
RQ_000_1101
with { 'the MTU on Link1 set to 1 400 octets' }

ensure that {
when { QE is requested to 'send data requiring a packet
length greater than 1 500 octets' }
then { EUT indicates 'receipt of the same data without
modification' }
}
Pre-test conditions:
PMTU set to 1 400 octets on link1

Step Test Sequence Verdict
Pass Fail
1 Cause QE to send an Echo Request to EUT with a packet size greater
than 1 500 octets and with each octet set to the hexadecimal value 'F0'
2 Check: Does protocol monitor show that the Echo Request was sent from Yes No
QE to EUT?
3 Check: Does QE receive an Echo Reply from EUT with a packet length the Yes No
same as the Echo Request and with each octet containing the
hexadecimal value 'F0'?
Observations:
4.2.2 Group 2 RFC 2461
4.2.2.1 Group 2.1 Generate Neighbor Discovery Messages
4.2.2.1.1 Group 2.1.5 Generate Router Advertisement
Test Description
Identifier: Test Purpose:
TD_COR_8295_01 TP_COR_8295_01
Summary: EUT (as a router) does not send Router Advertisements out any interface that is not an advertising
interface
Roles: Configuration:
CF_CORE_11
References: RQ_000_8295
with { QE 'configured with a unicast address'
and EUT 'configured with a multicast address'
and EUT 'not configured to have any unicast address' }

ensure that {
when { EUT 'is initializing' }
then { EUT 'does not send Router Advertisement to QE' }
}
Pre-test conditions: EUT is a router with an advertising interface
Configure EUT to have a multicast address and no unicast address
Step Test Sequence Verdict
Pass Fail
1 Cause the EUT's advertising interface to disable its advertising function
2 Check: Does the protocol monitor show that EUT sends a Router No Yes
Advertisement over this interface?
Observations:
ETSI
18 ETSI TS 102 517 V2.0.1 (2008-01)
4.2.2.1.1.1 Group 2.1.5.1 Router Advertisement Behaviour
4.2.2.1.1.1.1 Group 2.1.5.1.1 Router Advertisement Behaviour on Reconfiguration
Test Description
Identifier: TD_COR_8256_01 Test Purpose: TP_COR_8256_01
Summary: By default a router does not advertise its presence unless it has been explicitly configured to do so
Roles: Configuration: CF_CORE_11
References:
RQ_000_8256
with { QE 'configured with a unique global unicast address'
and EUT 'configured as a router with a unique global unicast address'
and EUT 'not configured to send router advertisements' }

ensure that {
when { EUT 'is initializing' }
then { EUT 'does not send Router Advertisement to QE'
and EUT discards 'Router Solicitation sent by QE' }
}
Pre-test conditions:
EUT configured as a router
EUT configured not to send any router advertisement
EUT power down
Step Test Sequence Verdict
Pass Fail
1 Reconnect EUT to the network (power-up)
2 Check: Does the protocol monitor show that a router advertisement is sent
from EUT?
3 Reconnect QE to the network (power-up)
4 Check: Does the protocol monitor show that a router solicitation is sent Yes No
from QE?
5 Check: Does the protocol monitor show that a router advertisement is sent No Yes
from EUT to QE?
Observations:
Test Description
Identifier: TD_COR_8297_01 Test Purpose: TP_COR_8297_01
Summary:
A disabled EUT advertising interface returns to being an advertising interface when re-enabled
Roles: Configuration: CF_CORE_11
References: RQ_000_8297
with { EUT 'advertising interface disabled' }
-- such that its network interfaces ceases to be an advertising interface --

ensure that {
when { EUT 'network interface is administratively re-enabled' }
then { EUT 'network interface returns to being an advertising interface' }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations:
This function is purely internal with no significant interoperability issues.

ETSI
19 ETSI TS 102 517 V2.0.1 (2008-01)
Test Description
Identifier: TD_COR_8313_01 Test Purpose: TP_COR_8313_01
Summary: EUT transmits FINAL Router advertisement messages and departs from the all-routers IP multicast
group on all interfaces on which the EUT supports IP multicast
Roles: Configuration: CF_CORE_22
References: RQ_000_8313
with { EUT 'configured to support IP multicast on its two interfaces'
and EUT 'configured to act as the default router for QE1' }

ensure that {
when { EUT 'network interface to QE1 is DISABLED from sending RA messages'
-- but the interface is still up and operational --
and EUT 'IP forwarding capability is DISABLED' }
then { EUT sends 'a number of Router Advertisement messages onto the link to
which QE1 is attached'
and EUT 'then leaves the all-routers IP multicast group on both interfaces' }
}
Pre-test conditions:
Step Test Sequence Verdict
Pass Fail
Observations:
This function is purely internal with no significant interoperability issues.

Test Description
Identifier: TD_COR_8314_01 Test Purpose: TP_COR_8314_01
Summary: When EUT becomes a Host, subsequent Neighbor Advertisements transmitted from a previously
advertising interface indicate that EUT is no longer a Router
Roles: Configuration: CF_CORE_22
References: RQ_000_8314
with { EUT 'Router Advertisements disabled on two previously advertising interfaces'
and EUT 'has IP forwarding disabled'
and EUT 'removed from all-routers IP multicast group on both interfaces'
and EUT 'configured as a Host' }

ensure that {
when { EUT is requested to 'send a Neighbor Advertisement message(s) from any of
...