Dotted Decimal notation for IPv6 addresses

Introduction The global use of the Internet Protocol v6 (IPv6) is constantly growing. At the time of writing of this document, Google reports that 45% of it's customer traffic uses IPv6 . Other actors like Cloudflare report a mean IPv6 traffic share of over 40% in the last 12 moths . With the slow but steady grows in IPv6 adoption, network administrator are expected to be confronted more often with IPv6 addresses, represented in their canonical form . While ensuring efficient text representation, the canonical IPv6 address form requires a deep knowledge of hexadecimal notation to be understood. This is often considered a barrier to the understanding ov the IPv6 protocol by network administrators who are more familiar with IPv4. A secondary IPv6 address notation could help close the gap between network administrators and the IPv6 protocol by providing a more familiar way of representing addresses. This proposal DOES NOT replace the standard canonical notation, but rather propose an alternate format.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Address representation The way of textually representing IPv6 addresses is addressed in this section.

Current form When being displayed or printed, an IPv6 address is represented in conformance with and . An example of an address with its prefix length is shown below.

This representation uses hexadecimal notation in conjunction with the leading zeroes omission and zero compression rules. the prefix length is separated from the address by the '/' character.

Issues with current form The canonical notation that is currently used for IPv6 address representation poses a number of issues : The use of hexadecimal notation introduces new digits that expand the traditional ten digits (0-9). However, as the standard english alphabet doesn't have more glyphs to represent digits, we are forced to use letters to represent values from 10 to 15. This introduces a lot of confusion when trying to read a hexadecimal number and forces network administrators to learn a new numbering format. The zero compression rule introduces a lot of confusion, because the length of an IPv6 represented in standard notation can vary greatly. Some examples of IPv6 addresses are shown below.

The colon (':') character is normally used to separate an IP address and a port number. Its usage in the representation of an IPv6 address introduces event more complexity and the necessity to use more characters to separate the address from the port number. An example is shown below.

These issues have greatly slowed down the global adoption of IPv6. Some proposals have been made to mitigate the issues, like , but redefining the architecture of the entire Internet seems excessive just to resolve an address representation issue.

New representation The new IPv6 address representation aims to fix the issues listed in and improve the readability of IPv6 addresses for seasoned network administrators. With this new representation, an IPv6 address is divided into 16 groups of 8 bits. Each byte is represented in decimal notation. The individual bytes are separated by dots ('.'). Leading zeroes in a byte MUST be omitted, but there is no zero compression rule. An example of an IPv6 address is shown below. Classic IPv6 address representation New IPv6 address representation 2001:db8::bad 32.1.13.184.0.0.0.0.0.0.0.0.0.0.11.173 While being longer, the new representation is more similar to an IPv4 address. The new representation also reintroduces network masks using the same semantics. An IPv6 prefix length with a value of N can be converted to a network mask by setting the N leftmost bits of a 128 bits integer to one and the reste of the bits to zero. The mask can them be displayed using the same new semantics as for an IPv6 address. IPv6 prefix length Resulting IPv6 netmask in dotted decimal notation 0 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 32 255.255.255.255.0.0.0.0.0.0.0.0.0.0.0.0 64 255.255.255.255.255.255.255.255.0.0.0.0.0.0.0.0.

Examples of fixed representation The IPv6 specification contains a number of special use addresses whose representation are very confusion. A few examples and their dotted decimal representation are listed below. Address Standard IPv6 representation Dotted decimal representation Unspecified :: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 Loopback ::1 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 IPv4-Mapped ::ffff:0:0 0.0.0.0.0.0.0.0.255.255.255.255.0.0.0.0 Note that in the case of the IPv4-Mapped address, the original IPv4 address is always readable in its native format.

Implementation considerations Most programming languages include in their standard library a way to parse a string containing an IPv6 address in canonical representation into an actual binary address and vice-versa. As there has only been one standard format to represent an IPv4 address and an IPv6 address, these APIs do not include functionality to choose a format. shows an example for adapting the C standard library to the new dotted decimal format.

C standard library The C standard library provides a few functions to convert an IP address from its textual representation to a binary value and vice-versa. One of them is inet_pton, that can be used with IPv4 or IPv6 addresses. Its counterpart inet_ntop does the opposite.

The af argument represents the address family and can be set to AF_INETfor an IPv4 address and AF_INET6 for an IPv6 address. One way of implementing the new dotted decimal notation would be to reserve a new value for the af argument, like AF_INET6_DD. This constant would have a decimal value of 11, which follows the value of the constant AF_INET6 (10) defined in linux/socket.h.

Security Considerations IPv6 address representation does not have a direct impact on Internet infrastructure security.

IANA Considerations This document has no IANA actions.