1、 ETSI TS 102 599 V1.1.1 (2007-09)Technical Specification Methods for Testing and Specification (MTS);Internet Protocol Testing (IPT): IPv4 to IPV6 Transitioning;Requirements CatalogueETSI ETSI TS 102 599 V1.1.1 (2007-09) 2 Reference DTS/MTS-IPT-018-IPv6-TrsReqCat Keywords IP, IPv6, testing ETSI 650
2、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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloa
3、ded 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 s
4、hall 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 ava
5、ilable 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
6、 copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2007. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks curre
7、ntly being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 599 V1.1.1 (2007-09) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Norma
8、tive references .5 3 Abbreviations .6 4 Requirements catalogue .6 Requirements extracted from RFC 2529.7 Requirements extracted from RFC 2765.17 Requirements extracted from RFC 2766.110 Requirements extracted from RFC 3056.136 Requirements extracted from RFC 3596.151 Requirements extracted from RFC
9、4213.154 Requirements extracted from RFC 4214.186 History 192 ETSI ETSI TS 102 599 V1.1.1 (2007-09) 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 a
10、vailable 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 s
11、erver (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
12、 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 ETSI TS 102 599 V1.1.1 (2007-09) 5 1 Scope The present document is a catalogue of all of the IPv4 to IPv6
13、transitioning-related requirements extracted from the following IETF specifications: RFC 2529 1: “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels“. RFC 2765 2: “Stateless IP/ICMP Translation Algorithm (SIIT)“. RFC 2766 3: “Network Address Translation - Protocol Translation (NAT-PT)“.
14、 RFC 2893 4: “Transition Mechanisms for IPv6 Hosts and Routers“. RFC 3056 5: “Connection of IPv6 Domains via IPv4 Clouds“. RFC 3596 6: “DNS Extensions to Support IP Version 6“. RFC 4213 7: “Basic Transition Mechanisms for IPv6 Hosts and Routers“. RFC 4214 8: “Intra-Site Automatic Tunnel Addressing P
15、rotocol (ISATAP)“. 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 an
16、d 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
17、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
18、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 we
19、re 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
20、 edition of the referenced document (including any amendments) applies. 1 IETF RFC 2529: “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels“. 2 IETF RFC 2765: “Stateless IP/ICMP Translation Algorithm (SIIT)“. 3 IETF RFC 2766: “Network Address Translation - Protocol Translation (NAT-PT)
21、“. 4 IETF RFC 2893: “Transition Mechanisms for IPv6 Hosts and Routers“. ETSI ETSI TS 102 599 V1.1.1 (2007-09) 6 5 IETF RFC 3056: “Connection of IPv6 Domains via IPv4 Clouds“. 6 IETF RFC 3596: “DNS Extensions to Support IP Version 6“. 7 IETF RFC 4213: “Basic Transition Mechanisms for IPv6 Hosts and R
22、outers“. 8 IETF RFC 4214: “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: DNS Domain Name System IANA Internet Assigned Number Association ICMP Internet Control Message Protocol IETF Internet Eng
23、ineering Task Force IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 NAT Network Address Translation PMTU Path Maximum Transmission Unit RFC Request For Comments (IETF terminology for a draft standard) SIIT Stateless IP/ICMP Translation algorithm TCP Transport C
24、ontrol Protocol UDP User Datagram Protocol 4 Requirements catalogue The requirements related to the transitioning from the Internet Protocol version 4 (IPv4) to the Internet Protocol version 6 (IPv6) are specified in a number of IETF documents. These documents include the basic transition mechanisms
25、 for IPv6 hosts and routers 7 as well as requirements for transitioning without the use of explicit tunnels 1, the use of the Stateless IP/ICMP Translation algorithm (SIIT) 2, protocol translation as part of NAT 3, transitioning mechanisms for IPv6 Hosts and Routers 4, connecting IPv6 domains throug
26、h IPv4 networks 5, extension to DNS to support IPv6 6 and the use of Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 8. The present document is a catalogue of all of the normative requirements from these security specifications. Each requirement is given a unique identifier (e.g. RQ_003_123
27、4) and the following information is included with each: the clause number in the RFC from which the requirement has been extracted; the type of requirement (Mandatory, Optional or Recommended); the type of device to which the requirement applies (for example, Host or Router); the actual text from wh
28、ich the requirement was extracted. ETSI ETSI TS 102 599 V1.1.1 (2007-09) 7 Requirements extracted from RFC 2529 - Identifier: RQ_003_1001 RFC Clause: 2 Type: Optional Applies to: Node Requirement: The default MTU size for IPv6 packets on an IPv4 domain of 1480 octets may be varied by a Router Advert
29、isement containing an MTU option which specifies a different MTU. Specification Text: The default MTU size for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied by a Router Advertisement DISC containing an MTU option which specifies a different MTU, or by manual configuration of
30、 each node. Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not disastrous. However, the IPv4 “do not fragment“ bit MUST NOT be set in the encapsulating IPv4 header. - Identifier: RQ_003_1002
31、 RFC Clause: 2 Type: Optional Applies to: Node Requirement: The default MTU size for IPv6 packets on an IPv4 domain of 1480 octets may be varied by manual configuration of each node. Specification Text: The default MTU size for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied b
32、y a Router Advertisement DISC containing an MTU option which specifies a different MTU, or by manual configuration of each node. Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not disastrous
33、. However, the IPv4 “do not fragment“ bit MUST NOT be set in the encapsulating IPv4 header. - Identifier: RQ_003_1003 RFC Clause: 2 Type: Mandatory Applies to: Node Requirement: The IPv4 “do not fragment“ bit MUST NOT be set in the encapsulating IPv4 header. Specification Text: The default MTU size
34、for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied by a Router Advertisement DISC containing an MTU option which specifies a different MTU, or by manual configuration of each node. Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subn
35、et, IPv4 fragmentation will ensue. While undesirable, this is not disastrous. However, the IPv4 “do not fragment“ bit MUST NOT be set in the encapsulating IPv4 header. ETSI ETSI TS 102 599 V1.1.1 (2007-09) 8 - Identifier: RQ_003_1004 RFC Clause: 3 Type: Mandatory Applies to: Node Requirement: IPv6 p
36、ackets SHALL BE transmitted in IPv4 packets with an IPv4 protocol type of 41, Specification Text: IPv6 packets are transmitted in IPv4 packets RFC 791 with an IPv4 protocol type of 41, the same as has been assigned in RFC 1933 for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header
37、 contains the Destination and Source IPv4 addresses. The IPv4 packet body contains the IPv6 header followed immediately by the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Ser
38、vice| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol 41 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
39、-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 header and payload
40、. / +-+-+-+-+-+-+-+ - Identifier: RQ_003_1005 RFC Clause: 3 Type: Recommendation Applies to: Node Requirement: If there are IPv4 options in the IPv4 header, then padding SHOULD be added to the IPv4 header such that the IPv6 header starts on a boundary that is a 32- bit offset from the end of the dat
41、alink header. Specification Text: If there are IPv4 options, then padding SHOULD be added to the IPv4 header such that the IPv6 header starts on a boundary that is a 32- bit offset from the end of the datalink header. - Identifier: RQ_003_1006 RFC Clause: 3 Type: Recommendation Applies to: Node Requ
42、irement: The Time to Live field of the IPv4 header SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. Specification Text: The Time to Live field SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be
43、 a configurable parameter, with a recommended default of 8. ETSI ETSI TS 102 599 V1.1.1 (2007-09) 9 - Identifier: RQ_003_1007 RFC Clause: 3 Type: Mandatory Applies to: Node Requirement: The Time to Live field of the IPv4 header MUST be a configurable parameter. Specification Text: The Time to Live f
44、ield SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be a configurable parameter, with a recommended default of 8. - Identifier: RQ_003_1008 RFC Clause: 3 Type: Recommendation Applies to: Node Requirement: The Time to Live field of the IPv4
45、header has a recommended default of 8. Specification Text: The Time to Live field SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be a configurable parameter, with a recommended default of 8. - Identifier: RQ_003_1009 RFC Clause: 4 Type: Man
46、datory Applies to: Router Requirement: The Interface Identifier of an IPv4 interface is the 32-bit IPv4 address of that interface, with the octets in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Specification Text: Th
47、e Interface Identifier AARCH of an IPv4 interface is the 32-bit IPv4 address of that interface, with the octets in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the “Universal/ Local“ bit is zero, indicating
48、that the Interface Identifer is not globally unique. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made. - Identifier: RQ_003_1010 RFC Clause: 4 Type: Mandatory Applies to: Router Requirement: The “Universal/ Local“ bit in an Interface Identifier of an IPv4 interface is zero. Specification Text: The Interface Identifier AARCH of an IPv4 interface is the 32-bit IPv4 address of that interfa
