Internet Engineering Task Force M. Ertl, Ed. Internet-Draft Ertl Software Productions Intended status: Informational 1 April 2026 Expires: 3 October 2026 UTF-8 Internet Protocol Addresses draft-mertl-afipv8-00 Abstract 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. 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 3 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 Ertl Expires 3 October 2026 [Page 1] Internet-Draft AF UTF-8 IP April 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. New display and entry format for IPv6 addresses . . . . . . . 3 3. Proposal for address extension . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. 1.1. Requirements Language 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. Ertl Expires 3 October 2026 [Page 2] Internet-Draft AF UTF-8 IP April 2026 2. New display and entry format for IPv6 addresses 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 * IETF server:/128 (tabulator and mandatory transition before slash) 4945:5446::7365:7276:6572/128 (traditional notation of the above) * RFC Editor:/128 (tabulator and mandatory transition before slash) 5246:4300::4564:6974:6F72/128 (traditional notation of the above) Ertl Expires 3 October 2026 [Page 3] Internet-Draft AF UTF-8 IP April 2026 * Campus dorm :/64 (tabulator and mandatory transition before slash) 4361:6D70:7573::646F:726D:2020/64 (traditional notation of the above) * This is an IPv6!:/128 (mandatory transition before slash) 5468:6973:2069:7320:616E:2049:5076:3621/128 (traditional notation of the above) Examples for mixed addresses * 2001:db80:Peace please:/64 (one transition and mandatory transition before slash) 2001:db80:5065:6163:6520:706C:6561:7365/64 (traditional notation of the above) * 2001:db8::IETF-room _ :/64 (one transition and mandatory transition before slash) 2001:db80:4945:5446:2D72:6F6F:6D20:5F20/64 (traditional notation of the above) * 2001:db8::corp-servers:/64 (one transition and mandatory transition before slash) 2001:db80:636F:7270:2D73:6572:7665:7273/64 (traditional notation of the above) * 2001:db80:land:0123::3/64 (two transitions, double colon and no mandatory transition) 2001:db80:6C61:6E64:0123::3/64 (traditional notation of the above) * 2001:db80:land 0123::/64 (two transitions, including double colon and no mandatory transition) 2001:db80:6C61:6E64:2030:3132:3300::/64 (traditional notation of the above) * 2001:db80:trees:0123: :/64 (three transitions, tabulator and mandatory transition before slash) 2001:db80:7472:6565:7301:2300::/64 (traditional notation of the above) * 2001:db80:trees:0123::/64 (equivalent to above, two transitions and no mandatory transition) 2001:db80:7472:6565:7310:2300::/64 (traditional notation of the above) * 2001:db80:trees0:1230::/64 (not equivalent to above, two transitions and no mandatory transition) 2001:db80:7472:6565:7330:1230::/64 (traditional notation of the above) Ertl Expires 3 October 2026 [Page 4] Internet-Draft AF UTF-8 IP April 2026 * 2001:db80::database:/64 (one transition and mandatory transition before slash) 2001:db80::6461:7461:6261:7365/64 (traditional notation of the above) * 2001:db80::Cameras:0/80 (not acceptable due to ambiguity) 2001:db80:0000:00:Cameras:0/80 (ambiguity removed, acceptable) 2001:db80::43:616D:6572:6173:0/80 (traditional notation of the above) 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. 3. Proposal for address extension 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. 4. IANA Considerations This memo includes no request to IANA. Ertl Expires 3 October 2026 [Page 5] Internet-Draft AF UTF-8 IP April 2026 5. Security Considerations 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. 6. References 6.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, . Ertl Expires 3 October 2026 [Page 6] Internet-Draft AF UTF-8 IP April 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 6.2. Informative References [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. Author's Address Marcus Ertl (editor) Ertl Software Productions An Peschbenden 13 47906 Kempen Germany Phone: +49 2152 53286 Email: marcus.ertl@gmx.net Ertl Expires 3 October 2026 [Page 7]