A Recommendation for IPv6 Address Text Representation
updates
- rfc-4291 — IP Version 6 Addressing Architecture
Extracted elements (19)
For mixed IPv4/IPv6 notation, the recommendation leaves room for future well-known prefixes to be represented in human-friendly dot-decimal form, accepting a tradeoff between strict search-match consistency and readability.
Lowercase was chosen over uppercase for hexadecimal digits because capital letters like D/0 and B/8 are frequently misread, reducing legibility in operational contexts.
RFC 4291's flexible text representation model — allowing leading zeros, optional '::' compression, and mixed case — was identified as the root cause of widespread operational problems including search failures, parsing bugs, audit confusion, and certificate verification errors. A canonical format was needed to eliminate ambiguity.
The '::' is prohibited from shortening a single zero field (Section 4.2.2) because the space savings are minimal and the inconsistency it would introduce outweighs any benefit; omitting leading zeros already handles the single-field case adequately.
Prefix representation problems mirror address representation problems. The text representation method for IPv6 prefixes should follow the same rules as for addresses.
The canonical format defined in this document complies fully with RFC 4291 and is implemented by various operating systems. The FreeBSD 7.0 getnameinfo() with NI_NUMERICHOST and inet_ntop() are cited as conforming reference implementations, except for special addresses in Section 5.
X.509 certificate verification that compares IPv6 address fields as text strings risks false negatives due to differing representations; the common practice and recommendation is to compare IPv6 addresses in binary format rather than text.
All implementations MUST accept and be able to handle any legitimate RFC 4291 format, even though systems SHOULD follow the canonical representation when generating text output.
For IPv4-embedded addresses (IPv4-Mapped, ISATAP, IPv4-translatable), mixed hexadecimal/dot-decimal notation is RECOMMENDED when the address can be distinguished as having IPv4 embedded from the address field alone via a well-known prefix.
For URIs containing IPv6 address literals, RFC 3986 MUST be followed, as well as the canonical representation rules defined in this document.
Leading zeros MUST be suppressed in each 16-bit field. For example, 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16-bit 0000 field MUST be represented as 0.
The hexadecimal characters 'a' through 'f' in an IPv6 address MUST be represented in lowercase.
The style of combining an IPv6 address with a port number as 'address:port' (e.g., 2001:db8::1:80) is NOT RECOMMENDED due to ambiguity. The bracket style [address]:port as specified in RFC 3986 SHOULD be employed.
The '::' symbol MUST be used to its maximum capability to shorten the address. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
The '::' symbol MUST NOT be used to shorten just one 16-bit 0 field. For example, 2001:db8:0:1:1:1:1:1 is correct but 2001:db8::1:1:1:1:1 is not correct.
When there is a choice in placement of '::', the longest run of consecutive 16-bit 0 fields MUST be shortened. When runs are equal length, the first sequence MUST be shortened. For example, 2001:db8::1:0:0:1 is the correct representation of 2001:db8:0:0:1:0:0:1.
Comparing IPv6 addresses in text format for access control purposes is a security risk due to multiple valid representations of the same address. Binary comparison should be used instead; the X.509 certificate example in Section 3.2.5 illustrates how textual comparison can produce incorrect results.
An IPv6 address in canonical text form consists of up to eight colon-separated 16-bit fields in lowercase hexadecimal with no leading zeros, with the longest consecutive run of all-zero fields replaced by '::' (first occurrence wins on ties), and '::' never used to abbreviate a single zero field.
For IPv4-embedded IPv6 addresses with well-known prefixes, the representation mixes leading hexadecimal groups (following Section 4 rules) with dot-decimal notation for the trailing 32 bits; e.g., ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1.