RFC 8771
The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) 💖
RFC 8771 🎀 Independent Submission, Experimental category, ISSN 2070-1721, dated 1 April 2020 🃏
Written by A. Mayrhofer (nic.at GmbH) and J. Hague (Sinodun) 👩💻👩💻
The title block doesn't list anything this one obsoletes or updates. 🌸
Abstract
Okay so domain names were made for humans, but IP addresses were not 🙈 Over 30 years after DNS showed up, a small group of people is still in there reading, writing, misspelling, memorizing, shuffling, and mixing up IP addresses, like it's their business 💀 This memo introduces the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO") 🦋 It's a notation that's way more concise than the current text forms, and it's built to discourage exactly that tiny-but-definitely-important group of humans from messing with addresses. Iconic. 👑
Status of This Memo
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪
It defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 📜
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8771 🔍
Copyright Notice
Copyright (c) 2020 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. Please read these carefully, bestie, because they spell out your rights and restrictions with respect to this document 🫶
Table of Contents
1. Introduction
2. Terminology
3. The Notation
3.1. Forming I-DUNNO
3.2. Deforming I-DUNNO
4. I-DUNNO Confusion Level Requirements
4.1. Minimum Confusion Level
4.2. Satisfactory Confusion Level
4.3. Delightful Confusion Level
5. Example
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Authors' Addresses1. Introduction ✨
So in Section 2.3 of [RFC0791], the people who designed the Internet Protocol carefully split names and addresses into two separate things 💅 They never said outright that names are for humans and addresses are for machines, but they did hint at it in their philosophical statement: "A name indicates what we seek." That basically means names are the thing humans should care about 🥺
The spec for domain names in [RFC1034], plus all the ongoing effort put into the Domain Name System, backs that up. Humans use names, and machines handle the addresses. RFC 1034 mentions "users" a bunch of times and even uses the word "humans." It's placed a little awkwardly, honestly, in a context of "annoying" and "can wreak havoc" (see Section 5.2.3 of [RFC1034]) 💀 Still, it's one more sign that domain names are made for people, while IP addresses are for machines 🤖
So given that, and a long, error-filled history of people trying to use addresses directly, it's honestly really desirable that humans don't meddle with IP addresses. It makes sense that a human-readable (textual) form of IP addresses got only a very vague spec in Section 2.1 of [RFC1123] 🙈 Later on, someone made a deliberate push to keep humans away by making IP addresses more confusing in [RFC1883] (which [RFC8200] obsoleted), and Section 2.2 of [RFC4291] added extra options for human puzzlement 🧩 These noble early attempts to stop humans from reading, understanding, or even spelling IP addressing schemes were, sadly, badly compromised in [RFC5952] 😭
To stop more damage from humans poking at IP addresses, we urgently need an address notation that replaces these "Legacy Notations" and efficiently discourages humans from reading, modifying, or otherwise manipulating IP addresses 🚨 Research in this area recognized long ago the potential in ab^H^Hperusing the intricacies, inaccuracies, and chaotic disorder of what humans proudly call a "Cultural Technique" (also known as "Script") 📜 And with a certain unstoppable inevitability, it has lately locked onto the admirable confusion (and thus discouragement) potential of [UNICODE] as an address notation 🌀 In Section 4, we introduce a framework of Confusion Levels to help evaluate how well any Unicode-based scheme produces notation that resists quick comprehension or, heaven forfend, mutation of the address. That's how you get the desired confusion and discouragement 💖
The authors welcome [RFC8369] as a major step in the right direction. However, they have some reservations about the scheme proposed there 🤔
- Concise, but not confusing enough. Their analysis shows that, while impressively concise, the scheme gets at best a Minimum Confusion Level in our classification 📉
- Emoji are too easy now. Humans, especially younger ones, are getting really good at handling emoji 😤 Over time, that will hurt the discouragement factor 💀
- IPv6 only. The proposed scheme is specific to IPv6. If a fix is going to be timely at all, it has to address IPv4 as its top priority 🚨 After all, even with the regrettable effects of RFC 5952 taken into account, IPv6 is still inherently much more confusing and discouraging than IPv4 🙃
So this document specifies a different Unicode-based notation, the Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) 🦋 It handles each of the concerns above:
- Confusion on tap. I-DUNNO can generate Minimum, Satisfactory, or Delightful levels of confusion 🌈
- More than emoji. As well as emoji, it takes advantage of other areas of Unicode confusion 🎪
- Both IP versions. It can be used with IPv4 and IPv6 addresses 🌸
We admit I-DUNNO is way less concise than the notation in RFC 8369 🙈 But by allowing multiple code points in the representation of a single address, I-DUNNO opens up the full spectrum of Unicode-adjacent code point interaction. That's a big reason it can reach higher confusion levels 🔥 I-DUNNO also doesn't change the current size of Unicode code points, so its chances of adoption and implementation are (slightly) higher ✨
Quick note: using I-DUNNO in the reverse DNS system is currently out of scope. The occasional human-caused absence of the magical one-character sequence U+002E is believed to create plenty of disorder there already 💅
Media Access Control (MAC) addresses are totally out of the question. 🙅♀️
2. Terminology 🎀
Okay, the BCP 14 key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are read as described in BCP 14 [RFC2119] [RFC8174] only when they're written in all capitals, exactly like that, and they're the only words this document treats that way 🧐
Extra terminology from [RFC6919] might apply, too. 📖
3. The Notation 🦋
I-DUNNO uses UTF-8 [RFC3629] to obfuscate IP addresses for humans. UTF-8 uses sequences of 1 to 4 octets to represent code points, like this:
+-----------------------+-------------------------------------+
| Char. number range | UTF-8 octet sequence |
+-----------------------+-------------------------------------+
| (hexadecimal) | (binary) |
+=======================+=====================================+
| 0000 0000 - 0000 007F | 0xxxxxxx |
+-----------------------+-------------------------------------+
| 0000 0080 - 0000 07FF | 110xxxxx 10xxxxxx |
+-----------------------+-------------------------------------+
| 0000 0800 - 0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
+-----------------------+-------------------------------------+
| 0001 0000 - 0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
+-----------------------+-------------------------------------+
Table 1I-DUNNO uses that structure to pack addressing info like so: 📦
3.1. Forming I-DUNNO
To make an I-DUNNO from the Legacy Notation of an IP address, you do the following steps 🧁
- The octets of the IP address are written as a bitstring in network byte order. 🔢
- Working from left to right, the bitstring (32 bits for IPv4; 128 bits for IPv6) gets used to generate a list of valid UTF-8 octet sequences. To allocate a single UTF-8 sequence:
- a. Choose whether to generate a UTF-8 sequence of 1, 2, 3, or 4 octets. The choice ought to be guided by the requirement to generate a satisfactory Minimum Confusion Level (Section 4.1) (not to be confused with the minimum Satisfactory Confusion Level (Section 4.2)). Use the character number range in Table 1 to figure out which octet sequence lengths are valid for a given bitstring. For example, a 2-octet UTF-8 sequence requires the next 11 bits to have a value in the range 0080-07ff. 🧮
- b. Allocate bits from the bitstring to fill the vacant positions 'x' in the UTF-8 sequence (see Table 1) from left to right. ➡️
- c. UTF-8 sequences of 1, 2, 3, and 4 octets require 7, 11, 16, and 21 bits, respectively, from the bitstring. Since the number of combinations of UTF-8 sequences that fit exactly 32 or 128 bits is limited, in sequences where the number of bits required doesn't exactly match the number of available bits, the final UTF-8 sequence MUST be padded with additional bits once the available address bits run out. The sequence may therefore need up to 20 bits of padding. The content of the padding SHOULD be chosen to maximize the resulting Confusion Level. 🧩
- Once the bits in the bitstring are used up, the conversion is complete. The I-DUNNO representation of the address is made of the Unicode code points described by the list of generated UTF-8 sequences, and it MAY now be presented to unsuspecting humans 😈
3.2. Deforming I-DUNNO
This section is intentionally omitted. 🤫 The machines will know how to do it, and by definition, humans SHOULD NOT attempt the process. 🚫🙈
4. I-DUNNO Confusion Level Requirements ✨
okay so a sequence of characters only counts as I-DUNNO when it has enough potential to confuse humans 🫶 no cap, that's the whole vibe check.
Unallocated code points MUST be avoided. 💀 They might look like they're giving maximum confusion rn, but there's a tiny chance that one gets allocated to a useful, legible character later and its confusion power drops off a cliff. Even worse, in the (unlikely, but not impossible -- see Section 3.1.3 of [RFC5894]) event that a code point loses its DISALLOWED property per IDNA2008 [RFC5894], existing I-DUNNOs could end up less than minimally confusing, and that would be a disaster 😭
The following Confusion Levels are defined:
4.1. Minimum Confusion Level
As a minimum, a valid I-DUNNO MUST:
- Contain at least one UTF-8 octet sequence with a length greater than one octet.
- Contain at least one character that is DISALLOWED in IDNA2008. No code point left behind! 🧚 This also lets machines tell I-DUNNO apart from Internationalized Domain Name labels, which is so useful ngl.
I-DUNNOs on this level will at least puzzle most human users who know the Legacy Notation 🙈
4.2. Satisfactory Confusion Level
An I-DUNNO with Satisfactory Confusion Level MUST adhere to the Minimum Confusion Level, and additionally contain two of the following:
- At least one non-printable character.
- Characters from at least two different Scripts.
- A character from the "Symbol" category.
The Satisfactory Confusion Level will make many human-machine interfaces beep, blink, silently fail, or any combination of those, and honestly that's chaotic enough to discourage most humans from deforming I-DUNNO 💅
4.3. Delightful Confusion Level
An I-DUNNO with Delightful Confusion Level MUST adhere to the Satisfactory Confusion Level, and additionally contain at least two of the following:
- Characters from scripts with different directionalities.
- Character classified as "Confusables".
- One or more emoji.
An I-DUNNO at this level will cause almost all humans to U+1F926, with the exception of those subscribed to the idna-update mailing list 🤦♀️😭
(We have also considered a further, higher Confusion Level, tentatively entitled "BReak EXaminatIon or Twiddling" or "BREXIT" Level Confusion, but currently we have no idea how to go about actually implementing it.) 🌈
5. Example
okay, example time 🎀 An I-DUNNO based on the Legacy Notation IPv4 address "198.51.100.164" gets formed and validated like this. First, the Legacy Notation is written as a string of 32 bits in network byte order:
11000110001100110110010010100100Since I-DUNNO requires at least one UTF-8 octet sequence with a length greater than one octet, we allocate bits in the following form:
seq1 | seq2 | seq3 | seq4
--------+---------+---------+------------
1100011 | 0001100 | 1101100 | 10010100100This translates into the following code points:
+-------------+-------------------------------------------+
| Bit Seq. | Character Number (Character Name) |
+=============+===========================================+
| 1100011 | U+0063 (LATIN SMALL LETTER C) |
+-------------+-------------------------------------------+
| 0001100 | U+000C (FORM FEED (FF)) |
+-------------+-------------------------------------------+
| 1101100 | U+006C (LATIN SMALL LETTER L) |
+-------------+-------------------------------------------+
| 10010100100 | U+04A4 (CYRILLIC CAPITAL LIGATURE EN GHE) |
+-------------+-------------------------------------------+
Table 2The resulting string MUST be evaluated against the Confusion Level Requirements before I-DUNNO can be declared. Given the example above:
- There is at least one UTF-8 octet sequence with a length greater than 1 (U+04A4).
- There are two IDNA2008 DISALLOWED characters: U+000C (for good reason!) and U+04A4.
- There is one non-printable character (U+000C).
- There are characters from two different Scripts (Latin and Cyrillic).
Therefore, the example above constitutes a valid I-DUNNO with a Satisfactory Confusion Level. U+000C in particular has great potential in environments where I-DUNNOs would be sent to printers 🖨️🍓
6. IANA Considerations
If this work is standardized, IANA is kindly requested to revoke all IPv4 and IPv6 address range allocations that do not allow for at least one I-DUNNO of Delightful Confusion Level. IPv4 prefixes are more likely to be affected, so this can easily be marketed as an effort to foster IPv6 deployment 🌸
Furthermore, IANA is urged to expand the Internet TLA Registry [RFC5513] to accommodate Seven-Letter Acronyms (SLA) for obvious reasons, and register 'I-DUNNO'. For that purpose, U+002D ("-", HYPHEN-MINUS) SHALL be declared a Letter. the SLA era is here, bestie 💅
7. Security Considerations
I-DUNNO is not a security algorithm. Quite the contrary -- many humans are known to develop a strong feeling of insecurity when confronted with I-DUNNO. 😭🙈
In the tradition of many other RFCs, the evaluation of other security aspects of I-DUNNO is left as an exercise for the reader 🦋
8. References
8.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<https://www.rfc-editor.org/info/rfc5894>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 2009,
<https://www.rfc-editor.org/info/rfc5513>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8369] Kaplan, H., "Internationalizing IPv6 Using 128-Bit
Unicode", RFC 8369, DOI 10.17487/RFC8369, April 2018,
<https://www.rfc-editor.org/info/rfc8369>.
[UNICODE] The Unicode Consortium, "The Unicode Standard (Current
Version)", 2019,
<http://www.unicode.org/versions/latest/>.Authors' Addresses
Alexander Mayrhofer
nic.at GmbH
Email: alexander.mayrhofer@nic.at
URI: https://i-dunno.at/
Jim Hague
Sinodun
Email: jim@sinodun.com
URI: https://www.sinodun.com/and that's the whole I-DUNNO spec, bestie 🌈💖✨
📦 where this page comes from
- ietf: rfc8771 2020-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms