# net.ipv6
Parse IPv6 text to its eight 16-bit groups, write groups back as the one
canonical text RFC 5952 defines, and check text without raising. The
canonical form of any address is `formatIpv6(parseIpv6(text))`.
## Why canonical text matters
`2001:DB8:0:0:1:0:0:1`, `2001:db8::1:0:0:1` and `2001:0db8:0:0:1::1` are the
same address. Compare them as text, log them, or use them as a map key, and
they are three. RFC 5952 fixes one spelling:
- lower-case hex, no leading zeros in a group;
- the longest run of two or more zero groups becomes `::`; on a tie the first
run; a single zero group is written `0`, never `::`;
- an IPv4-mapped address (`::ffff:0:0/96`) keeps its dotted-quad tail
(`::ffff:192.0.2.128`), as section 5 recommends. Other prefixes that can
carry IPv4 (the deprecated `::a.b.c.d` compatible form, `64:ff9b::/96`) are
written in hex; the parser accepts a dotted tail on any of them.
## What parses
RFC 4291 section 2.2 text: one to four hex digits per group in either case,
at most one `::` (standing for at least one zero group), and optionally a
dotted IPv4 address, following `net.ipv4`'s strict rules, as the last 32 bits.
Refused: a zone id (`fe80::1%eth0`, RFC 4007: it names an interface, it is not
part of the address), a prefix (`/64`, see `net.cidr`), brackets, whitespace
and non-ASCII digits.
`ipv6Groups` (`ipv6_groups`) is exported for sibling capabilities that want
"groups or null"; it is not part of the contract.
Sources: RFC 4291 (IP Version 6 Addressing Architecture) section 2.2;
RFC 5952 (A Recommendation for IPv6 Address Text Representation) sections 4
and 5.