| Internet-Draft | AF UTF-8 IP | April 2026 |
| Ertl | Expires 3 October 2026 | [Page] |
This memo describes an alternate entry and display format for IPv6 addresses using UTF-8 instead of hextets. A mixed representation for traditional IPv6 address prefixes also is explored, along with means of transitioning between the two within an IPv6 address.¶
Additionally, an address extension is proposed to accommodate the inevitable need for longer addresses.¶
Finally, security implications of special UTF-8 glyphs are considered.¶
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 3 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 adoption and deployment of IPv6 has been slow due to several factors, including the perceived unwieldiness of the addresses themselves and the lack of memorable constants. Hextet notation doesn't lend itself well to memorization (especially if the entire length needs to be memorized) and, while better in this respect, there still are only a handful of recognizable, catchy constants like "dead", "beer", "face", etc. . Even resorting to "Leetspeak" (1337) will yield only a comparatively small pool of choices. Therefore, the most powerful drive for adoption, vanity, isn't readily applicable. This document aims to change this by presenting a way for organizations and individuals to express themselves within IPv6 addresses, which is impossible to do with IPv4 and therefore is expected to become a deciding factor in IPv6 adoption.¶
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.¶
Instead of the current hextet format, separated by colons, IPv6 addresses as defined by [RFC8200] MAY be displayed and entered as a sequence of UTF-8 characters as defined in [RFC3629]. These lend themselves well to the underlying octet format while placing no limitations on the characters.¶
Mixed representation MAY be used and is especially relevant to conventional prefixes that have been defined without this new representation in mind. Representations MUST NOT change within octets. Transitions MUST be delimited by a colon. Mixed notation MUST NOT transition to UTF-8 using a valid hexadecimal character (a-f,A-F,0-9).¶
The new UTF-8 representation uses the tabulator (U+0009) as native replacement for the double colon used in IPv6. As with the double colon, a UTF-8 IP address MUST NOT contain more than one tabulator. It also MUST NOT contain both a tabulator and a double colon.¶
To avoid confusion, the displaying software SHOULD visually distinguish the tabulator from common whitespace. Likewise, the displaying software SHOULD visually distinguish traditional and nontraditional parts of an IPv6 address, since it will be common that characters from the hexadecimal range appear in the new notation. Also see Section 5 for security implications of possible usage of special formatting glyphs.¶
If the slash prefix notation "/[bits]" is used, there MUST be a transition to hextet notation immediately preceding the slash.¶
Even though it is NOT RECOMMENDED, the mixed representation allows transitions transition to / from UTF-8 after odd-numbered octets. If a double colon or tabulator is used with such a separation, all remaining octets MUST be spelt out fully (even those that would be compacted to a single "0" in traditional IPv6). Basic IPv6 colon separation and explosion rules MUST NOT be applied in this case.¶
The three characters: colon (:), slash (/) and tabulator (U+0009) are reserved and MUST NOT appear as part of the address itself.¶
Examples¶
Examples for mixed addresses¶
As seen above, it is often feasible to encode the entire hostname in the host part of the IPv6. However, the reverse translation into mixed notation cannot easily be done without additional user input, therefore it is RECOMMENDED to have the position of the transition to UTF-8 be defined by the prefix length, and also it is NOT RECOMMENDED to transition back from UTF-8 at all except for the the mandatory transition at the slash.¶
If the prefix length is used in this manner, automated reversal would be facilitated, which would make it significantly more easy to administer static IP addresses, oversee dynamic address leases as well as analyze log files, where the absence of meaningful UTF-8 representation may by itself be a clue to an issue. Essentially, the translation of a more or less arbitrary hextet sequence to any specific machine name would become largely unnecessary once the hostname is the IP address. This in turn has the potential of streamlining the workflow and thereby reduce both manual labour and opportunity for error.¶
By transitioning to UTF-8 addressing it becomes immediately obvious that the current size of an IPv6 address is insufficient. There will undoubtedly be
desire to use organization names, catchy phrases, or mottos for public-facing hosts, for the prefix, or both.
It is therefore proposed to increase the address size by a factor of four.
When doing so,
notation should be restricted to UTF-8 only, as the resulting longer addresses cannot be rendered in a concise way in hextet notation.
With this extension, the current DNS system would become obsolete, simplifying the internet architecture and removing vulnerable services.¶
This memo includes no request to IANA.¶
If the proposed address extension is implemented, the DNS system, both local and global, would become obsolete and all associated vulnerabilities and
risks with it.
Additionally, the direct representation of hostnames as their IP addresses would likely benefit security due to reduced risk of misidentification or misrepresentation.
Care must be taken, however, with
international UTF-8 glyphs that look similar to those used in a particular instance, just like in internationalized domain names (IDN), [RFC5890].
Additionally,
glyphs that facilitate hiding of characters, like in the GlassWorm exploit, need to be taken into account.
Finally, the tabulator may also look similar to a common
whitespace, so fake addresses could be constructed to mimic official addresses exploiting this.¶
While hiding glyphs SHOULD simply be disallowed, the other glyphs may have legitimate purposes and cannot be universally restricted. Instead, the displaying software needs to visually distinguish them in an obvious but non-intrusive way so that the risk for misidentification is at least reduced.¶
The displaying software MUST ensure that all characters and glyphs that make up an address are clearly and immediately identifiable, including formatting.¶
The handling of special glyphs except for the tabulator by security software and devices can likely be heavy-handed because it is expected that these will be used either only internal to a specific network, or not at all, because entering them will be difficult and thus undesirable in any foreign script. External or global use will thus be restricted to fraud and forgery.¶
As a general rule, glyphs that are not native to the respective script of a network or organization should be visually distinguished. If a glyph or character cannot be rendered, it MUST be replaced by a clear indicator, ideally identifying the offending character or glyph by other means.¶
This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz.¶