]> Ertl Software Productions

An Peschbenden 13 47906 Kempen NRW DE +49 2152 53286 marcus.ertl@gmx.net

Transport Internet Engineering Task Force ip6ipv6ipvanityaddressing 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

New display and entry format for IPv6 addresses Instead of the current hextet format, separated by colons, IPv6 addresses as defined by MAY be displayed and entered as a sequence of UTF-8 characters as defined in . 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 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)
• 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)
• 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.

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.

IANA Considerations This memo includes no request to IANA.

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), .
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.

References Normative References Informative References

Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz.