You are here: Home > Publications > RIPE Document Store > Requirements for IPv6 in ICT Equipment

Changes to Requirements for IPv6 in ICT Equipment

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted
ripe-554: Requirements ripe-501: Formulating requirements for IPv6 support can be done in ICT Equipment several ways. In this document we look at three different options.
delete: <p class="alert alert-warning"> delete: <span class="fa fa-info-circle"> delete: </span> Please note that some of the links on this document are now obsolete delete: </p> delete: <p> delete: <strong> Table of contents: delete: </strong> delete: </p> delete: <p> delete: </p> insert: <h2>

Contents insert: </h2>

delete: <p> delete: </p> insert: <hr noshade="noshade" size="1" />

delete: <a name="introduction"> insert: <a id="1" name="1"> 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 information and computer technology (ICT) equipment and support. This document is intended to provide a Best Current Common Practice (BCP) and does not specify any standards or policy itself. delete: </p> delete: <p> It can serve as a template that can be used by governments, governments or large enterprises and all other organisations when seeking IPv6 support in their tenders or equipment requirements and offer guidance on what specifications to ask for. developing tender documents. 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 independent of the RIPE community, 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. delete: </p> delete: <p> Some parts of Formulating requirements for IPv6 support can be done in several ways. In this section are document we look at three different options: insert: </p>

insert: <ol>
    insert: <li>
  1. 1.Option 1 is based loosely based on the insert: <a href="http://www.antd.nist.gov/usgv6/"> NIST/USGv6 profile developed by the US government: delete: <a href="#_ftn1"> [1] delete: </a> government insert: </a> .
    delete: <a href="http://www.antd.nist.gov/usgv6/" data-linktype="external" data-val="http://www.antd.nist.gov/usgv6/"> http://www.antd.nist.gov/usgv6/ delete: </a> delete: </p> delete: <p> The authors go6 expert council and the Slovenian IPv6 working group have modified these documents to make them more universally applicable. This option The new draft includes a list of RFC specification standards that which must be supported, divided into eight four categories of devices. delete: </p> delete: <p> insert: <br />
    insert: <br />
    insert: </li>
  2. insert: <li>
  3. 1.Option 2 is based on compliance with the “IPv6 Ready” program, as specified by the IPv6 Forum. This document also follows the IPv6 Node requirements document, RFC6434. This RFC program is the general IETF guidance on what parts of IPv6 need to be implemented by different devices. delete: </p> delete: <h3> delete: <a name="intro1"> delete: </a> General information on how to use this document delete: </h3> delete: <p> An IPv6 Ready Logo certificate can be required for any device. This divided into two phases: Phase 1 includes testing and certification of the basic "core" protocols, while Phase 2 includes testing and certification of advanced IPv6 functionality. insert: <br />
    insert: <br />
    insert: </li>
  4. insert: <li>
  5. 1.Option 3 is the easiest way for vendors providing the a combination of the first two approaches. insert: </li>
  6. insert: </ol>
insert: <h2>

Option 1 insert: </h2>

insert: <p>

Requirements are divided in equipment to prove and integrator support (output from go6 IPv6 WG). insert: </p>

insert: <p>

The following is the draft text that it fulfills basic IPv6 requirements. The tender initiator shall also provide the list of required mandatory and optional RFCs in order not to exclude vendors that did not yet put their equipment under IPv6 Ready Logo testing certifications. This way we propose be included in public tenders can't be accused of preferring any type or vendor of equipment. delete: </p> delete: <p> When we specify the list of required RFCs, we must list all mandatory requirements, except the entries that start with, “If [functionality] is requested…” These entries are mandatory only if the tender initiator requires certain functionality. Please note that the tender initiator should decide what functionality is required, not the equipment vendor. delete: </p> delete: <p> Certain features that are in the 'optional' section in this document might be important for your specific case and/or organisation. In such cases the tender initiator should move the requirement to the 'required' section in their tender request. delete: </p> delete: <h3> delete: <a name="intro2"> delete: </a> How to specify for ICT equipment, specifying requirements delete: </h3> delete: <p> As stated above, the IPv6 Ready Logo program does not cover all equipment that correctly supports IPv6; so declaring such equipment ineligible may not be desirable. 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 RFCs listed in the section below. delete: </p> delete: <p> About the IPv6 Ready Logo program: delete: <br /> delete: <a href="http://www.ipv6ready.org/"> http delete: </a> delete: <a href="http://www.ipv6ready.org/"> :// delete: </a> delete: <a href="http://www.ipv6ready.org/"> www delete: </a> delete: <a href="http://www.ipv6ready.org/"> . delete: </a> delete: <a href="http://www.ipv6ready.org/"> ipv delete: </a> delete: <a href="http://www.ipv6ready.org/"> 6 delete: </a> delete: <a href="http://www.ipv6ready.org/"> ready delete: </a> delete: <a href="http://www.ipv6ready.org/"> . delete: </a> delete: <a href="http://www.ipv6ready.org/"> org delete: </a> delete: <a href="http://www.ipv6ready.org/"> / delete: </a> delete: </p> delete: <p> Also note that there exists the BOUNDv6 project whose goal is to create a permanent multi-vendor network environment connecting approved laboratories where the community can test IPv6-enabled applications and devices in meaningful test scenarios. Tender initiators are encouraged to have a look and also use the results of this project. delete: </p> delete: <p> About BOUNDv6: delete: <br /> delete: <a href="http://www.boundv6.org/"> http delete: </a> delete: <a href="http://www.boundv6.org/"> :// delete: </a> delete: <a href="http://www.boundv6.org/"> www delete: </a> delete: <a href="http://www.boundv6.org/"> . delete: </a> delete: <a href="http://www.boundv6.org/"> boundv delete: </a> delete: <a href="http://www.boundv6.org/"> 6. delete: </a> delete: <a href="http://www.boundv6.org/"> org delete: </a> delete: <a href="http://www.boundv6.org/"> / delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> delete: <strong> Important note for tender initiator: delete: </strong> delete: </p> delete: <p> The IPv6 Ready Logo certification covers basic IPv6 requirements and some advanced features, but not all of them. If you require any advanced feature that is not covered by IPv6 Ready Logo certification, please request a list of RFCs that covers those specific needs in addition to IPv6 Logo Certification. In the lists below RFCs that are covered in the IPv6 Ready Logo certification are marked with *. delete: </p> delete: <h2> delete: <a name="proposed_generic_text"> delete: </a> Proposed generic text for the tender initiator delete: </h2> delete: <p> In every tender, following text shall be included: delete: </p> delete: <p> delete: </p> delete: <p> delete: <em> for IPv6 capability and support: insert: </p>

insert: <blockquote>
insert: <p>

insert: <i> All ICT hardware as subject of this tender must support both the IPv4 and IPv6 protocols. Similar performance must be provided for both protocols protocols. There should not be more than ...% difference in input, output and/or throughput data-flow performance, transmission and processing of packets. delete: </em> delete: </p> delete: <p> delete: </p> delete: <p> delete: <em> IPv6 support can be verified and certified by the IPv6 Ready Logo certificate. delete: </em> delete: </p> delete: <p> delete: </p> delete: <p> delete: <em> packets between the two protocols. insert: </i> insert: </p>

insert: <p>

insert: <i> (Notes for tender initiators: For high-end devices we recommend to state a maximum difference of 15%. For enterprise grade devices we recommend a maximum of 30%. For consumer grade devices we recommend a maximum of 40%.) insert: </i> insert: </p>

insert: <p>

insert: <i> Any software that communicates via the IP protocol must support both protocol versions (IPv4 and IPv6). The difference must not be noticeable to users. delete: </em> delete: </p> delete: <p> delete: </p> delete: <p> delete: <em> Equipment that has not been put through the IPv6 Ready testing procedures must comply with the RFCs listed below: delete: </em> delete: </p> delete: <p> delete: </p> delete: <p> delete: <em> [appropriate list of selected mandatory and optional RFCs from below lists] delete: </em> delete: </p> delete: <h2> delete: <a name="lists_of_mandatory_and_optional"> delete: </a> Lists of mandatory and optional RFC/3GPP technical specifications insert: </i> insert: </p>

insert: </blockquote>
insert: <h3>

Requirements for support for various hardware and software delete: </h2> delete: <p> Requirements are divided by hardware equipment and integrator support. delete: </p> delete: <p> delete: </p> delete: <p> It should be assumed that all IPv4 traffic will migrate to IPv6. All requirements placed on IPv4 traffic capabilities like latency, bandwidth and throughput should also be required for IPv6 traffic. delete: </p> delete: <h3> delete: <a name="ipsec"> delete: </a> IPsec: mandatory or optional of standards

delete: <p> In the original IPv6 Node Requirements (RFC4294) standard, IPsec was listed as a 'MUST' implement to be standards compliant. The updated RFC (RFC6434) changed IPsec to a 'SHOULD' implement. Reasons for the change are stated in this new RFC. delete: </p> delete: <p> The RIPE IPv6 Working Group has extensively discussed whether to make IPsec support mandatory or optional. The most vocal constituents showed support for moving IPsec to the optional sections, which is what is reflected in this document. delete: </p> delete: <p> While the consensus of the community was to make IPsec optional in most cases, the IETF have now stated that IPsec 'SHOULD' be implemented in the latest version of the IPv6 Node Requirements standard (RFC6434). In the IETF context, a SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. delete: </p> delete: <p> Organisations that use IPsec or expect to use it in the future should include the following in the mandatory section when initiating the tender: delete: <br /> • IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * delete: </p> delete: <h3> delete: <a name="devices"> delete: </a> Definitions and descriptions of different types of devices delete: </h3> delete: <p> The following definitions will be used for classifying the varying hardware equipment. While some hardware may have overlapping functionality (i.e., a Layer 2 switch can act as a Layer 3 router or a router may have some firewall capabilities), it is expected that for any overlapping functionality, the requirements for each specific device be combined. delete: </p> delete: <p> delete: <strong> delete: <em> Host: delete: </em> delete: </strong> A host is a network participant that sends and receives packets but does not forward them on behalf of others. delete: </p> delete: <p> delete: <strong> delete: <em> Switch, or ‘Layer 2 Switch': delete: </em> delete: </strong> A switch or ‘Layer 2 switch' is a device that is primarily used for forwarding Ethernet frames based on their attributes. Exchanging Ethernet information with other Ethernet switches is usually part of its function. delete: </p> delete: <p> delete: <strong> delete: <em> Router or ‘Layer 3 Switch': delete: </em> delete: </strong> A router or ‘Layer 3 switch' is a device that is primarily used for forwarding IP packets based on their attributes. Exchanging routing information with other Routers is usually part of its function. delete: </p> delete: <p> delete: <strong> delete: <em> Network Security Equipment: delete: </em> delete: </strong> Network security equipment is 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. delete: </p> delete: <p> delete: <strong> delete: <em> Customer Premise Equipment (CPE): delete: </em> delete: </strong> A CPE device is a small office or residential router that is used to connect home users and/or small offices in a myriad of configurations. Although a CPE is usually a Router, the requirements are different from an Enterprise/ISP Router Layer 3 switch. delete: </p> delete: <p> delete: <strong> delete: <em> Mobile Device delete: </em> delete: </strong> : In the context of this document, a mobile device is a node that connects to a 3GPP defined system using some 3GPP specified access technology (such as 2G, 3G, or LTE). For situations where the network logic is being provided solely by a dedicated device A connected to another device B, the specification will refer to device A and not to device B. If the protocol logic is distributed (e.g. a computer with an external Ethernet interface that performs TCP checksum offloading), the aggregate system is being referred to. delete: </p> delete: <p> delete: <strong> delete: <em> Load Balancer: delete: </em> delete: </strong> A load balancer is a networking device that distributes workload across multiple computers, servers or other resources, to achieve optimal or planned resource utilisation, maximise throughput, minimise response time, and avoid overload. delete: </p> delete: <p> delete: </p> delete: <p> The following references are of relevance to this BCP document. At the time of publication, the editions indicated were valid. All references are subject to revision; users of this BCP document are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below. delete: </p> delete: <h2> delete: <a name="lists_of_required_standards"> delete: </a> Lists of required RFC/3GPP standards for different types of hardware delete: </h2>

ICT hardware equipment is can be roughly divided into seven functional four groups:

  • Host: client or server
  • Layer 2 switch
  • Router or Layer layer 3 switch
  • Network Equipment to ensure network security equipment (firewalls, IDS, IPS...) delete: </li> delete: <li> CPE delete: </li> delete: <li> Mobile device delete: </li> delete: <li> Load balancer IPS, ...)

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.

insert: <blockquote>
insert: <p>

Please note that all RFC references are correct at the time of writing, but may be superseded by developments in the IETF. For all updates, please see: insert: <br />
insert: <a href="http://www.rfc-editor.org/"> http://www.rfc-editor.org/ insert: </a> insert: </p>

insert: </blockquote>
insert: <h3>

insert: <a id="hardware" name="hardware"> insert: </a> Hardware insert: </h3>

Any hardware that does not comply with delete: <strong> to all delete: </strong> of the mandatory standards should be is marked as inappropriate by the tender evaluator. delete: </p> delete: <p> The standards that are part of the IPv6 Ready Logo test procedures, typically performed by accredited labs, are marked with an asterisk *. inappropriate.

delete: <a name="requirements1"> insert: <a id="host" name="host"> Requirements for "host" equipment

insert: <b> Mandatory support: insert: </b>

  • IPv6 Basic specification [RFC2460] *
  • IPv6 Addressing Architecture basic [RFC4291] *
  • Default Address Selection [RFC3484]
  • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] delete: </li> delete: <li> ICMPv6 [RFC4443] *
  • DHCPv6 client [RFC3315] *
  • SLAAC [RFC4862] *
  • Path MTU Discovery [RFC1981] * delete: </li> delete: <li> Neighbor insert: </li>
  • insert: <li>
  • Neighbour Discovery [RFC4861] * delete: </li> delete: <li> If support for tunneling and dual stack is required, the device must support insert: </li>
  • insert: <li>
  • Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]
  • IPsec-v2 [RFC2401, RFC2406, RFC2402] insert: </li>
  • insert: <li>
  • IKE version 2 (IKEv2) [RFC4306, RFC4718] insert: </li>
  • insert: <li>
  • If support for mobile IPv6 is required, the device must support needs to comply to “MIPv6” [RFC6275, [RFC3775, RFC5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877]
  • DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
  • DNS message extension mechanism [RFC2671]
  • DNS message size requirements [RFC3226]
  • delete: <li> Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * delete: </li>

delete: </p> delete: <p> insert: <b> Optional support: insert: </b>

  • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] Revised ICMPv6 [RFC5095]
  • Extended ICMP for multi-part messages [RFC4884]
  • SeND SEND [RFC3971]
  • SLAAC Privacy Extensions [RFC4941]
  • Stateless DHCPv6 [RFC3736] *
  • DS (Traffic class) [RFC2474, RFC3140]
  • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] insert: </li>
  • insert: <li>
  • Cryptographically Generated Addresses [RFC3972]
  • IPsec/IKEv2 IPsec-v3 [RFC4301, RFC4303, RFC4302, RFC5996] * RFC4302]
  • SNMP protocol [RFC3411]
  • SNMP capabilities [RFC3412, RFC3413, RFC3414] delete: </li> delete: <li> SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
  • Multicast Listener Discovery version 2 [RFC3810] * delete: </li> delete: <li> Packetisation insert: </li>
  • insert: <li>
  • Packetization Layer Path MTU Discovery [RFC4821]
  • delete: <li> IPv6 Host-to-Router Load Sharing [RFC4311] delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] delete: </li>

delete: <a name="requirements2"> insert: <a id="layer2con" name="layer2con"> Requirements for consumer grade "Layer "layer 2 switch" equipment

insert: <b> Mandatory support: insert: </b> insert: </p>

insert: <ul>
    insert: <li>
  • MLDv2 snooping [RFC4541] insert: </li>
  • insert: </ul>
insert: <p>

Optional support (management)

  • MLDv2 snooping [RFC4541] delete: </li> delete: <li> IPv6 Basic specification [RFC2460] *
  • IPv6 Addressing Architecture basic [RFC4291] *
  • Default Address Selection [RFC3484]
  • ICMPv6 [RFC4443] *
  • SLAAC [RFC4862] *
  • SNMP protocol [RFC3411]
  • SNMP capabilities [RFC3412, RFC3413, RFC3414]
  • delete: <li> SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289] delete: </li>
delete: <p> delete: </p> delete: <p> delete: </p> delete: <p> delete: </p> delete: <p> delete: </p>

delete: <a name="requirements3"> insert: <a id="layer" name="layer2ent"> Requirements for enterprise/ISP grade "Layer "layer 2 switch" equipment

insert: <b> Mandatory support: insert: </b>

  • MLDv2 snooping [RFC4541]
  • DHCPv6 filtering snooping [RFC3315] insert: <br />
    DHCPv6 messages must be blocked between subscribers and the network so that false DHCPv6 servers cannot distribute addresses.
  • Router Advertisement (RA) filtering [RFC4862] [RFC4862, RFC5006] insert: <br />
    RA filtering must be used in the network to block unauthorised RA messages.
  • Dynamic "IPv6 Neighbor neighbour solicitation/advertisement" inspection [RFC4861] delete: </li> delete: <li> Neighbor [RFC4862] insert: <br />
    There must be an IPv6 neighbour solicitation/advertisement inspection, as in IPv4 "Dynamic ARP Inspection". The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages. insert: </li>
  • insert: <li>
  • Neighbour Unreachability Detection [NUD, RFC4861] filtering insert: <br />
    There must be a NUD filtering function to ensure that false NUD messages cannot be sent.
  • Duplicate Address Detection [DAD, RFC4429] snooping and filtering. delete: <a href="#_ftn2"> [2] delete: </a> filtering insert: <br />
    Only authorised addresses may be allowed as source IPv6 addresses in DAD messages from each port.

delete: </p> delete: <p> insert: <b> Optional support (management): (management) insert: </b>

  • IPv6 Basic specification [RFC2460] *
  • IPv6 Addressing Architecture basic [RFC4291] *
  • Default Address Selection [RFC3484]
  • ICMPv6 [RFC4443] *
  • SLAAC [RFC4862] *
  • SNMP protocol [RFC3411]
  • SNMP capabilities [RFC3412, RFC3413, RFC3414] delete: </li> delete: <li> SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
  • IPv6 Routing Header [RFC2460, Next Header value 43] filtering * delete: </li> delete: <li> snooping insert: </li>
  • insert: <li>
  • IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops [See also RFC5095, Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * IPv6]
  • UPnP filtering
  • insert: <li>
  • UPnP messages must always be blocked between customer ports. There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0×800 and 0×806 for IPv4. insert: </li>

delete: <a name="requirements4"> insert: <a id="layer2" name="layer3"> Requirements for "router or Layer layer 3 switch" equipment

insert: <b> Mandatory support: insert: </b>

  • IPv6 Basic specification [RFC2460] *
  • IPv6 Addressing Architecture basic [RFC4291] *
  • Default Address Selection [RFC3484]
  • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] delete: </li> delete: <li> ICMPv6 [RFC4443] *
  • SLAAC [RFC4862] *
  • MLDv2 snooping [RFC4541] delete: </li> delete: <li> Multicast Listener Discovery version 2 [RFC3810] *
  • Router-Alert option [RFC2711]
  • Path MTU Discovery [RFC1981] * delete: </li> delete: <li> Neighbor insert: </li>
  • insert: <li>
  • Neighbour Discovery [RFC4861] * delete: </li> delete: <li> Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * insert: </li>
  • insert: <li>
  • Classless Inter-domain routing [RFC4632]
  • If a dynamic interior gateway internal guidance protocol (IGP) is requested, then RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] 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" [RFC4552]
  • If BGP4 protocol is requested, the equipment must comply with RFC4271, RFC1772, RFC4760, RFC1997, RFC3392 and RFC2545
  • Support for QoS [RFC2474, RFC3140]
  • If support for tunneling and dual stack is required, the device must support Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]
  • If support for tunneling and dual stack is required, the device must support Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891] insert: </li>
  • insert: <li>
  • Generic Packet Tunneling and IPv6 [RFC2473]
  • If 6PE is requested, the equipment must support comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC4798]
  • Multicast Listener Discovery version 2 [RFC3810] insert: </li>
  • insert: <li>
  • If mobile IPv6 is requested, the equipment must support comply with MIPv6 [RFC6275, [RFC3775, RFC5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” Architecture" [RFC4877] delete: </li> delete: <li> 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)" [RFC5120]
  • 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)" [RFC4798] [RFC 4798]
  • If Layer 3 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" [RFC4659] [RFC 4659]
  • If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi-Topology Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC5120] [RFC 5120]

delete: </p> delete: <p> insert: <b> Optional support: support insert: </b>

  • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] Revised ICMPv6 [RFC5095]
  • DHCPv6 client/server/relay client / server [RFC3315] *
  • Extended ICMP for multi-part messages [RFC4884]
  • SeND SEND [RFC3971]
  • SLAAC Privacy Extensions [RFC4941]
  • Stateless DHCPv6 [RFC3736] *
  • DHCPv6 PD [RFC3633] *
  • Route Refresh for BGP-4 Capabilities BGP Capabilities-4 [RFC2918]
  • BGP Extended Communities Attribute [RFC4360]
  • (QOS) (QOS), Assured Forwarding [RFC2597]
  • (QOS) Expedited Forwarding [RFC3246]
  • Generic Routing Encapsulation [RFC2784]
  • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] insert: </li>
  • insert: <li>
  • Cryptographically Generated Addresses [RFC3972]
  • IPsec/IKEv2 ProSafe-v3 [RFC4301, RFC4303, RFC4302, RFC5996] * delete: </li> delete: <li> Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891] RFC4302] insert: </li>
  • insert: <li>
  • IPSec-v2 [RFC2401, RFC2406, RFC2402] insert: </li>
  • insert: <li>
  • IKE version 2 (IKEv2) [RFC4306, RFC4718]
  • SNMP protocol [RFC3411]
  • SNMP capabilities [RFC3412, RFC3413, RFC3414]
  • Mibsam SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] [RFC4292], IPsec [RFC4807] and DiffServ [RFC3289]
  • DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
  • DNS message extension mechanism [RFC2671]
  • DNS message size Requirements [RFC3226]
  • 127-bit IPv6 Prefixes on Inter-Router Links [RFC6164] delete: </li> delete: <li> Packetisation Links: insert: <br />
    insert: <a href="http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01"> http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01 insert: </a> insert: </li>
  • insert: <li>
  • Packetization Layer Path MTU Discovery [RFC4821]
  • IPv6 Host-to-Router Load Sharing [RFC4311] delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] When IS-IS routing protocol is requested, the equipment should support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (this support is highly recommended)

delete: <a name="requirements5"> insert: <a id="net-sec" name="net-sec"> Requirements for "network security equipment” security" equipment

Equipment in this section is divided into three subgroups:

  • Firewall (FW)
  • Intrusion prevention device (IPS) (IMS)
  • Application firewall (APFW)
delete: <p> delete: </p>

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

delete: </p> delete: <p> insert: <b> Mandatory support: insert: </b>

  • IPv6 Basic specification [RFC2460] (FW, IPS, APFW) *
  • IPv6 Addressing Architecture basic [RFC4291] (FW, IPS, APFW)
  • Default Address Selection [RFC3484] (FW, IPS, APFW)
  • ICMPv6 [RFC4443] (FW, IPS, APFW) *
  • SLAAC [RFC4862] (FW, IPS) * delete: </li> delete: <li> Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * delete: </li> delete: <li> Inspecting IPv6-in-IPv4 protocol-41 traffic, which is specified in: Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (IPS)
  • Router-Alert option [RFC2711] (FW, IPS)
  • Path MTU Discovery [RFC1981] (FW, IPS, APFW) * delete: </li> delete: <li> Neighbor APWF) insert: </li>
  • insert: <li>
  • Neighbour Discovery [RFC4861] (FW, IPS, APFW) *
  • If the request is for the BGP4 protocol, the equipment must comply with RFC4271, RFC1772, RFC4760 and RFC2545 (FW, IPS, APFW)
  • If the request is for a dynamic internal gateway guidance protocol (IGP), then the required RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. [RFC5308]. The contracting authority shall specify the required protocol. (FW, IPS, APFW)
  • If OSPF-v3 is requested, the requested OSPF-v3, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW)
  • Support for QoS [RFC2474, RFC3140] (FW, (FW APFW)
  • If tunneling is required, the device must support Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (FW)
  • insert: <li>
  • Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW) insert: </li>
delete: <p> delete: </p> delete: <p> 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. delete: </p> delete: <p> delete: </p>

Functionality and features that are supported over IPv4 should be comparable with the functionality 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 synchronising synchronizing IPv4 sessions between all members of a cluster, then this must also be possible with IPv6 sessions.

delete: </p> delete: <p> insert: <b> Optional support: support insert: </b>

  • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] Revised ICMPv6 [RFC5095]
  • DHCPv6 client/server/relay client / server [RFC3315] *
  • Extended ICMP for Multipart Messages [RFC4884]
  • SeND SEND [RFC3971]
  • SLAAC Privacy Extensions [RFC4941]
  • Stateless DHCPv6 [RFC3736] *
  • DHCPv6 PD [RFC3633] *
  • BGP Communities Attribute [RFC1997]
  • BGP Capabilities Advertisement WITH-4 [RFC3392]
  • (QOS) (QOS), Assured Forwarding [RFC2597]
  • (QOS) Expedited Forwarding [RFC3246]
  • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
  • Cryptographically Generated Addresses [RFC3972]
  • IPsec/IKEv2 IPsec-v3 [RFC4301, RFC4303, RFC4302, RFC5996] * delete: </li> delete: <li> Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW) RFC4302]
  • OSPF-v3 [RFC5340]
  • Authentication/Confidentiality Authentication / Confidentiality for OSPF-v3 [RFC4552]
  • Generic Packet Tunneling and IPv6 [RFC2473] insert: </li>
  • insert: <li>
  • IPsec-v2 [RFC2401, RFC2406, RFC2402] insert: </li>
  • insert: <li>
  • IKE version 2 (IKEv2) [RFC4306, RFC4718]
  • SNMP protocol [RFC3411]
  • SNMP capabilities [RFC3412, RFC3413, RFC3414]
  • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289] delete: </li> delete: <li> DNS protocol extensions to support IPv6 for incorporating IPv6 DNS resource records [RFC3596]
  • DNS message extension mechanism [RFC2671]
  • DNS message size requirements [RFC3226]
  • Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC4891]
  • Multicast Listener Discovery version 2 [RFC3810] *
  • MLDv2 snooping [RFC4541] (when in L2 or passthrough mode) * delete: </li> delete: <li> Packetisation insert: </li>
  • insert: <li>
  • Packetization Layer Path MTU Discovery [RFC4821]
  • delete: <li> IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739] delete: </li> delete: <li> IPv6 Host-to-Router Load Sharing [RFC4311] delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] delete: </li>

delete: <a name="requirements6"> insert: <br />
insert: <a id="net-sec2" name="software"> Requirements for CPE equipment IPv6 support in software

delete: <p> Mandatory support: delete: </p> delete: <ul> delete: <li> RFC6204 (Basic Requirements for IPv6 Customer Edge Routers) * delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> Optional support: delete: </p> delete: <ul> delete: <li> IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * delete: </li> delete: <li> If support for mobile IPv6 is required, the device needs to comply to “MIPv6” [RFC6275, RFC5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877] delete: </li> delete: <li> Extended ICMP for multi-part messages [RFC4884] delete: </li> delete: <li> SeND [RFC3971] delete: </li> delete: <li> SLAAC Privacy Extensions [RFC4941] delete: </li> delete: <li> DS (Traffic class) [RFC2474, RFC3140] delete: </li> delete: <li> Cryptographically Generated Addresses [RFC3972] delete: </li> delete: <li> SNMP protocol [RFC3411] delete: </li> delete: <li> SNMP capabilities [RFC3412, RFC3413, RFC3414] delete: </li> delete: <li> SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289] delete: </li> delete: <li> Multicast Listener Discovery version 2 [RFC3810] * delete: </li> delete: <li> Packetisation Layer Path MTU Discovery [RFC4821] delete: </li> delete: <li> IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] delete: </li> delete: <li> Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC6333] If support this then also must support Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [RFC6334] delete: </li> delete: <li> The A+P Approach to the IPv4 Address Shortage [RFC6346] delete: </li> delete: <li> IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739] delete: </li> delete: <li> IPv6 Host-to-Router Load Sharing [RFC4311] delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] delete: </li> delete: </ul> delete: <h3> delete: <a name="requirements7"> delete: </a> Requirements for mobile devices delete: </h3> delete: <p> Mandatory support: delete: </p> delete: <ul> delete: <li> IPv6 basic specification [RFC2460] * delete: </li> delete: <li> Neighbor Discovery for IPv6 [RFC4861] * delete: </li> delete: <li> IPv6 Stateless Address Autoconfiguration [RFC4862] * delete: </li> delete: <li> IPv6 Addressing Architecture [RFC4291] * delete: </li> delete: <li> ICMPv6 [RFC4443] * delete: </li> delete: <li> IPv6 over PPP [RFC2472] delete: </li> delete: <li> Multicast Listener Discovery version 2 [RFC3810] * delete: </li> delete: <li> IPv6 Router Alert Option [RFC2711] delete: </li> delete: <li> DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> Optional support: delete: </p> delete: <ul> delete: <li> Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC4941] delete: </li> delete: <li> Path MTU Discovery for IPv6 [RFC1981] * delete: </li> delete: <li> Generic Packet Tunneling for IPv6 [RFC2473] delete: </li> delete: <li> DHCPv6 [RFC3315] * delete: </li> delete: <li> Stateless DHCPv6 [RFC3736] delete: </li> delete: <li> DHCPv6 option for SIP servers [RFC3319] delete: </li> delete: <li> IPv6 Prefix Options for DHCPv6 [RFC3633] delete: </li> delete: <li> Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude] delete: </li> delete: <li> Default Address Selection [RFC3484] delete: </li> delete: <li> IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * delete: </li> delete: <li> IKEv2 Mobility and Multihoming Protocol MOBIKE [RFC 4555] delete: </li> delete: <li> IPv6 Host-to-Router Load Sharing [RFC4311] delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> References: delete: </p> delete: <ul> delete: <li> 3GPP delete: </li> delete: <li> Internetworking Between Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) [3GPP TS 29.061] delete: </li> delete: <li> GPRS Service Description [3GPP TS 23.060] delete: </li> delete: <li> General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access [3GPP TS 23.401] delete: </li> delete: <li> Signaling flows for IP multimedia Call control based on SIP and SDP [3GPP TS 24.228] delete: </li> delete: <li> IP multimedia call control protocol based on SIP and SDP [3GPP TS 24.229] delete: </li> delete: <li> IP Based Multimedia Framework [3GPP TS 22.941] delete: </li> delete: <li> Architectural Requirements [3GPP TS 23.221] delete: </li> delete: <li> Packet domain; Mobile Stations (MS) Supporting Packet Switching Service [3GPP TS 27.060] delete: </li> delete: <li> IPv6 migration guidelines [3GPP TR 23.975] delete: </li> delete: <li> IETF delete: </li> delete: <li> IPv6 for Some Second and Third Generation Cellular Hosts [RFC3316] delete: </li> delete: <li> Recommendations for IPv6 in 3GPP Standards [RFC3314] delete: </li> delete: <li> IPv6 in 3rd Generation Partnership Project (3GPP) [RFC6459] delete: </li> delete: </ul> delete: <h3> delete: <a name="requirements8"> delete: </a> Requirements for load balancers delete: </h3> delete: <p> 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: delete: </p> delete: <ul> delete: <li> Load balancing IPv6 clients to IPv6 servers (6-to-6) delete: <strong> must delete: </strong> be supported delete: </li> delete: <li> Load balancing IPv6 clients to IPv4 servers (6-to-4) delete: <strong> must delete: </strong> be supported delete: </li> delete: <li> Load balancing IPv4 clients to IPv4 servers (4-to-4) delete: <strong> should delete: </strong> be supported delete: </li> delete: <li> Load balancing IPv4 clients to IPv6 servers (4-to-6) delete: <strong> should delete: </strong> be supported delete: </li> delete: <li> Load balancing a single external/virtual IPv4 address to a mixed set of IPv4 and IPv6 servers delete: <strong> should delete: </strong> be supported delete: </li> delete: <li> Load balancing a single external/virtual IPv6 address to a mixed set of IPv4 and IPv6 servers delete: <strong> should delete: </strong> be supported delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> If a load balancer provides Layer 7 (application level / reverse proxy, defined as ‘surrogate' in section 2.2 of RFC3040) load balancing then support for the X-forwarded-for (or equivalent) header in HTTP delete: <strong> must delete: </strong> be provided in order to make the source IP address of the client visible to the servers. delete: </p> delete: <p> delete: </p> delete: <p> Mandatory support: delete: </p> delete: <ul> delete: <li> IPv6 Basic specification [RFC2460] * delete: </li> delete: <li> IPv6 Addressing Architecture [RFC4291] * delete: </li> delete: <li> Default Address Selection [RFC3484] delete: </li> delete: <li> Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] delete: </li> delete: <li> ICMPv6 [RFC4443] * delete: </li> delete: <li> Path MTU Discovery [RFC1981] * delete: </li> delete: <li> Neighbor Discovery [RFC4861] * delete: </li> delete: <li> DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] delete: </li> delete: <li> DNS message extension mechanism [RFC2671] delete: </li> delete: <li> DNS message size requirements [RFC3226] delete: </li> delete: <li> Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> Optional support: delete: </p> delete: <ul> delete: <li> IPv6 Router Advertisement Options for DNS Configuration [RFC6106] delete: </li> delete: <li> Extended ICMP for multi-part messages [RFC4884] delete: </li> delete: <li> SeND [RFC3971] delete: </li> delete: <li> DS (Traffic class) [RFC2474, RFC3140] delete: </li> delete: <li> Cryptographically Generated Addresses [RFC3972] delete: </li> delete: <li> SNMP protocol [RFC3411] delete: </li> delete: <li> SNMP capabilities [RFC3412, RFC3413, RFC3414] delete: </li> delete: <li> SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289] delete: </li> delete: <li> Multicast Listener Discovery version 2 [RFC3810] * delete: </li> delete: <li> Packetisation Layer Path MTU Discovery [RFC4821] delete: </li> delete: <li> NAT64/DNS64 [RFC6146, RFC6147] delete: </li> delete: <li> If support for IPsec is required, the device must support IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * and Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5685] delete: </li> delete: <li> If support for BGP4 is required, the equipment must comply with RFC4271, RFC1772, RFC4760 and RFC2545 delete: </li> delete: <li> If support for a dynamic internal gateway protocol (IGP) is required, the RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. The contracting authority shall specify the required protocol. delete: </li> delete: <li> If OSPF-v3 is requested, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW) delete: </li> delete: <li> IPv6 Host-to-Router Load Sharing [RFC4311] (FW) delete: </li> delete: <li> Default Router Preferences and More-Specific Routes [RFC4191] (FW) delete: </li> delete: </ul> delete: <p> delete: </p> delete: <h2> delete: </h2> delete: <h2> delete: <a name="requirements_ipv6_support"> delete: </a> Requirements for IPv6 support in software delete: </h2>

All software must support IPv4 and IPv6 and be able to communicate over IPv4-only, IPv6-only and dual-stack both types of 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 Functional differences must not be significantly different between IPv4 must also be available over and IPv6. The user should not experience any noticeable significant difference when software is communicating over IPv4 or IPv6, unless this is providing explicit benefit to the user. delete: </p> delete: <p> It is strongly recommended not to use any address literals in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC3484]. delete: </p> delete: <h2> delete: <a name="skill_requirements"> IPv6. insert: </p>

insert: <h3>

insert: <a id="net-sec3" name="skills"> Skill requirements of the systems integrator delete: </h2> insert: </h3>

Vendors and resellers reseller 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. These employees must also have certificates must indicate a general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security (as also indicated by the certification for these skills). security. 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 cancelled and become null and void.

The definition of proper integration, timing and degree of disruption of the network during the assembly shall be a matter of agreement between the client and systems integrator.

It is also recommended that a systems integrator and its employees have a broad knowledge of IPv6 and generic IPv6 certificates other than those specifically offered by the equipment manufacturers. These certificates can be obtained from independent education providers. Such knowledge may be awarded extra points in the tender process.

All bidders in the tender process must sign a declaration, the following form, which indicates that the company and its employees have passed technical training for design, construction and integration of ICT equipment in IPv4 and IPv6 networks. A sample of such a declaration is shown below. delete: </p> insert: </p>

insert: <hr noshade="noshade" size="1" />

insert: <a id="net-sec4" name="declaration"> insert: </a> DECLARATION

delete: <h3> delete: <a name="declaration"> delete: </a> insert: <p>

Declaration of IPv6 technical competence delete: </h3> delete: <p> Tender initiators should require technical IPv6 competence declaration from the for planning, building and integrating ICT equipment supplier or integrator. IPv6 knowledge and experience is required to assure proper installation and integration of IPv6 in the ICT environment. delete: </p> delete: <p> The declaration should say that the equipment supplier or system integrator declares in IPv4 and IPv6 networks and environments insert: </p>

insert: <p>

Company: ________________________________________ insert: </p>

insert: <p>

Address: ________________________________________ insert: </p>

insert: <p>

declares, under criminal and material responsibility:

delete: <p> delete: </p>
  • That they we have a sufficient number of people employed to perform offered services;
  • That those employees are professionally trained for their work - design, construction and integration of ICT equipment in both IPv4 and IPv6 networks and environments; environments
  • That the quality of offered services meets the requirements laid out in the tender documents, and documents. insert: </li>
  • insert: </ul>
insert: <p>

Place ____________________ insert: </p>

insert: <p>

Date ____________________ insert: <br />
insert: <br />
insert: </p>

insert: <p>

Stamp and signature of Systems Integrator insert: </p>

insert: <p>

insert: </p>

insert: <hr noshade="noshade" size="1" />
insert: <h2>

insert: <a id="2" name="2"> insert: </a> Option 2 insert: </h2>

insert: <p>

The tender initiator can require ICT equipment to be “Phase 1” or “Phase 2” certified under the “IPv6 Ready” program. Tests for both phases of certification can be done in five accredited laboratories around the world: TTA (Korea), BII (China), CHT-TL (Taiwan), IRISA (France) and UNH-IOL (US). These tests determine basic IPv6 protocols compliance (Phase 1, approximately 150 tests) and advanced IPv6 functionality (Phase 2, over 450 tests). insert: </p>

insert: <ul> insert: <p>

Any other requirements for the system integrator remain the same as in the first option. insert: </p>

insert: <h3>

insert: <a id="2text" name="2text"> insert: </a> Proposed text for the tender initiator: insert: </h3>

insert: <blockquote>
insert: <p>

insert: <i> ICT equipment that these requirements apply supports and communicates over the IPv4 protocol must also support the IPv6 protocol and be able to both communicate with other devices over IPv6. Basic IPv6 support must be verified and certified by the IPv6 Ready program with a “Phase 1” logo certificate. A “Phase 2” logo certificate will be awarded additional points (+10%) in the tender evaluation procedure. insert: </i> insert: </p>

insert: </blockquote>
insert: <h3>

Option 3 insert: </h3>

insert: <p>

The third option is a mix of the two alternatives outlined above. The IPv6 Ready program does not cover all equipment that correctly supports IPv6, so declaring such equipment ineligible may not be desirable. This option suggests that the tender initiator specify that eligible equipment may be either Phase 1 or Phase 2 certified under the IPv6 Ready program, or be compliant with the appropriate RFCs listed in Option 1. insert: </p>

insert: <h3>

insert: <a id="3text" name="3text"> insert: </a> Proposed text for the tender initiator: insert: </h3>

insert: <blockquote>
insert: <p>

insert: <i> ICT equipment that supports and communicates over the IPv4 and protocol must also support the IPv6 protocol and be able to communicate with other devices over IPv6. delete: </li> delete: </ul> delete: <p> delete: </p> delete: <p> Note Basic IPv6 support must be verified and certified by the IPv6 Ready program with a “Phase 1” logo certificate. A “Phase 2” logo certificate will be awarded additional points (+10%) in the tender evaluation procedure. insert: </i> insert: </p>

insert: <p>

insert: <i> Equipment that declarations like this can vary depending on local legislation. Therefore translators and tender initiators should get legal advice on the exact wording for these requirements. delete: </p> has not been put through the IPv6 Ready testing procedures must comply with the RFCs listed below: insert: </i> insert: </p>

insert: <p>

insert: <i> [appropriate list of selected mandatory and optional RFCs from Option 1] insert: </i> insert: </p>

insert: </blockquote>

delete: <a name="ack"> insert: <a id="ack" name="ack"> Acknowledgments

delete: <p> The first version of this document was done in the Go6 Expert Council and the Slovenian IPv6 working group. delete: </p>

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

delete: <p> The authors of this document would like to thank the RIPE IPv6 Working Group and its chairs for all of the support and encouragement to develop a follow-up version of the document. Special thanks goes to Ole Trøan, editor of RFC6204 for his help in the CPE section and for suggesting other changes across the document. Thanks to Marco Hogewoning, Ivan Pepelnjak and S.P. Zeidler for great input in ideas how to make the document structure and content better, Timothy Winters and Erica Johnson (both IPv6 Ready Logo committee, UNH) for help in marking RFCs they test and constructive suggestions. Thanks also to Yannis Nikolopoulos and Frits Nolet. Special thanks goes to Jouni Korhonen, Jari Arkko, Eric Vyncke, David Freedman, Tero Kivinen and Michael Richardson for some very useful comments and suggestions that made this document much better. delete: </p> delete: <p> Suggestions for improvement to this document and other comments can be sent to to the RIPE IPv6 Working Group mailing list < delete: <a href="mailto:ipv6-wg@ripe.net"> ipv6-wg@ripe.net delete: </a> >. delete: </p> delete: <p> delete: </p> delete: <hr align="left" size="1" width="33%" /> delete: <p> delete: <a href="#_ftnref1"> [1] delete: </a> The USGv6 specifications are currently undergoing an updated revision which is expected to be completed by early 2012 delete: </p> delete: <p> delete: <a href="#_ftnref2"> [2] delete: </a> 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. delete: </p>
Requirements for For IPv6 in ICT Equipment
RIPE Documents Search