In Section 2.3
of RFC 0791
, the original designers of the Internet Protocol carefully defined names and addresses as separate quantities. While they did not explicitly reserve names for human consumption and addresses for machine use, they did consider the matter indirectly in their philosophical communal statement: "A name indicates what we seek." This clearly indicates that names rather than addresses should be of concern to humans.
The specification of domain names in [RFC 1034
], and indeed the continuing enormous effort put into the Domain Name System, reinforces the view that humans should use names and leave worrying about addresses to the machines. RFC 1034
mentions "users" several times, and even includes the word "humans", even though it is positioned slightly unfortunately, though perfectly understandably, in a context of "annoying" and "can wreak havoc" (see Section 5.2.3
of RFC 1034
). Nevertheless, this is another clear indication that domain names are made for human use, while IP addresses are for machine use.
Given this, and a long error-strewn history of human attempts to utilize addresses directly, it is obviously desirable that humans should not meddle with IP addresses. For that reason, it appears quite logical that a human-readable (textual) representation of IP addresses was just very vaguely specified in Section 2.1
of RFC 1123
. Subsequently, a directed effort to further discourage human use by making IP addresses more confusing was introduced in [RFC 1883
] (which was obsoleted by [RFC 8200
]), and additional options for human puzzlement were offered in Section 2.2
of RFC 4291
. These noble early attempts to hamper efforts by humans to read, understand, or even spell IP addressing schemes were unfortunately severely compromised in [RFC 5952
In order to prevent further damage from human meddling with IP addresses, there is a clear urgent need for an address notation that replaces these "Legacy Notations", and efficiently discourages humans from reading, modifying, or otherwise manipulating IP addresses. Research in this area long ago recognized the potential in ab^H^Hperusing the intricacies, inaccuracies, and chaotic disorder of what humans are pleased to call a "Cultural Technique" (also known as "Script"), and with a certain inexorable inevitability has focused of late on the admirable confusion (and thus discouragement) potential of [UNICODE
] as an address notation. In Section 4
, we introduce a framework of Confusion Levels as an aid to the evaluation of the effectiveness of any Unicode-based scheme in producing notation in a form designed to be resistant to ready comprehension or, heaven forfend, mutation of the address, and so effecting the desired confusion and discouragement.
The authors welcome [RFC 8369
] as a major step in the right direction. However, we have some reservations about the scheme proposed therein:
Our analysis of the proposed scheme indicates that, while impressively concise, it fails to attain more than at best a Minimum Confusion Level in our classification.
Humans, especially younger ones, are becoming skilled at handling emoji. Over time, this will negatively impact the discouragement factor.
The proposed scheme is specific to IPv6; if a solution to this problem is to be in any way timely, it must, as a matter of the highest priority, address IPv4. After all, even taking the regrettable effects of RFC 5952 into account, IPv6 does at least remain inherently significantly more confusing and discouraging than IPv4.
This document therefore specifies an alternative Unicode-based notation, the Internationalized Deliberately Unreadable Network NOtation (I-DUNNO). This notation addresses each of the concerns outlined above:
I-DUNNO can generate Minimum, Satisfactory, or Delightful levels of confusion.
As well as emoji, it takes advantage of other areas of Unicode confusion.
It can be used with IPv4 and IPv6 addresses.
We concede that I-DUNNO notation is markedly less concise than that of RFC 8369
. However, by permitting multiple code points in the representation of a single address, I-DUNNO opens up the full spectrum of Unicode-adjacent code point interaction. This is a significant factor in allowing I-DUNNO to achieve higher levels of confusion. I-DUNNO also requires no change to the current size of Unicode code points, and so its chances of adoption and implementation are (slightly) higher.
Note that the use of I-DUNNO in the reverse DNS system is currently out of scope. The occasional human-induced absence of the magical one-character sequence U+002E is believed to cause sufficient disorder there.
Media Access Control (MAC) addresses are totally out of the question.