RFC 1924 INFORMATIONAL HUMOR · IPV6

Compact IPv6 Addresses: A Compact Representation of IPv6 Addresses

An April Fools joke proposing base-85 encoding for IPv6 addresses

On rfc-editor.org ↗
PUBLISHED
April 1996
AUTHORS
R. Elz
STREAM
INDEPENDENT
ENCODING BASE
Base 85
CHARACTERS NEEDED
20 bytes
DOI
10.17487/RFC1924

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                             R. Elz
Request for Comments: 1924                       University of Melbourne
Category: Informational                                     1 April 1996


               A Compact Representation of IPv6 Addresses

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1. Abstract

   IPv6 addresses, being 128 bits long, need 32 characters to write in
   the general case, if standard hex representation, is used, plus more
   for any punctuation inserted (typically about another 7 characters,
   or 39 characters total).  This document specifies a more compact
   representation of IPv6 addresses, which permits encoding in a mere 20
   bytes.

2. Introduction

   It is always necessary to be able to write in characters the form of
   an address, though in actual use it is always carried in binary.  For
   IP version 4 (IP Classic) the well known dotted quad format is used.
   That is, 10.1.0.23 is one such address.  Each decimal integer
   represents a one octet of the 4 octet address, and consequently has a
   value between 0 and 255 (inclusive).  The written length of the
   address varies between 7 and 15 bytes.

   For IPv6 however, addresses are 16 octets long [IPv6], if the old
   standard form were to be used, addresses would be anywhere between 31
   and 63 bytes, which is, of course, untenable.

   Because of that, IPv6 had chosen to represent addresses using hex
   digits, and use only half as many punctuation characters, which will
   mean addresses of between 15 and 39 bytes, which is still quite long.
   Further, in an attempt to save more bytes, a special format was
   invented, in which a single run of zero octets can be dropped, the
   two adjacent punctuation characters indicate this has happened, the
   number of missing zeroes can be deduced from the fixed size of the
   address.

   In most cases, using genuine IPv6 addresses, one may expect the
   address as written to tend toward the upper limit of 39 octets, as
   long strings of zeroes are likely to be rare, and most of the other
   groups of 4 hex digits are likely to be longer than a single non-zero
   digit (just as MAC addresses typically have digits spread throughout
   their length).

   This document specifies a new encoding, which can always represent
   any IPv6 address in 20 octets.  While longer than the shortest
   possible representation of an IPv6 address, this is barely longer
   than half the longest representation, and will typically be shorter
   than the representation of most IPv6 addresses.

3. Current formats

   [AddrSpec] specifies that the preferred text representation of IPv6
   addresses is in one of three conventional forms.

   The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
   hexadecimal values of the eight 16-bit pieces of the address.

   Examples:

        FEDC:BA98:7654:3210:FEDC:BA98:7654:3210  (39 characters)

        1080:0:0:0:8:800:200C:417A  (25 characters)

   The second, or zero suppressed, form allows "::" to indicate multiple
   groups of suppressed zeroes, hence:

        1080:0:0:0:8:800:200C:417A

   may be represented as

        1080::8:800:200C:417A

   a saving of just 5 characters from this typical address form, and
   still leaving 21 characters.

   In other cases the saving is more dramatic, in the extreme case, the
   address:

        0:0:0:0:0:0:0:0

   that is, the unspecified address, can be written as

        ::

   This is just 2 characters, which is a considerable saving.  However
   such cases will rarely be encountered.

   The third possible form mixes the new IPv6 form with the old IPv4
   form, and is intended mostly for transition, when IPv4 addresses are
   embedded into IPv6 addresses.  These can be considerably longer than
   the longest normal IPv6 representation, and will eventually be phased
   out.  Consequently they will not be considered further here.

4. The New Encoding Format

   The new standard way of writing IPv6 addresses is to treat them as a
   128 bit integer, encode that in base 85 notation, then encode that
   using 85 ASCII characters.

4.1. Why 85?

   2^128 is 340282366920938463463374607431768211456.  85^20 is
   387595310845143558731231784820556640625, and thus in 20 digits of
   base 85 representation all possible 2^128 IPv6 addresses can clearly
   be encoded.

   84^20 is 305904398238499908683087849324518834176, clearly not
   sufficient, 21 characters would be needed to encode using base 84,
   this wastage of notational space cannot be tolerated.

   On the other hand, 94^19 is just
   30862366077815087592879016454695419904, also insufficient to encode
   all 2^128 different IPv6 addresses, so 20 characters would be needed
   even with base 94 encoding.  As there are just 94 ASCII characters
   (excluding control characters, space, and del) base 94 is the largest
   reasonable value that can be used.  Even if space were allowed, base
   95 would still require 20 characters.

   Thus, any value between 85 and 94 inclusive could reasonably be
   chosen.  Selecting 85 allows the use of the smallest possible subset
   of the ASCII characters, enabling more characters to be retained for
   other uses, eg, to delimit the address.

4.2. The Character Set

   The character set to encode the 85 base85 digits, is defined to be,
   in ascending order:

             '0'..'9', 'A'..'Z', 'a'..'z', '!', '#', '$', '%', '&', '(',
             ')', '*', '+', '-', ';', '<', '=', '>', '?', '@', '^', '_',
             '`', '{', '|', '}', and '~'.

   This set has been chosen with considerable care.  From the 94
   printable ASCII characters, the following nine were omitted:

      '"' and "'", which allow the representation of IPv6 addresses to
      be quoted in other environments where some of the characters in
      the chosen character set may, unquoted, have other meanings.

      ',' to allow lists of IPv6 addresses to conveniently be written,
      and '.' to allow an IPv6 address to end a sentence without
      requiring it to be quoted.

      '/' so IPv6 addresses can be written in standard CIDR
      address/length notation, and ':' because that causes problems when
      used in mail headers and URLs.

      '[' and ']', so those can be used to delimit IPv6 addresses when
      represented as text strings, as they often are for IPv4,

      And last, '\', because it is often difficult to represent in a way
      where it does not appear to be a quote character, including in the
      source of this document.

5. Converting an IPv6 address to base 85.

   The conversion process is a simple one of division, taking the
   remainders at each step, and dividing the quotient again, then
   reading up the page, as is done for any other base conversion.

   For example, consider the address shown above

        1080:0:0:0:8:800:200C:417A

   In decimal, considered as a 128 bit number, that is
   21932261930451111902915077091070067066.

   As we divide that successively by 85 the following remainders emerge:
   51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70,
   68, 4.

   Thus in base85 the address is:

        4-68-70-46-66-12-63-31-61-19-4-37-53-75-0-58-57-65-34-51.

   Then, when encoded as specified above, this becomes:

        4)+k&C#VzJ4br>0wv%Yp

   This procedure is trivially reversed to produce the binary form of
   the address from textually encoded format.

6. Additional Benefit

   Apart from generally reducing the length of an IPv6 address when
   encode in a textual format, this scheme also has the benefit of
   returning IPv6 addresses to a fixed length representation, leading
   zeroes are never omitted, thus removing the ugly and awkward variable
   length representation that has previously been recommended.

7. Implementation Issues

   Many current processors do not find 128 bit integer arithmetic, as
   required for this technique, a trivial operation.  This is not
   considered a serious drawback in the representation, but a flaw of
   the processor designs.

   It may be expected that future processors will address this defect,
   quite possibly before any significant IPv6 deployment has been
   accomplished.

8. Security Considerations

   By encoding addresses in this form, it is less likely that a casual
   observer will be able to immediately detect the binary form of the
   address, and thus will find it harder to make immediate use of the
   address.  As IPv6 addresses are not intended to be learned by humans,
   one reason for which being that they are expected to alter in
   comparatively short timespan, by human perception, the somewhat
   challenging nature of the addresses is seen as a feature.

   Further, the appearance of the address, as if it may be random
   gibberish in a compressed file, makes it much harder to detect by a
   packet sniffer programmed to look for bypassing addresses.

9. References

   [IPv6]        Internet Protocol, Version 6 (IPv6) Specification,
                 S. Deering, R. Hinden, RFC 1883, January 4, 1996.

   [AddrSpec]    IP Version 6 Addressing Architecture,
                 R. Hinden, S. Deering, RFC 1884, January 4, 1996.

10. Author's Address

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Victoria, 3052
   Australia

   EMail: kre@munnari.OZ.AU

AI ELI5

On this page
PROBLEMIPv6 addresses are 128 bits, requiring 32 hex digits plus punctuation—up to 39 characters—which is cumbersome to write.
MECHANISMThis RFC (published April 1, 1996) proposes treating the address as a single 128-bit integer, encoding it in base 85, and representing it in 20 bytes using a special 85-character set. The character set avoids punctuation that conflicts with common syntax (quotes, slashes, colons, brackets).
AN APRIL FOOLS PRANKA mathematically sound but impractical joke; the encoding reduces length but is unreadable and requires 128-bit arithmetic.

§1The Setup

This RFC is an April Fools joke, published on 1 April 1996. It proposes encoding IPv6 addresses using base-85 notation, which would reduce them from up to 39 characters to exactly 20 characters. While the math is correct and the spec is detailed, it is not intended as a serious proposal and was never adopted.

The author's tone is deadpan; the document is phrased as a serious technical specification, building humor through false earnestness.

This is a funny April Fools joke where someone pretended to solve the problem of long IPv6 addresses by making them into nonsense strings.

§2How the Encoding Works

The scheme treats a 128-bit IPv6 address as a single integer and converts it to base 85. Since 85^20 is large enough to represent all 2^128 possible addresses, exactly 20 characters suffice. Base 85 was chosen as the smallest base that fits in 20 characters (base 84 would need 21; base 94 is the maximum using printable ASCII).

The character set includes digits, letters, and special characters—omitting quotes, commas, periods, slashes, colons, brackets, and backslashes so the address can appear in quotes or CIDR notation. An example address 1080:0:0:0:8:800:200C:417A encodes as 4)+k&C#VzJ4br>0wv%Yp.

Take the whole IPv6 address as one huge number, convert it to base 85, and you get 20 weird characters. It works mathematically but looks like gibberish.

§3Why This Is a Joke

The RFC treats real problems seriously (IPv6 addresses are long; humans don't learn them) but proposes an absurd solution. The resulting strings are unreadable; the scheme requires 128-bit integer arithmetic, which was not trivial in 1996; and readability is lost entirely. The author notes that the obscurity might even be a security feature—an address in base-85 looks like random gibberish to a packet sniffer.

The joke works because it is technically sound but practically useless, mirroring the earnest-but-absurd tone of some real RFC specifications.

It's a funny idea because it technically works but nobody could actually use it. Writing addresses as 4)+k&C#VzJ4br>0wv%Yp is worse than writing them the normal way.

§4References