RFC 8369

Internationalizing IPv6 Using 128-Bit Unicode

📅 published April 2018, from ietf

RFC 8369: Internationalizing IPv6 Using 128-Bit Unicode 🌈

Okay bestie, RFC 8369 is titled Internationalizing IPv6 Using 128-Bit Unicode 🦋 It was written by H. Kaplan from 128 Technology, it's Informational (not a Standards Track spec, so don't go treating it like law 💅), it's dated 1 April 2018, and its ISSN is 2070-1721. It obsoletes RFC 8135 🎀

Abstract ✨

Unicode is going to run out of code points eventually, so we're going to need more, no cap. If ISO and the Unicode Consortium do things the way the IETF does, the next Unicode code point size will be 128 bits 🔥 This doc is about how that future 128-bit Unicode can be used to boost IPv6 adoption and finally give IPv6 real internationalization support 🌸

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8369.

Copyright (c) 2018 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.

Table of Contents 🎀

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
  1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
2.  The Need for 128-Bit Code Points  . . . . . . . . . . . . . .   4
3.  Unicode IPv6 Addresses  . . . . . . . . . . . . . . . . . . .   6
  3.1.  Reserved Addresses  . . . . . . . . . . . . . . . . . . .   6
  3.2.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .   7
  3.3.  IPv6 Routing  . . . . . . . . . . . . . . . . . . . . . .   7
4.  Using Unicode IPv6 Addresses  . . . . . . . . . . . . . . . .   8
  4.1.  Uniform Resource Identifiers  . . . . . . . . . . . . . .   8
  4.2.  Address Allocation and Resolution . . . . . . . . . . . .   8
5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction 💖

Unicode [Unicode] is currently capped at 1,114,112 code points, and they're encoded in different formats (like UTF-8, UTF-16, and UTF-32). When this doc was published, 136,755 code points had been allocated, and even more were already in the approval process 😭 Every year we get new writing scripts, symbols, and emojis, and none ever get removed. After consulting expert mathematicians, we figured out that the world will run out of code points someday 💀

Yes, the current allocation rate makes it look like we have loads of time, but Internet history shows that popular number spaces don't fill up linearly. They fill up exponentially 📈 And once a number space gets entrenched, it takes decades to move to a bigger one. So the code point number space must be increased as soon as possible 🫶

The details for expanding the Unicode code point space aren't covered here. Those need to be sorted out between the IETF, ISO, the Unicode Consortium, and various gods 🧚 We're assuming the code point space will need to grow a LOT, and that there will still be a need for a fixed-length encoding scheme similar to UTF-32. So the next size bump should go from UTF-32 to UTF-128, and the rest of this doc runs with that assumption ✨

This new 128-bit Unicode code point space can also help the IETF with one of IPv6's lingering problems: there's not much left to standardize 🙈 With the changes in this doc, the IETF will stay busy for decades. It also opens up new features and market opportunities that help the global economy. That increases tax revenue for governments, which may eventually mean more funding for fighting global warming 🌍 So, the ultimate goal of this document is to reduce global warming 🌸

1.1. Requirements Language 📖

Here's the official key-word list, and it only counts when these words appear in all capitals, exactly as shown: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They're to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. All other words SHOULD be interpreted as described by the Oxford English Dictionary OED [OED], which MAY be considered almost as authoritative for word definitions as the IETF 🤓

1.2. Definitions 🦋

  • UTF-128: A fixed-length encoding for 128-bit Unicode. It's implemented as an array of bytes, the same way legacy IPv6 addresses are, to avoid endianness issues.
  • Short-Name Tag: A short descriptive name for a Unicode character code point, wrapped in colons (:). For example, :garfield: represents the Unicode code point for the Garfield cat imoji 🐱
  • Emoji: A pictographic symbol encoded in Unicode, used to express a general item, concept, or emotion.
  • Imoji: A pictographic symbol encoded in Unicode, used to represent an individual, specific thing: a specific human, a favorite pet, a famous animal, etc. 💜
  • Amoji: A pictographic symbol encoded in Unicode, used to represent an individual of an alien species 👽
  • Umoji: A pictographic symbol encoded in Unicode, used to represent unknown things not covered by the other mojis ❓
  • Omoji: A pictographic symbol encoded in Unicode, used to represent obfuscated identities, used as addresses for the purpose of privacy 🙈

2. The Need for 128-Bit Code Points 🍓

The exponentially growing demand for Unicode code points might not be obvious at first glance 👀 Sure, the number of languages and their writing scripts doesn't grow quickly over time, but one type of "character" definitely does: emojis 😭 Unicode has barely started giving code points to all the emojis people already use, and more will almost certainly be created later. Right now there are still missing emoji for most types of food and drink, the flags of every town and city on Earth, all human sporting and leisure activities (including every local and national sports team and player), and every plant and animal species and gender 🌈

It's also become common for apps to let users make custom emojis, where the user supplies the graphic that shows up for a new "character" 🎨 For example, a user might set their chat app to display a graphic of Carlos Ramirez's popular "Trollface" meme [TROLL] using the short-name tag :trollface:. Every other user of that same chat app can see and use the same custom trollface emoji 💀

But here's the catch: there's no Unicode code point for :trollface:, so the chat app can't export the trollface emoji to other chat apps or protocols, like Internet Relay Chat (IRC) or the Extensible Messaging and Presence Protocol (XMPP). That's a clear interoperability issue 😤

Down the road, it might also become desirable to give every human a Unicode code point to represent them, kind of like a name, with the glyph being a picture of their face or a custom graphic 🥹 These personal code points aren't really "emojis" in the classical sense of generic concepts, so we've decided to give them a new name to avoid confusion: imoji. Unlike human names, imoji code points will be unique per human, for all space and time. Favorite pets and famous animals can get imojis too 🐶

Last but not least, if we ever meet sentient species from other planets, they'll need Unicode code points for their writing scripts and emojis too 👽 They'll each need unique amojis (imojis for aliens), for whatever form their individual identity takes. Section 4 of RFC 8136 [RFC8136] clearly supports this scenario, with the new UFO IPv6 option 🛸

Based on these super obvious use cases, it's clear that the current ~1 million code points are nowhere near enough. Going to 64 bits might be enough for now, but since this transition will be painful no matter what size we pick, we believe jumping straight to 128 bits is the right call 💅

Note: The current limit of ~1 million code points is a formal limit because of what UTF-16 can encode today. Raising the limit will either require deprecating UTF-16 or paying a hefty overhead penalty to encode 128 bits across many pairs of surrogate code points. Since the ultimate goal of this document is to reduce global warming, choosing between deprecating UTF-16 and paying the overhead price is a trivial dilemma by comparison 🌍✨

3. Unicode IPv6 Addresses 🦋

Assuming the new Unicode code point space is 128 bits (excluding some reserved bits for backwards compatibility and future expansion), it seems only natural to use Unicode code points for IPv6 addresses, and vice versa. That leads to some exciting changes, like:

  • IPv6 addresses no longer need to be typed as hex values. Instead, the glyph for the script character, symbol, emoji, or imoji that represents the address can be input by the user, and the application will display it as the graphic itself 🤩 From the user's perspective, this is also more compact than the representation described in RFC 1924 [RFC1924].
  • Network monitoring and troubleshooting tools can now show pretty glyphs instead of ugly IPv6 addresses, which means less stress on the eyes of network administrators 🥺✨
  • For places where graphical glyphs can't be used, like IETF documents, we can deprecate the legacy textual notation of IPv6 addresses like 2001:db8:85a3::8a2e:370:7334 in favor of the simpler Unicode textual notation U+20010DB885A3000000008A2E03707334. Using the short-name tag is also possible, like :v6address-1: 🎀

Because IPv6 addresses are now Unicode code points, RFC 8135 [RFC8135] is made obsolete by this document. It was found to be too complex to implement anyway 💀🔥

3.1. Reserved Addresses 🌌

okay so some code points are just NOT giving for IPv6 addressing 💀, like formatting characters and control codes. Those code points MUST NOT be used for IPv6 addresses 🚫

we still need to reserve a few code points for private network use though 🔒 and since no sentient life has been found on Mars 👽 (honestly so sad 😭), the code points that would've been allocated for Martian imojis are officially reserved for this private use. these addresses are called "Martians", also known as "Bogons" because they're bogus 🙈

Note: Should life be found on Mars in the future, new code points will be allocated for them. To avoid confusion, they will be called "Barsoom Indigenous Glyph Off-world Network" addresses, or "Bigons" (pronounced "bye-gons"). We're certain the Martians will let Bogons be bygones, and Bigons be Bigons. 🧚💜

3.2. Multicast 📣

okay the vibe here is that in both IPv4 and IPv6, multicast addresses have been stuck in predefined IP address ranges 😩, which limits how many multicast groups can be used at the same time. with broadcasting-style social media and everyone wanting to be watched and followed by a bunch of random strangers all the time 👀, it's giving that we need to be able to multicast everything, all the time 🔥

so, the high-order bit of the 128-bit code point space SHALL be reserved to indicate multicast ✨ that means every valid code point (aka IPv6 address) will have a multicast counterpart 🫶 for example, the code point allocated for :cat: is U+1F408, so the multicast group U+8000000000000000000000000001F408 is for content about cats 🐈 note that this is for general cat content. other code points are allocated for specific cat content, like joy cat, grinning cat, pouty cat, etc 😭 and for an individual cat like Garfield, setting the high-order bit to the code point allocated for :garfield: will indicate that it's multicast content about Garfield 🧡

source-specific multicast plays a role too 💅 like, joining the :garfield: multicast group and restricting it to a source of :garfield: means you only get content about Garfield, from Garfield. iconic 👑

3.3. IPv6 Routing 🗺️

there should be little impact on routing using code-point-based IPv6 addresses 🌸 there might be some exponential growth in routing and forwarding tables because code points are hard to aggregate, but hopefully processor and memory capacity will catch up to that 🤞 and of course this will also drive the need to frequently upgrade networking hardware 🛠️ which gives a boost to the global economy, and thus a reduction in global warming 🌍 (the plot twist is literally everything is connected 🥹)

one routing improvement that MAY be considered is scenic routing as defined by RFC 7511 [RFC7511] 🌄 with emojis and imojis available for addressing, we can now specify exactly what type of scenery to visit along the way, or even which exact avian carrier [RFC6214] to ride with 🐦 ngl that's the main character energy we deserve. just a heads up though: avian carriers as described in RFC 1149 [RFC1149] are not supported, since they only support IPv4 💔

4. Using Unicode IPv6 Addresses ✨

4.1. Uniform Resource Identifiers 🔗

okay so Uniform Resource Identifiers (URIs) and Uniform Resource Locators (URLs) already support Unicode through Internationalized Resource Identifiers (IRIs) 🌐 but those are basically just a way to use multiple Unicode characters to point at a resource. with 128-bit Unicode, the number space is big enough to identify each resource with a single Unicode character 🤯 why waste space and time typing out multiple characters when you can just use one? 💅

for URLs, this new model might only mean using a single Unicode character for the hostname part 🏢 like a corporate logo instead of the legacy corporate domain name. another option is to allocate a code point for the entire host and path, maybe even including the scheme 🧠 these types of decisions can be made in future IETF Working Groups 📋

the interesting part is that no address lookup needs to be performed 😳 the single 128-bit Unicode for the URL is the IPv6 address. the only extra step is when the user inputs a private Unicode character or short-name tag that needs to be converted to a publicly allocated one 🔄 that would need Network Address Translation (NAT) from the private code point or short-name tag to a public Unicode code point. and this can be done locally, which finally brings NATs into the last part of the Internet where they aren't currently deployed: the user's application 🎀

4.2. Address Allocation and Resolution 🏦

it's obvious that once a single 128-bit Unicode character is used for addresses and URIs, domain names will quickly become obsolete 💀 the subsequent collapse of the domain name industry is a threat to the world economy, which MUST be addressed 🚨

one solution is to establish a Unicode registry model and an accompanying Code Point Unicode Resolution System (CPURS, pronounced "keepers") 🔑 CPURS would replace DNS and provide an architecture and resolution mechanism to resolve Unicode code points to their registered glyphs and short-name tags, and vice versa. the new Unicode registries and registrars would replace the legacy domain name counterparts 🫠 this would kick off a new gold rush for registering Unicode code points for corporate logos and product icons 🤑 usher in an era of economic prosperity, which would eventually reduce global warming 🌷

once Unicode registries and CPURS are in place, IPv6 addresses would be allocated by registering code points through that system 📝 they would no longer be registered by IANA and RIRs. it's not a major concern though, because any tax revenue loss will be more than offset by Unicode registries allocating code points 💸 also, to make CPURS possible, the actual graphic files for the glyphs need to be standardized and created in numerous formats and sizes, with various intellectual property rules 🎨⚖️ more work for graphic artists and lawyers means more tax revenue, periodt 💼

the astute reader might ask why we need CPURS if Unicode translation is already performed locally on hosts today 🤔 the answer is volume. host applications are unlikely to keep up with the rate of new Unicode code points being allocated for emojis, imojis, and umojis 😵‍💫 application and operating system updates have been happening at an ever-increasing rate and will soon match the rate of human births, but it's doubtful they'll ever match the rate of sentient extraterrestrial births 👽 so we need a system that can scale to that volume before we make first contact 🛸 otherwise, the diplomatic failure to quickly give the aliens amojis of their own may lead to armed conflict ⚔️ and an armed conflict with other sentient beings capable of reaching Earth might increase global warming, which would defeat this document's ultimate purpose 😭

5. Summary 🌈

there's still a lot to decide, most of which is honestly pretty boring 🥱 but it's clear that 128-bit Unicode code points will be needed eventually, and IPv6 addressing MUST be migrated to it. so the time to act is NOW 🚀✨

6. IANA Considerations 📚

this document has no IANA actions 🫶

7. Security Considerations 🕵️‍♀️

okay this part is SERIOUS bestie 😤 the main security concern with using 128-bit Unicode for IPv6 addressing is privacy, in terms of anonymity 🙈 if an IPv6 packet is sent with an imoji or amoji address, then man-in-the-middle devices in the network will know the specific human or alien that sent or received the packet 😱 using that info might lead to heated discussions, which would increase global warming 🔥

to address this, an IPv6 address MAY be obfuscated by using an omoji 🖤 an omoji is simply the original Unicode code point with the least-significant bit set. all other types of 128-bit Unicode code points MUST have the least-significant bit cleared 🚫 the graphical representation of an omoji is the same as its unobfsucated moji counterpart, except it's covered over by a solid black block ⬛

by setting the least-significant bit of the source or destination (turning it into an omoji), the IPv6 address is obfuscated and the true identity can't be determined, while IPv6 routers can still route the packet appropriately 🧠 this only provides a bit of privacy, but every bit helps 💜

8. References 📖

8.1. Normative References

8.2. Informative References

Acknowledgements 💖

the authors want to thank the following people for providing the inspiration for this work: Cal Henderson, Carlos Ramirez, Graham Linehan, Agnetha Faltskog, Bjorn Ulvaeus, Benny Andersson, and Anni-Frid Lyngstad 🎶🥰

Author's Address 🦋

Hadriel Kaplan

128 Technology

Burlington, MA

United States of America

Email: hadriel@128technology.com

📦 where this page comes from