1、 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 CatalogueETSI ETSI TS 102 514 V2.1.1 (2008-02) 2 Reference RTS/MTS-IPT-0032-IPv6-CrRqCa Keywords IP, IPv6, testing ETSI 650 Route des
2、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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from:
3、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 th
4、e 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
5、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
6、 and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade
7、 Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 514 V2.1.1 (2008-02) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Normative references .5 3 Abbreviations .6 4 Requirements Catalogue.6 4.1 Requiremen
8、ts extracted from TS 123 0606 4.2 Requirements extracted from TS 123 2218 4.3 Requirements extracted from TS 129 0618 4.4 Requirements extracted from RFC 198125 4.5 Requirements extracted from RFC 246029 4.6 Requirements extracted from RFC 246172 4.7 Requirements extracted from RFC 2462261 4.8 Requi
9、rements extracted from RFC 2463283 4.9 Requirements extracted from RFC 2464314 4.10 Requirements extracted from RFC 2675318 4.11 Requirements extracted from RFC 3513326 Annex A (informative): Duplicated requirements.355 Annex B (informative): Bibliography.357 History 358 ETSI ETSI TS 102 514 V2.1.1
10、(2008-02) 4 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: “Intellect
11、ual 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 investigat
12、ion, 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 Specificati
13、on (TS) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). ETSI ETSI TS 102 514 V2.1.1 (2008-02) 5 1 Scope 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 ETS
14、I Specifications. The catalogue follows the guidelines defined by the MTS IPv6 Testing: Methodology and Framework (see TS 102 351 in bibliography). 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific
15、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
16、; - 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 p
17、rimary 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 addre
18、ss, 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 a
19、pplication 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 IETF RFC 1122: “Requirements for Internet Hosts - Communication Layers“. 2 IETF RFC 1981: “Path M
20、TU Discovery for IP version 6“. 3 IETF RFC 2373: “IP Version 6 Addressing Architecture“. 4 IETF RFC 2402: “IP Authentication Header“. 5 IETF RFC 2460: “Internet Protocol, Version 6 (IPv6) Specification“. 6 IETF RFC 2461: “Neighbor Discovery for IP Version 6 (IPv6)“. 7 IETF RFC 2462: “IPv6 Stateless
21、Address Autoconfiguration“. 8 IETF RFC 2463: “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification“. 9 IETF RFC 2464: “Transmission of IPv6 Packets over Ethernet Networks“. 10 IETF RFC 2675: “IPv6 Jumbograms“. 11 IETF RFC 3513: “Internet Protocol Versio
22、n 6 (IPv6) Addressing Architecture“. ETSI ETSI TS 102 514 V2.1.1 (2008-02) 6 12 ETSI TS 123 060: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service description; Stage 2 (3GPP TS 23.060)“. 13 ETSI TS
23、123 221: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Architectural requirements (3GPP TS 23.221)“. 14 ETSI TS 123 228: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimed
24、ia Subsystem (IMS); Stage 2 (3GPP TS 23.228)“. 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) (3G
25、PP TS 29.061)“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: ICMP Internet Control Message Protocol IE Information Element MTU Maximum Transmission Unit ND Neighbor Discovery PDP Packet Data Protocol PMTU Path MTU TCP Transfer Control Protocol UDP User
26、 Datagram Protocol 4 Requirements Catalogue The requirements below have been extracted from IETF RFCs 1981 2, 2460 5, 2461 6, 2462 7, 2463 8, 2464 9, 2675 10, 351311) and ETSI specifications TS 123 060 12, TS 123 221 13, TS 123 228 14, TS 129 061 15). 4.1 Requirements extracted from TS 123 060 RQ_00
27、0_7003 Configure Address TS 123 060 9.2.1.1 MANDATORY Applies to: Host Context: An IPv6 Mobile Station is performing either stateless or stateful address autoconfiguration Requirement: An IPv6 Mobile Station SHALL use the interface identifier provided by the Gateway GPRS Support Node to configure it
28、s link-local address Specification Text: 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
29、-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 an
30、d the GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the PDP context. ETSI ETSI TS 102 514 V2.1.1 (2008-02) 7 RQ_000_7004 Detect Duplicate Address (DAD) TS 123 060 9.2.1.1 OPTIONAL Applies to: Host Context: An IPv6 Mobile Station is performing stateless a
31、ddress autoconfiguration using a prefix advertised by a Gateway BPRS Support Node in a PDP context. Requirement: The IPv6 Mobile Station MAY omit duplicate address detection. Specification Text: Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the prefix (i.
32、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 Unr
33、eachability Detection towards the GGSN, as defined in RFC 246171; 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. RQ_000_7005 Detect Duplicate Address (DAD) TS 123 060 9.2.1.1 MANDATORY Applie
34、s to: Router Context: An IPv6 Mobile Station is performing stateless address autoconfiguration using a prefix advertised by a Gateway BPRS Support Node in a PDP context. Requirement: The IPv6 Gateway GPRS Support NODE SHALL silently discard any Neighbor Solicitation messages sent by the IPv6 Mobile
35、Station. Specification Text: 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 Neighbo
36、r Solicitation messages that the MS may send to perform Duplicate Address Detection. . RQ_000_7006 Stateless Autoconfiguration TS 123 060 9.2.1.1 MANDATORY Applies to: Router Context: An IPv6 Mobile Station has sent an “Activate PDP Context Request“ to its Serving GPRS Support Node Requirement: The
37、IPv6 Gateway GPRS Support Node SHALL NOT advertise the same prefix on more than one PDP context on a given APN or set of APNs, within the same addressing scope. Specification Text: The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain the same prefix as the o
38、ne 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 shall be configured to advertise only one prefix per PDP context After the MS has received the Router Advertisement message, it constr
39、ucts 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 si
40、lently discard the others. RQ_000_7007 Stateless Autoconfiguration TS 123 060 9.2.1.1 MANDATORY Applies to: Host Context: An IPv6 Mobile Station receives a Router Advertisement message which contains more than one prefix. Requirement: The IPv6 Mobile Station SHALL use the first prefix and silently d
41、iscard the others. Specification Text: 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 add
42、ressing scope. The GGSN shall be configured to advertise only one prefix per PDP context ETSI ETSI TS 102 514 V2.1.1 (2008-02) 8 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
43、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 discard the others. RQ_000_7009 Startup Router Advertisement Behavior TS 123 060 9.2.1.1 MANDAT
44、ORY Applies to: Router Context: Requirement: 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 Specification Text: IPv6 stateful address autoconfiguration uses the standar
45、d 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 Advertis
46、ement messages towards the MS after a PDP context of type IPv6 is activated. The use of stateless or stateful address autoconfiguration is configured per APN. 4.2 Requirements extracted from TS 123 221 RQ_000_7010 3GPP UE supports IPv6 TS 123 221 5.6 MANDATORY Applies to: Host Context: Requirement:
47、A 3GPP User Equipment supporting IPv6 SHALL comply with the Basic IP group of specifications as defined in RFC3316. Specification Text: The set of IPv6 functionality a 3GPP UE will require is dependent on the services (IMS, Packet Streaming etc.) it will use. As a minimum, a 3GPP UE shall comply wit
48、h the Basic IP group of specifications as defined in RFC3316. This IPv6 functionality is sufficient to provide compatibility towards IPv6 entities external to 3GPP. A 3GPP UE shall follow the recommendations for the IP Security set of functions in RFC3316 when a specific service requires such functi
49、ons. 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 UE has been changed. An example of such means is defined in TS 23.228. Note: RFC3316 does not make any recommendations on preferred tran
