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

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

RTS/MTS-IPT-007[2]-IPv6-CorITS

General Information

• Status: Published
• Publication Date: 14-Jan-2008
• Technical Committee: MTS IPT - IP Testing Group
• Current Stage: 12 - Completion
• Due Date: 15-Jan-2008
• Completion Date: 15-Jan-2008

Standards Content (Sample)

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)

---------------------- Page: 1 ----------------------
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.: [phone]  Fax: [phone]

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

---------------------- Page: 2 ----------------------
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

---------------------- Page: 3 ----------------------
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

---------------------- Page: 4 ----------------------
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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
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

---------------------- Page: 8 ----------------------
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

---------------------- Page: 9 ----------------------
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

---------------------- Page: 10 ----------------------
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

---------------------- Page: 11 ----------------------
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

---------------------- Page: 12 ----------------------
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 ho
...