DRAFT: Requirements For IPv6 in ICT Equipment

Proposal authors: Merike Käo, Jan Žorž and Sander Steffann

Table of contents

Requirements For IPv6 in ICT Equipment

Introduction

To ensure the smooth and cost-efficient uptake of IPv6 across their networks, it is important that governments and large enterprises specify requirements for IPv6 compatibility when seeking tenders for Information and Communication Technology (ICT) equipment and support. This document is intended to provide a Best Current Practice (BCP) and does not specify any standards or policy itself.

It can serve as a template to be used by governments, large enterprises and other organisations when seeking IPv6 support in their tenders or equipment requirements, and can offer guidance on what specifications to ask for. It can also serve as an aid to those people or organisations interested in tendering for government or enterprise contracts.

Be aware that the standards listed here have their origin in various bodies, which operate independently, and that any of these standards might be changed or become replaced with a newer version. You may also need to adjust the recommendations to your specific local needs.

Some parts of this section are loosely based on the NIST/USGv6 profile developed by the US government:

http://www.antd.nist.gov/usgv6/

General Information on How to Use his Document

In this document we suggest two strategies for ensuring IPv6 readiness in tendered equipment and services. These two strategies should not be seen as exclusive, but rather complimentary. The first strategy is based on the IPv6 Ready Logo program, the second on a tailored set of requirements based on your specific situation and needs, and referencing specific IETF documents (Request For Comments or RFCs) or 3GPP standards.

The IPv6 Ready Logo Program

An IPv6 Ready Logo certificate can be obtained for any device that meets the relevant requirements. This is the easiest way for vendors to prove that their equipment fulfills basic IPv6 requirements.

About the IPv6 Ready Logo program:

http://www.ipv6ready.org/

Specific Requirements

Even if you rely on the IPv6 Ready Logo Program, however, a tender initiator should also provide a specific list of requirements, both mandatory and optional. This will mean that you do not exclude vendors that have not certified their equipment under the IPv6 Ready Logo Program, and avoid preferential treatment of specific equipment types or vendors in public tenders.

Requirements specified in this document are defined as either 'Mandatory' or 'Optional'. Some requirements are designated 'Mandatory' if a specific functionality is required. The tender initiator should decide what functionality is required, not the equipment vendor.

Depending on the specific needs of your organisation, you may wish to change requirements designated 'Optional' in this document to 'Mandatory' in your tender request.

How to Specify Requirements

As stated above, the IPv6 Ready Logo Program does not cover all equipment that correctly supports IPv6. This document recommends that the tender initiator specify that eligible equipment be either certified under the IPv6 Ready Program, or be compliant with the appropriate standards listed in the sections below.

The work of projects such as BOUNDv6 can also be an important resource. The goal of BOUNDv6 is to create a permanent multi-vendor network environment connecting approved laboratories for the purpose of testing IPv6-enabled applications and devices in meaningful test scenarios. Tender initiators may find the results useful in preparing their tender request documents.

About BOUNDv6:

http://www.boundv6.org/

Important note for tender initiator:

IPv6 Ready Logo certification covers basic IPv6 requirements and some advanced features, but not all of them. If you require an advanced feature not covered by IPv6 Ready Logo certification, you should specify a list of requirements to cover those specific needs in addition to IPv6 Logo certification.

In the sections below, standards already required under the IPv6 Ready Logo program are marked with an asterisk (*).

Proposed generic text for the tender initiator:

All ICT hardware as subject of this tender must support both the IPv4 and IPv6 protocols. Similar performance must be provided for both protocols in input, output and/or throughput data-flow performance, transmission and processing of packets.

IPv6 support can be verified and certified by the IPv6 Ready Logo certificate.

Any software that communicates via the IP protocol must support both protocol versions (IPv4 and IPv6). The difference must not be noticeable to users.

Equipment that has not been put through the IPv6 Ready testing procedures must comply with the requirements listed below:

[Select an appropriate list of selected mandatory and optional RFCs from the lists below]

Lists of Mandatory and Optional RFC /3GPP Standards Support for Various Hardware and Software

Requirements are divided between hardware equipment and integrator support.

It should be assumed that all IPv4 traffic will eventually migrate to IPv6. All requirements placed on IPv4 traffic capabilities, such as latency, bandwidth and throughput, should also be required for IPv6 traffic.

Definitions and Descriptions of Different Type of Devices

The following definitions will be used for classifying hardware equipment. While some hardware may have overlapping functionality (for instance, a layer-2 switch can act as a layer-3 router or a router may have some firewall capabilities), it is expected that in cases of overlapping functionality, the requirements for each specific device be combined.

Host: A host is a network participant that sends and receives packets but does not forward them on behalf of others.

Layer-2 switch: A layer-2 switch is a device that is primarily used for forwarding packets based on layer-2 attributes. Exchanging layer-2 information with other layer-2 switches is usually part of its function.

Router or layer-3 switch: A router or layer-3 switch is a device that is primarily used for forwarding packets based on layer-3 attributes. Exchanging routing information with other routers or layer-3 switches is usually part of its function.

Network security equipment: Network security equipment refers to devices whose primary function is to permit, deny and/or monitor traffic between interfaces in order to detect or prevent potential malicious activity. These interfaces can also include VPNs (SSL or IPsec). Network security equipment is often also a layer-2 switch or a router/layer-3 switch.

Customer Premises Equipment (CPE): A CPE device is a small office or residential router that is used to connect home users and/or small offices in various configurations. Although a CPE is usually a router, the requirements are different from an enterprise/ISP router/layer-3 switch.

Mobile node: In the context of this document a mobile node is a device that connects via some 3GPP specification (such as 3G, GPRS/UMTS or LTE). In situations where the network logic is being provided solely by a dedicated device (A) connected to another device (B), the specification refers to device A and not to device B. If the protocol logic is distributed (for example, a computer with an external Ethernet interface that performs TCP checksum offloading), the aggregate system is being referred to.

Load balancer: A networking device that distributes workload across multiple computers, servers or other resources, to achieve optimal resource utilisation, maximize throughput, minimize response time and avoid overload.

At the time of publication, all standards and documents listed below are valid; however, all references are subject to revision. Users of this document are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below.

Lists of Required RFC /3GPP Standards for Different Type of Hardware

ICT hardware equipment are divided into six groups:

• Host: client or server
• Layer-2 switch
• Router or layer-3 switch
• Network security equipment (firewalls, IDS, IPS, etc.)
• CPE
• Mobile node
• Load balancers

We have divided the following requirements into two categories, 'Mandatory' and 'Optional'. Equipment must meet the mandatory standards requirements list. Support for the optional requirements may earn the tender applicant additional points, if so specified by the tender initiator.

Any hardware that does not comply with all of the mandatory standards should be marked as inappropriate by the tender evaluator.

The standards that are part of the IPv6 Ready Logo test procedures, typically performed by accredited labs, are marked with an asterisk *.

Requirements for Host Equipment

Mandatory support:

• IPv6 basic specification [RFC 2460] *
• IPv6 Addressing Architecture basic [RFC 4291] *
• Default Address Selection [RFC 3484(bis)]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
• ICMPv6 [RFC 4443] *
• DHCPv6 client [RFC 3315] *
• SLAAC [RFC 4862] *
• Path MTU Discovery [RFC 1981] *
• Neighbor Discovery [RFC 4861] *
• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]
• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *
• If support for mobile IPv6 is required, the device must support “MIPv6” [RFC 3775, RFC 5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
• DNS message extension mechanism [RFC 2671]
• DNS message size requirements [RFC 3226]

Optional support:

• Revised ICMPv6 [RFC 5095] *
• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]
• Extended ICMP for multi-part messages [RFC 4884]
• SEND [RFC 3971]
• SLAAC Privacy Extensions [RFC 4941]
• Stateless DHCPv6 [RFC 3736] *
• DS (Traffic class) [RFC 2474, RFC 3140]
• Cryptographically Generated Addresses [RFC 3972]
• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• Multicast Listener Discovery version 2 [RFC 3810] *
• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for Consumer-grade Layer 2 Switch Equipment

Mandatory support:

• MLDv2 snooping [RFC 4541]

Optional support (management):

• IPv6 basic specification [RFC 2460] *
• IPv6 Addressing Architecture basic [RFC 4291] *
• Default Address Selection [RFC 3484(revise)]
• ICMPv6 [RFC 4443] *
• SLAAC [RFC 4862] *
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

Requirements for Enterprise/ISP-grade Layer-2 Switch Equipment

Mandatory support:

• MLDv2 snooping [RFC 4541]
• DHCPv6 filtering [RFC 3315]
• Router Advertisement (RA) filtering [RFC 4862]
• Dynamic "IPv6 Neighbor solicitation/advertisement" inspection [RFC 4861]
• Neighbor Unreachability Detection [NUD, RFC 4861] filtering
• Duplicate Address Detection [DAD, RFC 4429] snooping and filtering

Note that the IETF Source Address Validation Improvements (SAVI) working group is currently working on RFCs that specify a framework for source address validation. Once these RFCs are published, the NUD and DAD filtering references can be changed accordingly.

Optional support (management):

• IPv6 basic specification [RFC 2460] *
• IPv6 Addressing Architecture basic [RFC 4291] *
• Default Address Selection [RFC 3484(bis)]
• ICMPv6 [RFC 4443] *
• SLAAC [RFC 4862] *
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• IPv6 Routing Header [RFC 2460, Next Header value 43] filtering *
• Deprecation of Type 0 Routing Headers in IPv6 [RFC 5095]
• UPnP filtering

Requirements for Router or Layer-3 Switch Equipment

Mandatory support:

• IPv6 basic specification [RFC 2460] *
• IPv6 Addressing Architecture basic [RFC 4291] *
• Default Address Selection [RFC 3484(bis)]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
• ICMPv6 [RFC 4443] *
• SLAAC [RFC 4862] *
• MLDv2 snooping [RFC 4541]
• Router-Alert option [RFC 2711]
• Path MTU Discovery [RFC 1981] *
• Neighbor Discovery [RFC 4861] *
• Classless Inter-domain Routing [RFC 4632]
• If a dynamic interior gateway protocol (IGP) is requested, then RIPng [RFC 2080], OSPF-v3 [RFC 5340] or IS-IS [RFC 5308] must be supported. The contracting authority shall specify the required protocol.
• If OSPF-v3 is requested, the equipment must comply with "Authentication/Confidentiality for OSPF-v3" [RFC 4552]
• If BGP4 protocol is requested, the equipment must comply with RFC 4271, RFC 1772, RFC 4760, RFC 1997, RFC 3392 and RFC 2545
• Support for QoS [RFC 2474, RFC 3140]
• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]
• Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC 4891]
• Generic Packet Tunneling and IPv6 [RFC 2473]
• If 6PE is requested, the equipment must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC 4798]
• Multicast Listener Discovery version 2 [RFC 3810] *
• If mobile IPv6 is requested, the equipment must support MIPv6 [RFC 3775, RFC 5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]
• If the IS-IS routing protocol is requested the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]
• If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798]
• If layer-3 VPN functionality is requested, the PE-routers and route reflectors must support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659]
• If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]

Optional support:

• Revised ICMPv6 [RFC 5095] *
• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]
• DHCPv6 client / server [RFC 3315] *
• Extended ICMP for multi-part messages [RFC 4884]
• SEND [RFC 3971]
• SLAAC Privacy Extensions [RFC 4941]
• Stateless DHCPv6 [RFC 3736] *
• DHCPv6 PD [RFC 3633] *
• Route Refresh for BGP Capabilities-4 [RFC 2918]
• BGP Extended Communities Attribute [RFC 4360]
• (QOS), Assured Forwarding [RFC 2597]
• (QOS) Expedited Forwarding [RFC 3246]
• Generic Routing Encapsulation [RFC 2784]
• Cryptographically Generated Addresses [RFC 3972]
• ProSafe-v3 (IPSec-v3) [RFC 4301, RFC 4303, RFC 4302] *
• IPSec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409]
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• Mibsam SNMP for IP [RFC 4293] Forwarding [RFC 4292], IPsec [RFC 4807] and DiffServ [RFC 3289]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
• DNS message extension mechanism [RFC 2671]
• DNS message size Requirements [RFC 3226]
• 127-bit IPv6 Prefixes on Inter-Router Links [RFC 6164]
• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for Network Security Equipment

Equipment in this section is divided into three subgroups:

• Firewall (FW)
• Intrusion prevention device (IPS)
• Application firewall (APFW)

For each mandatory standard the applicable subgroups are specified in parentheses at the end of the line.

Mandatory support:

• IPv6 basic specification [RFC 2460] (FW, IPS, APFW) *
• IPv6 Addressing Architecture basic [RFC 4291] (FW, IPS, APFW)
• Default Address Selection [RFC 3484(bis)] (FW, IPS, APFW)
• ICMPv6 [RFC 4443] (FW, IPS, APFW) *
• SLAAC [RFC 4862] (FW, IPS) *
• Inspecting IPv6-in-IPv4 protocol-41 traffic, Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213] (FW, IPS)
• Router-Alert option [RFC 2711] (FW, IPS)
• Path MTU Discovery [RFC 1981] (FW, IPS, APFW) *
• Neighbor Discovery [RFC 4861] (FW, IPS, APFW) *
• Even if highly discouraged, if the request is for the BGP4 protocol, the equipment must comply with RFC 4271, RFC 1772, RFC 4760 and RFC 2545 (FW, IPS, APFW)
• If the request is for a dynamic internal gateway protocol (IGP), then the required RIPng [RFC 2080], OSPF-v3 [RFC 5340] or IS-IS [RFC 5308] must be supported. The contracting authority shall specify the required protocol. (FW, IPS, APFW)
• If the requested OSPF-v3, the device must support "Authentication/Confidentiality for OSPFv3" [RFC 4552] (FW, IPS, APFW)
• Support for QoS [RFC 2474, RFC 3140] (FW, APFW)
• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213] (FW)
• Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC 4891] (FW)

A network security device is often placed where a layer-2 switch or a router/layer-3 switch would otherwise be placed. Depending on this placement those requirements should be included.

Functionality and features that are supported over IPv4 should be comparable with the functionalities supported over IPv6. For example, if an intrusion prevention system is capable of operating over IPv4 in layer-2 and layer-3 mode, then it should also offer this functionality over IPv6. Or if a firewall is running in a cluster capable of synchronizing IPv4 sessions between all members of a cluster, then this must also be possible with IPv6 sessions.

Optional support

• Revised ICMPv6 [RFC 5095] *
• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]
• DHCPv6 client / server [RFC 3315] *
• Extended ICMP for Multipart Messages [RFC 4884]
• SEND [RFC 3971]
• SLAAC Privacy Extensions [RFC 4941]
• Stateless DHCPv6 [RFC 3736] *
• DHCPv6 PD [RFC 3633] *
• BGP Communities Attribute [RFC 1997]
• BGP Capabilities Advertisement WITH-4 [RFC 3392]
• (QOS), Assured Forwarding [RFC 2597]
• (QOS) Expedited Forwarding [RFC 3246]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
• Cryptographically Generated Addresses [RFC 3972]
• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *
• OSPF-v3 [RFC 5340]
• Authentication / Confidentiality for OSPF-v3 [RFC 4552]
• Generic Packet Tunneling and IPv6 [RFC 2473]
• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409]
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• DNS protocol extensions for incorporating IPv6 DNS resource records INTO [RFC 3596]
• DNS message extension mechanism [RFC 2671]
• DNS message size requirements [RFC 3226]
• Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC 4891]
• Multicast Listener Discovery version 2 [RFC 3810] *
• MLDv2 snooping [RFC 4541] (when in L2 or passthrough mode) *
• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for CPE Equipment

Mandatory support:

• RFC 6204 (Basic Requirements for IPv6 Customer Edge Routers) *
• If this specification is used for business class CPE, then IPsec-v2 [RFC 2401, RFC 2406, RFC 2402], IKE version 2 (IKEv2) [RFC 4306, RFC 4718] and ISAKMP [RFC 2407, RFC 2408, RFC 2409] must be supported in addition to RFC 6204 requirements

Optional support:

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409]
• If support for mobile IPv6 is required, the device needs to comply to “MIPv6” [RFC 3775, RFC 5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]
• Revised ICMPv6 [RFC 5095] *
• Extended ICMP for multi-part messages [RFC 4884]
• SEND [RFC 3971]
• SLAAC Privacy Extensions [RFC 4941]
• DS (Traffic class) [RFC 2474, RFC 3140]
• Cryptographically Generated Addresses [RFC 3972]
• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• Multicast Listener Discovery version 2 [RFC 3810] *
• Packetization Layer Path MTU Discovery [RFC 4821]
• IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC 5969]
• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC 6333] If support this then also must support Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [RFC 6334]
• The A+P Approach to the IPv4 Address Shortage [I-D.ymbk-aplusp]

Requirements for Mobile Nodes

Mandatory support:

• IPv6 basic specification [RFC 2460] *
• IPv6 Node Requirements [RFC 4294] (errata for RFC 2460)
• Neighbor Discovery for IPv6 [RFC 4861] (obsoletes RFC 2461) *
• IPv6 Stateless Address Autoconfiguration [RFC 4862] (obsoletes RFC 2462) *
• IPv6 Addressing Architecture basic [RFC 4291] *
• ICMPv6 [RFC 4443] *
• IPv6 over PPP [RFC 2472]
• Multicast Listener Discovery [RFC 2710]
• IPv6 Router Alert Option [RFC 2711]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *

Optional support:

• Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 4941]
• Privacy Extensions for Address Configuration in IPv6 [RFC 3041]
• Path MTU Discovery for IPv6 [RFC 1981] *
• Generic Packet Tunneling for IPv6 [RFC 2473]
• DHCPv6 [RFC 3315] *
• DHCPv6 option for SIP servers [RFC 3319]
• Default Address Selection [RFC 3484(bis)]

References:

3GPP

• Internetworking Between Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) [3GPP TS 29.061]
• GPRS Service Description [3GPP TS 23.060]
• Signalling flows for IP multimedia Call control based on SIP and SDP [3GPP TS 24.228]
• IP multimedia call control protocol based on SIP and SDP [3GPP TS 24.229]
• IP Based Multimedia Framework [3GPP TS 22.941]
• Architectural Requirements [3GPP TS 23.221]
• Packet domain; Mobile Stations (MS) Supporting Packet Switching Service [3GPP TS 27.060]
• IPv6 migration guidelines [3GPP TR 23.975]

3GPP2

• IP Network Architecture Model for cdma2000 Spread Spectrum Systems [3GPP2 S.R0037-0]
• Wireless IP Network Standard [3GPP2 P.S0001-B]

IETF

• IPv6 for Some Second and Third Generation Cellular Hosts [RFC 3316]
• Recommendations for IPv6 in 3GPP Standards [RFC 3314]

Requirements for Load Balancers

A load balancer distributes incoming requests and/or connections from clients to multiple servers. Load balancers will have to support several combinations of IPv4 and IPv6 connections:

• Load balancing IPv6 clients to IPv6 servers (6-to-6) must be supported
• Load balancing IPv6 clients to IPv4 servers (6-to-4) must be supported
• Load balancing IPv4 clients to IPv4 servers (4-to-4) should be supported
• Load balancing IPv4 clients to IPv6 servers (4-to-6) should be supported
• Load balancing a single external/virtual IPv4 address to a mixed set of IPv4 and IPv6 servers should be supported
• Load balancing a single external/virtual IPv6 address to a mixed set of IPv4 and IPv6 servers should be supported

If a load balancer provides layer-7 (application level / reverse proxy, defined as ‘surrogate' in section 2.2 of RFC 3040) load balancing then support for the X-forwarded-for (or equivalent) header in HTTP must be provided in order to make the source IP address of the client visible to the servers.

Mandatory support:

• IPv6 basic specification [RFC 2460] *
• IPv6 Addressing Architecture basic [RFC 4291] *
• Default Address Selection [RFC 3484(bis)]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
• ICMPv6 [RFC 4443] *
• Path MTU Discovery [RFC 1981] *
• Neighbor Discovery [RFC 4861] *
• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
• DNS message extension mechanism [RFC 2671]
• DNS message size requirements [RFC 3226]

Optional support:

• Revised ICMPv6 [RFC 5095] *
• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]
• Extended ICMP for multi-part messages [RFC 4884]
• SEND [RFC 3971]
• DS (Traffic class) [RFC 2474, RFC 3140]
• Cryptographically Generated Addresses [RFC 3972]
• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *
• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *
• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *
• SNMP protocol [RFC 3411]
• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]
• Multicast Listener Discovery version 2 [RFC 3810] *
• Packetization Layer Path MTU Discovery [RFC 4821]
• NAT64/DNS64 [RFC 6146, RFC 6147]

Requirements for IPv6 Support in Software

All software must support IPv4 and IPv6 and be able to communicate over IPv4-only, IPv6-only and dual-stack networks. If software includes network parameters in its local or remote server settings, it should also support configuration of IPv6 parameters.

All features that are offered over IPv4 must also be available over IPv6. The user should not experience any noticeable difference when software is communicating over IPv4 or IPv6, unless this is providing explicit benefit to the user.

It is not recommended that any address literals be used in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC 3484].

Skill Requirements of the Systems Integrator

Vendors and resellers that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. Additionally, these employees should have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security, as indicated by certification from independent education providers (not simply the equipment manufacturers). Such knowledge may be awarded extra points in the tender process.

If it becomes obvious during the equipment installation and integration that the integrator's knowledge, competence and experience is not sufficient to successfully install and configure the equipment to establish normal IPv4 and IPv6 communication with the network, the agreement shall be canceled and become null and void. The definition of proper integration, timing and degree of disruption of the network during the assembly should be a matter of agreement between the client and systems integrator.

Declaration of IPv6 Competence

Tender initiators should require a declaration of technical IPv6 competence from the equipment supplier or integrator. IPv6 knowledge and experience is required to assure proper installation and integration of IPv6 in the ICT environment.

This declaration should state:

• That the equipment supplier or system integrator have a sufficient number of people employed to perform the offered services;
• That those employees are professionally trained for their work (including design, construction and integration of ICT equipment in both IPv4 and IPv6 networks and environments);
• That the quality of offered services meets the requirements laid out in the tender documents, in relation to both IPv4 and IPv6.

The ability to legally enforce such declarations will vary depending on local legislation. Therefore translators and tender initiators should get legal advise on the exact wording for these requirements.

Additional Information: Working With Your ISP

This document specifies how to request IPv6 functionality and compliance when buying ICT equipment, but equipment itself, even if installed and implemented correctly, is not enough. You still need to communicate with the Internet, which usually means connecting to one or multiple Internet Service Providers (ISPs).

To ensure that your ISP(s) offers you the appropriate level of IPv6 service, we suggest asking them the following questions, compiled specifically for enterprise and very large customers:
http://go6.si/service-provider-ipv6/

Acknowledgments

The initial version of this document was prepared by the Go6 Expert Council and the Slovenian IPv6 Working Group.

The authors would like to thank all involved in creation and modification of previous versions of this document. First of all we would like to thank Janez Sterle, Urban Kunc, Matjaz Straus, Simeon Lisec, Davor Sostaric and Matjaz Lenassi from the Go6 Expert Council for their enthusiastic governance of this document. We recognise the work done in the Slovenian IPv6 Working Group for their review and useful input; special recognition goes to Ivan Pepelnjak, Andrej Kobal and Ragnar Us for their efforts and work done on the document. Thanks also to the Co-chairs of RIPE IPv6 Working Group, David Kessens, Shane Kerr and Marco Hogewoning, for their support and encouragement. We would also like to thank Patrik Fältström, Torbjörn Eklöv, Randy Bush, Matsuzaki Yoshinobu, Ides Vanneuville, Olaf Maennel, Ole Trøan, Teemu Savolainen and participants in the RIPE IPv6 Working Group (Joao Damas, S.P.Zeidler, Gert Döring and others) for their input, comments and review of the document. Last, but not least we would like to thank Chris Buckridge from RIPE NCC for correcting our grammar and wording in this document. And everybody else that contributed to this work.

The authors of this current document would like to thank RIPE IPv6 WG and its Co-chairs for all support end encouragement in developing a collow-up version of the document. Special thanks goes to Ole Trøan, editor of RFC 6204 for his help in the CPE section and also suggesting other changes across the document. Thanks to Marco Hogewoning, Ivan Pepelnjak and S.P. Zeidler for great input in ideas how to improve the document's structure and content, Timothy Winters and Erica Johnson (both IPv6 Ready Logo committee, UNH) for help with marking the RFCs on which they base their tests and constructive suggestions. Thanks also to Yannis Nikolopoulos and Frits Nolet.