RFC 1924

RFC 1924: A Compact Representation of IPv6 Addresses ✨

okay bestie, let's get the facts straight first 🎀 This is Network Working Group Request for Comments 1924, written by R. Elz (Robert Elz) from the University of Melbourne and dated 1 April 1996. It's Category: Informational, so it's giving "here's some good info," not a rulebook 💅. The title block doesn't list anything it obsoletes or updates 🦋.

---

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 are 128 bits long, so they need 32 characters in standard hex, plus extra punctuation (usually about 7 more, for 39 characters total) 😭. This document defines a more compact way to write them that fits in just 20 bytes ✨.

2. Introduction 💅

Okay so, we always have to be able to write an address out as characters, even though in real life it's always carried in binary 🤓. For IP version 4 (IP Classic), we use the well-known dotted quad format. For example, 10.1.0.23 is one of these addresses. Each decimal number is one octet of the 4-octet address, so it's between 0 and 255 (inclusive). The written length is between 7 and 15 bytes 🦋.

IPv6 addresses are 16 octets long [IPv6]. If we used the old standard form, they'd be anywhere between 31 and 63 bytes, which is, of course, untenable 💀.

So IPv6 went with hex digits and only half as many punctuation characters, which means addresses are between 15 and 39 bytes. That's still quite long 🥲. To save even more bytes, there's a special format where a single run of zero octets can be dropped. Two adjacent punctuation characters show that this happened, and the number of missing zeroes can be figured out from the fixed size of the address ✨.

With real IPv6 addresses, you'd expect the written address to lean toward the upper limit of 39 characters. Long strings of zeroes are probably rare, and most groups of 4 hex digits will be longer than a single non-zero digit. It's like how MAC addresses have digits spread all over their length 🌈.

This document specifies a new encoding that can always represent any IPv6 address in 20 octets 👑. It's longer than the shortest possible representation of an IPv6 address, but it's barely longer than half the longest one, and it'll usually be shorter than most IPv6 addresses 🔥.

3. Current formats 🧚

[AddrSpec] says the preferred text representation of IPv6 addresses is one of three conventional forms 🎀.

The preferred form is x:x:x:x:x:x:x:x, where each x is the hexadecimal value of one 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 form, the zero-suppressed one, lets :: stand in for multiple groups of suppressed zeroes. So:

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

can be written as

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

That's a saving of just 5 characters from this typical address form, and it still leaves 21 characters 🍓.

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

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

which is the unspecified address, can be written as

::

That's just 2 characters, which is a considerable saving 🤯. Honestly though, cases like this will rarely come up 🙈.

The third form mixes the new IPv6 form with the old IPv4 form. It's mostly meant for transition, when IPv4 addresses are embedded into IPv6 addresses. These can be considerably longer than the longest normal IPv6 representation, and they'll eventually be phased out 🌸. So we won't be looking at them any further here 💅.

4. The New Encoding Format 💜

The new standard way to write IPv6 addresses is to treat them as a 128-bit integer, encode that in base 85 notation, and then encode the result using 85 ASCII characters ✨.

4.1. Why 85? 🤔

2^128 is 340282366920938463463374607431768211456. 85^20 is 387595310845143558731231784820556640625, so in 20 digits of base 85 we can clearly encode all 2^128 possible IPv6 addresses 🦋.

84^20 is 305904398238499908683087849324518834176, which clearly isn't enough. You'd need 21 characters to encode in base 84, and this wastage of notational space just cannot be tolerated 💀.

On the other hand, 94^19 is just 30862366077815087592879016454695419904, which also isn't enough to encode all 2^128 different IPv6 addresses. So you'd need 20 characters even with base 94 encoding. There are just 94 ASCII characters (excluding control characters, space, and del), so base 94 is the largest reasonable value to use. Even if space were allowed, base 95 would still need 20 characters 🔥.

So any value between 85 and 94 inclusive could reasonably be chosen. Picking 85 lets us use the smallest possible subset of the ASCII characters. That leaves more characters free for other uses, like delimiting the address 🎀.

4.2. The Character Set 🌈

The character set for encoding the 85 base-85 digits is defined to be, in ascending order:

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

This set was chosen with considerable care 🫶. From the 94 printable ASCII characters, these nine were left out:

• '"' and "'", which let an IPv6 address be quoted in other environments where some of the characters in the chosen set might have other meanings when unquoted 🙈.
• , so lists of IPv6 addresses can be written easily, and . so an IPv6 address can end a sentence without needing quotes 📝.
• / so IPv6 addresses can be written in standard CIDR address/length notation, and : because it causes problems in mail headers and URLs 😭.
• [ and ], so they can delimit IPv6 addresses when they're represented as text strings, the way they often are for IPv4 🌸.
• And last, \, because it's hard to represent in a way that doesn't look like a quote character, including in the source of this document 💀.

5. Converting an IPv6 address to base 85. 🧮

The conversion is a simple process of division. You take the remainders at each step, divide the quotient again, and then read up the page, just like any other base conversion 🤓.

For example, take the address from before:

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

Treated as a 128-bit number, in decimal, that's 21932261930451111902915077091070067066 🔢.

When we divide that successively by 85, these remainders come out:

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

So in base 85, the address is:

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

And when it's encoded as described above, it becomes:

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

Reversing this is trivial, and it gives you the binary form of the address from the textual encoded format ✨.

6. Additional Benefit 💖

Apart from generally shortening an IPv6 address when it's written in text, this scheme also gives IPv6 addresses a fixed-length representation 💎. Leading zeroes are never omitted. That gets rid of the ugly, awkward variable-length format that was recommended before 👑.

7. Implementation Issues 🛠️

Lots of current processors don't find 128-bit integer arithmetic, which this technique needs, to be a trivial operation 😅. That's not considered a serious drawback of the representation. It's a flaw in the processor designs 💅.

It's expected that future processors will fix this defect, quite possibly before any significant IPv6 deployment is done 🚀.

8. Security Considerations 🔐

⚠️ Serious security note, bestie: this section is about how hard addresses are to read and find.

By encoding addresses in this form, it's less likely that a casual observer will immediately be able to detect the binary form of the address. That makes it harder to make immediate use of the address 🕵️. IPv6 addresses aren't meant to be learned by humans. One reason is that they're expected to change within a comparatively short timespan, as far as human perception goes. So the somewhat challenging nature of the addresses is seen as a feature 🙃.

Further, because the address looks like it might just be random gibberish in a compressed file, it's much harder for a packet sniffer programmed to look for bypassing addresses to detect it 🥷.

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 🦋