The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
RFC 8771

Document Type RFC - Experimental (April 2020; No errata)
Last updated 2020-04-01
Stream ISE
Formats plain text html xml pdf htmlized bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 8771 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)


Independent Submission                                      A. Mayrhofer
Request for Comments: 8771                                   nic.at GmbH
Category: Experimental                                          J. Hague
ISSN: 2070-1721                                                  Sinodun
                                                            1 April 2020

The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)

Abstract

   Domain Names were designed for humans, IP addresses were not.  But
   more than 30 years after the introduction of the DNS, a minority of
   mankind persists in invading the realm of machine-to-machine
   communication by reading, writing, misspelling, memorizing,
   permuting, and confusing IP addresses.  This memo describes the
   Internationalized Deliberately Unreadable Network NOtation
   ("I-DUNNO"), a notation designed to replace current textual
   representations of IP addresses with something that is not only more
   concise but will also discourage this small, but obviously important,
   subset of human activity.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  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/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 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
   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' Addresses

1.  Introduction

   In Section 2.3 of [RFC0791], 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 [RFC1034], 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 [RFC1034]).  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
   [RFC1123].  Subsequently, a directed effort to further discourage
   human use by making IP addresses more confusing was introduced in
   [RFC1883] (which was obsoleted by [RFC8200]), and additional options
   for human puzzlement were offered in Section 2.2 of [RFC4291].  These
   noble early attempts to hamper efforts by humans to read, understand,
   or even spell IP addressing schemes were unfortunately severely
   compromised in [RFC5952].

   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.
Show full document text