Network Working Group G. Bauer Internet-Draft 23 April 2026 Intended status: Informational Expires: 25 October 2026 Dotted Decimal notation for IPv6 addresses draft-bauer-ipv6-dotted-decimal-address-format-00 Abstract This document defines a new canonical format for IPv6 addresses, that uses familiar dotted decimal notation. Status of This Memo 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 Notice 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. Bauer Expires 25 October 2026 [Page 1] Internet-Draft ddnip6a April 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 3. Address representation . . . . . . . . . . . . . . . . . . . 3 3.1. Current form . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Issues with current form . . . . . . . . . . . . . . . . 3 3.3. New representation . . . . . . . . . . . . . . . . . . . 4 3.4. Examples of fixed representation . . . . . . . . . . . . 5 4. Implementation considerations . . . . . . . . . . . . . . . . 5 4.1. C standard library . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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 [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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bauer Expires 25 October 2026 [Page 2] Internet-Draft ddnip6a April 2026 3. Address representation The way of textually representing IPv6 addresses is addressed in this section. 3.1. Current form 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. 3.2. 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. 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 Bauer Expires 25 October 2026 [Page 3] Internet-Draft ddnip6a April 2026 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. 3.3. New representation 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 | New IPv6 address representation | | representation | | +======================+========================================+ | 2001:db8::bad | 32.1.13.184.0.0.0.0.0.0.0.0.0.0.11.173 | +----------------------+----------------------------------------+ Table 1: Dotted decimal format 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 | Resulting IPv6 netmask in dotted decimal | | length | 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. | +-------------+--------------------------------------------------+ Table 2: IPv6 network mask notation Bauer Expires 25 October 2026 [Page 4] Internet-Draft ddnip6a April 2026 3.4. 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 |Dotted decimal representation | | |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| +-----------+--------------+---------------------------------------+ Table 3: Special use addresses Note that in the case of the IPv4-Mapped address, the original IPv4 address is always readable in its native format. 4. 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. Section 4.1 shows an example for adapting the C standard library to the new dotted decimal format. 4.1. 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. 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); Bauer Expires 25 October 2026 [Page 5] Internet-Draft ddnip6a April 2026 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. 5. Security Considerations IPv6 address representation does not have a direct impact on Internet infrastructure security. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [Cloudflare-IPv6] Cloudflare, "Cloudflare Radar", n.d., . Bauer Expires 25 October 2026 [Page 6] Internet-Draft ddnip6a April 2026 [Google-IPv6] Google, "Google IPv6 Statistics", n.d., . [IPv8] Thain, J., "IPv8", n.d., . Author's Address Guillaume Bauer Email: guillaume.bauer.418@gmail.com Bauer Expires 25 October 2026 [Page 7]