| Internet-Draft | ddnip6a | April 2026 |
| Bauer | Expires 25 October 2026 | [Page] |
This document defines a new canonical format for IPv6 addresses, that uses familiar dotted decimal notation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [Google-IPv6]. Other actors like Cloudflare report a mean IPv6 traffic share of over 40% in the last 12 moths [Cloudflare-IPv6]. 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 [RFC5952]. 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The way of textually representing IPv6 addresses is addressed in this section.¶
When being displayed or printed, an IPv6 address is represented in conformance with [RFC4291] and [RFC5952]. An example of an address with its prefix length is shown below.¶
2001:db8::bad/64
¶
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.¶
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.¶
2001:db8::1 2001:db8:1111:1111:1111:1111 ::¶
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.¶
[2001:db8::1]:443¶
These issues have greatly slowed down the global adoption of IPv6. Some proposals have been made to mitigate the issues, like [IPv8], but redefining the architecture of the entire Internet seems excessive just to resolve an address representation issue.¶
The new IPv6 address representation aims to fix the issues listed in Section 3.2 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. |
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.¶
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. Section 4.1 shows an example for adapting the C standard library to the new dotted decimal format.¶
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.¶
int inet_pton(int af,
const char *restrict src,
void *restrict dst);
const char *inet_ntop(socklen_t size,
int af,
const void *restrict src,
char dst[restrict size],
socklen_t size);
¶
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.¶
IPv6 address representation does not have a direct impact on Internet infrastructure security.¶
This document has no IANA actions.¶