IPv6 - CNlabs
blog

IPv6 Standardization and Compliance – I

Background

The first proposed standard for Internet Protocol Version 6 was introduced as part of RFC 1883, in December 1995. Back then, it was popularly referred to as Internet Protocol Next Generation or simply IPng. This proposed standard was a result of discussions and suggested improvements on The Recommendation for the IP Next Generation Protocol captured as part of RFC 1752, which was accepted by the Internet Engineering Steering Group (IESG).

The need was clear — to address billions of hosts on millions of networks, without creating additional overheads in the networks. Although the 32-bit addressing structure (IPv4) could theoretically enumerate 4 billion hosts, the actual number of addresses was far too limited, and the inefficiency was aggravated by using class-based addressing. After several spirited discussions on using CIDR as a measure and after rejecting a proposal for “IP Version 7” from IAB, the IETF formed several working groups to refocus attention on IPng. A whitepaper on IPng was solicited (RFC 1550) and was answered by RFC 1710 — Simple Internet Protocol Plus (SIPP), which first presented the idea of extended addresses — 128-bit, 192-bit or even larger, while maintaining the addresses in manageable 64-bit units. The SIPP spec (128-bit) was one of the “Specific recommendations” included in the RFC 1752, which also used the term IPv6 for the first time, as version number 6 was designated to IPng by IANA.

Based on the recommendations of RFC 1752, RFC 1883 defined the IPv6 Header format and various extension headers while addressing core issues related to packet sizes and upper-layer protocols. Subsequently, the draft standard for IPv6 Specification — RFC 2460 (December 1998) was introduced. RFC 2460 obsoleted RFC 1883 and defined the basic structure of an IPv6 packet along with traffic classes. It also covered potential issues which were not addressed in RFC 1883. For almost two decades, RFC 2460 became the de-facto standard for IPv6 Specification, until the introduction of RFC 8200 (July 2017). As the usage of IPv6 evolved and a greater number of IPv6 networks were deployed in the industry, more standards were created for seamless interoperability. Today, more than a hundred RFCs exist for IPv6.

The IPv6 Header Format

Image for post

Using dual-stacking and tunnelling techniques the transition from IPv4 to IPv6 has largely been smooth for nearly two decades. However, with IoT making its way into the tiniest of devices using technologies such as 6LoWPAN and Zigbee, the use of IPv6-only addresses is more prevalent than ever. It is also fitting, in the sense that IPv6 was created for this purpose — to enumerate a large number of devices on the internet.

Compliance to IPv6 Standards

With more than a hundred standards for IPv6, it becomes complex for the OEMs and product vendors to have strict compliance with all the RFCs. In short, how do they identify the primary RFCs their devices need to be compliant with, to say the device is IPv6 “ready” or IPv6 “enabled”? Will these RFCs be enough to claim compliance with industry standards and regulatory requirements? The compliance teams of OEMs are often posed with these questions.

The IPv6 Forum, a worldwide consortium of leading service providers, international ISPs and research & educational networks, provides IPv6-enabled certification programs for websites and service providers. The forum’s IPv6 Ready Logo certification program aims at increasing user confidence by demonstrating that products are IPv6 ready. The certification, consisting of Conformance and Interoperability testing, aims to validate a device’s compliance with the latest IPv6 RFCs. To facilitate product vendors to identify the primary IPv6 RFCs a device should be compliant to, it offers a certification program for IPv6 Core Protocols — covering the 5 primary IPv6 RFCs viz. RFC 8200 (IPv6 Specification), RFC 4861 (Neighbor Discovery), RFC 4862 (SLAAC), RFC 8201 (PMTU for IPv6), and RFC 4443 (ICMPv6). The forum updates its specifications frequently to be up to date with the latest IPv6 standards, thereby simplifying the processing overhead for product vendors. Apart from the core protocols, the forum also offers certification programs for related IPv6 standards such as DHCPv6, IPSec etc.

Across the industry, the need to migrate towards IPv6 networks has intensified during the last couple of years. Several regulatory authorities across the globe are also pushing for compliance with IPv6 standards. The US government’s USGv6 program is one such initiative to develop infrastructure that is compliant to IPv6 standards. Additionally, Telecommunication Engineering Center of the Department of Telecommunications, India (TEC, India) has rolled out its Essential Requirements for all telecom equipment to be sold or imported into India, including Routers, Switches, Access Points, GPON equipment and Mobile Devices. The Essential Requirements are tested as per the Mandatory Testing and Certification of Telecommunication Equipment (MTCTE) scheme, which has made IPv6 mandatory for most telecom equipment. Regulatory bodies of other geographies in EU and Asia are also considering making IPv6 mandatory by the end of 2020.

Revision of IPv6 Standards

A common misconception is that upgrading a device’s IPv6 stack to comply with the latest standards is a complex activity. However, the updated standards are developed for seamless interoperability across IPv6 nodes with fewer overheads, and the requirements are, in fact, less stringent as compared to the older standards. For example, RFC 8200, which obsoletes RFC 2460, does not mandatorily require the processing of Hop-By-Hop options header. It also does not require a Fragmented echo reply, after a “Packet Too Big” message for MTU less than 1280 Bytes is received by a node. Additionally, RFC 7217 (April 2004) provides an alternative method to generate IPv6 interface identifiers and which are not based on the hardware addresses of devices. It provides a mechanism to configure an IPv6 address which is stable within a subnet and the interface identifier changes when the host moves between networks. This is useful for Mobile handsets and IoT devices, and many product vendors have already started implementing it.

RFC 8201: An Echo Reply need not be fragmented when MTU < 1280Bytes

Image for post

The IPv6 standards have evolved over the years and revisions are made consistently to address the issues and drawbacks faced during deployment. The security and privacy of the users are some of the top priorities while revising the standards and are addressed specifically in the latest IPv6 RFCs.

In the next part of this series of blogs, we will further discuss the challenges faced by developers in implementing the IPv6 stack as per the latest standards, IPv6-related certifications, the role of regulatory authorities and IPv6 addressing of IoT devices.

Source: https://medium.com/@kklahoti/ipv6-standardization-and-compliance-7bfabb98ecee