ETSI TS 102 514 V2.1.1 (2008-02)

ETSI TS 102 514 V2.1.1 (2008-02)
Technical Specification
Methods for Testing and Specification (MTS);
Internet Protocol Testing (IPT): IPv6 Core Protocol;
Requirements Catalogue
---------------------- Page: 1 ----------------------
2 ETSI TS 102 514 V2.1.1 (2008-02)
Reference
RTS/MTS-IPT-003[2]-IPv6-CrRqCa
Keywords
IP, IPv6, 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

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

If you find errors in the present document, please send your comment to one of the following services:

DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered

3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.

Intellectual Property Rights................................................................................................................................4

Foreword.............................................................................................................................................................4

1 Scope........................................................................................................................................................5

2 References................................................................................................................................................5

2.1 Normative references.........................................................................................................................................5

3 Abbreviations...........................................................................................................................................6

4 Requirements Catalogue...........................................................................................................................6

4.1 Requirements extracted from TS 123 060..........................................................................................................6

4.2 Requirements extracted from TS 123 221..........................................................................................................8

4.3 Requirements extracted from TS 129 061..........................................................................................................8

4.4 Requirements extracted from RFC 1981..........................................................................................................25

4.5 Requirements extracted from RFC 2460..........................................................................................................29

4.6 Requirements extracted from RFC 2461..........................................................................................................72

4.7 Requirements extracted from RFC 2462........................................................................................................261

4.8 Requirements extracted from RFC 2463........................................................................................................283

4.9 Requirements extracted from RFC 2464........................................................................................................314

4.10 Requirements extracted from RFC 2675........................................................................................................318

4.11 Requirements extracted from RFC 3513........................................................................................................326

Annex A (informative): Duplicated requirements.............................................................................355

Annex B (informative): Bibliography.................................................................................................357

History ............................................................................................................................................................358

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

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

This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and

The purpose of the present document is to provide a catalogue of requirements extracted from the core IPv6 RFCs (see

references in clause 2) and from ETSI Specifications. The catalogue follows the guidelines defined by the MTS IPv6

References are either specific (identified by date of publication and/or edition number or version number) or

• Non-specific reference may be made only to a complete document or a part thereof and only in the following

- if it is accepted that it will be possible to use all future changes of the referenced document for the

Referenced documents which are not found to be publicly available in the expected location might be found at

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

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee

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

[8] IETF RFC 2463: "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6

[11] IETF RFC 3513: "Internet Protocol Version 6 (IPv6) Addressing Architecture".

[12] ETSI TS 123 060: "Digital cellular telecommunications system (Phase 2+); Universal Mobile

[13] ETSI TS 123 221: "Digital cellular telecommunications system (Phase 2+); Universal Mobile

[14] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile

[15] ETSI TS 129 061: "Digital cellular telecommunications system (Phase 2+); Universal Mobile

Telecommunications System (UMTS); Interworking between the Public Land Mobile Network

(PLMN) supporting packet based services and Packet Data Networks (PDN) (3GPP TS 29.061)".

The requirements below have been extracted from IETF RFCs 1981 [2], 2460 [5], 2461 [6], 2462 [7], 2463 [8],

2464 [9], 2675 [10], 3513[11]) and ETSI specifications TS 123 060 [12], TS 123 221 [13], TS 123 228 [14],

An IPv6 Mobile Station is performing either stateless or stateful address autoconfiguration

An IPv6 Mobile Station SHALL use the interface identifier provided by the Gateway GPRS Support

To ensure that the link-local address generated by the MS does not collide with the link-local

address of the GGSN, the GGSN shall provide an interface identifier (see RFC 2462 [69]) to the

MS and the MS shall use this interface identifier to configure its link-local address. This is

applicable for both stateful and stateless IPv6 address autoconfiguration. In case of stateless

address autoconfiguration however, the MS can choose any interface identifier to generate

addresses other than link-local, without involving the network. In particular, the SGSN and the

GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the

An IPv6 Mobile Station is performing stateless address autoconfiguration using a prefix

Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the

prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address

Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor

Solicitation messages that the MS may send to perform Duplicate Address Detection. It is

possible for the MS to perform Neighbor Unreachability Detection towards the GGSN, as defined

in RFC 2461[71]; therefore if the GGSN receives a Neighbor Solicitation as part of this

procedure, the GGSN shall provide a Neighbor Advertisement as described in RFC 2461.

An IPv6 Mobile Station is performing stateless address autoconfiguration using a prefix

The IPv6 Gateway GPRS Support NODE SHALL silently discard any Neighbor Solicitation messages

Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the

prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address

Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor

Solicitation messages that the MS may send to perform Duplicate Address Detection. .

An IPv6 Mobile Station has sent an "Activate PDP Context Request" to its Serving GPRS Support

The IPv6 Gateway GPRS Support Node SHALL NOT advertise the same prefix on more than one PDP

The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain

the same prefix as the one provided in step 2. A given prefix shall not be advertised on more

than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN

After the MS has received the Router Advertisement message, it constructs its full IPv6 address

by concatenating the interface identifier received in step 3, or a locally generated interface

identifier, and the prefix received in the Router Advertisement. If the Router Advertisement

contains more than one prefix option, the MS shall only consider the first one and silently

An IPv6 Mobile Station receives a Router Advertisement message which contains more than one

The IPv6 Mobile Station SHALL use the first prefix and silently discard the others.

The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain

the same prefix as the one provided in step 2. A given prefix shall not be advertised on more

than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN

After the MS has received the Router Advertisement message, it constructs its full IPv6 address

by concatenating the interface identifier received in step 3, or a locally generated interface

identifier, and the prefix received in the Router Advertisement. If the Router Advertisement

contains more than one prefix option, the MS shall only consider the first one and silently

An IPv6 Gateway GPRS Support Node shall automatically and periodically send Router

Advertisement messages towards the Mobile Station after a PDP context of type IPv6 is activated

IPv6 stateful address autoconfiguration uses the standard External PDN Address Allocation

procedure, as described in TS 29.061. The GGSN informs the MS that it shall perform stateful

address autoconfiguration by means of the Router Advertisements, as defined in RFC 2461. For

this purpose, the GGSN shall automatically and periodically send Router Advertisement messages

towards the MS after a PDP context of type IPv6 is activated. The use of stateless or stateful

A 3GPP User Equipment supporting IPv6 SHALL comply with the Basic IP group of specifications as

The set of IPv6 functionality a 3GPP UE will require is dependent on the services (IMS, Packet

As a minimum, a 3GPP UE shall comply with the Basic IP group of specifications as defined in

RFC3316. This IPv6 functionality is sufficient to provide compatibility towards IPv6 entities

A 3GPP UE shall follow the recommendations for the IP Security set of functions in RFC3316

According to the procedures defined in TS 23.060, when a UE is assigned an IPv6 prefix, it can

change the global IPv6 address it is currently using via the mechanism defined in RFC 3041, or

similar means, without updating the PS domain. Any application that requires full IP address

knowledge shall provide a mechanism to get the latest IPv6 address when the IPv6 address in the

Note: RFC3316 does not make any recommendations on preferred transition and interoperability

An IPv6 Mobile Station which is capable of both stateless and stateful autoconfiguration.

The IPv6 Mobile Station SHALL use stateless autoconfiguration to configure the address and

Stateful and Stateless Autoconfiguration may also co-exist. In that case, the MS shall use

Stateless to configure the address and Stateful to configure additional parameters only. The MS

shall not use Stateless and Stateful Address Autoconfiguration simultaneously since GPRS only

An IPv6 Mobile Station SHALL NOT use both stateless and stateful autoconfiguration

Stateful and Stateless Autoconfiguration may also co-exist. In that case, the MS shall use

Stateless to configure the address and Stateful to configure additional parameters only. The MS

shall not use Stateless and Stateful Address Autoconfiguration simultaneously since GPRS only

For MS, IPv6 Stateless Address Autoconfiguration is mandatory, and IPv6 Stateful Address

AN IPv6 Gateway GPRS Support Node MAY omit the randomisation of the period between sending

The handling of Router Advertisements shall be consistent with what is specified in RFC 2461

[44]. For the MS-GGSN link however, some specific handling shall apply. The randomisation part

to determine when Router Advertisements shall be sent may be omitted since the GGSN is the only

router on the link. Furthermore, some 3GPP specific protocol constants and default values shall

apply (see subclause "IPv6 Router Configuration Variables in the GGSN"). These relate to the

periodicity of the Router Advertisements initially and during continued operation. The

motivation for this is to have a faster user-plane set-up even in bad radio conditions and to

For MS, IPv6 Stateless Address Autoconfiguration is mandatory, and IPv6 Stateful Address

The default value of the configurable timer, MaxRtrAdvInterval in a 3GPP IPv6 router shall be

For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall

behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the

RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in

RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables

require particular attention in GPRS in order to preserve radio resources and MS power

consumption while still allowing for appropriate robustness and fast user-plane set-up time

even in bad radio conditions, or simply because they have a particular meaning in GPRS. These

particular variables are listed below with appropriate (default) values and shall be

configurable per APN. The values specified hereafter are specific to GPRS and supersede those

Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).

RFC 2461 also specifies a number of protocol constants. The following shall have specific

The default value of the configurable timer, MinRtrAdvInterval in a 3GPP IPv6 router SHALL be

For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall

behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the

RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in

RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables

require particular attention in GPRS in order to preserve radio resources and MS power

consumption while still allowing for appropriate robustness and fast user-plane set-up time

even in bad radio conditions, or simply because they have a particular meaning in GPRS. These

particular variables are listed below with appropriate (default) values and shall be

configurable per APN. The values specified hereafter are specific to GPRS and supersede those

Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).

RFC 2461 also specifies a number of protocol constants. The following shall have specific

The default value of the configurable timer, AdvValidLifetime in a 3GPP IPv6 router SHALL be

For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall

behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the

RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in

RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables

require particular attention in GPRS in order to preserve radio resources and MS power

consumption while still allowing for appropriate robustness and fast user-plane set-up time

even in bad radio conditions, or simply because they have a particular meaning in GPRS. These

particular variables are listed below with appropriate (default) values and shall be

configurable per APN. The values specified hereafter are specific to GPRS and supersede those

Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).

RFC 2461 also specifies a number of protocol constants. The following shall have specific