RFC 5952 recommends to use the compressed format for IPv6 address textual representation:
IPv6 addresses in URLs
In resource identifiers like URIs and URLs, the colon (:) character is used to separate the IP address from the port number. As the literal representation of IPv6 addresses contains colon characters, this might cause conflicts. Because of this, literal IPv6 addresses are enclosed in "[" and "]" (square) brackets.
In an URL, the IPv6 address should be enclosed in square brackets [rfc3986]:
IPv6 addresses including a port number
IPv6 addresses with prefix
The prefix is appended to the IPv6 address separated by a slash "/" character (CIDR notation) [rfc4291]:
IPv6 addresses including a zone identifier (zone index)
A zone identifier within an IPv6 address should be specified separated by "%" (percent) character [rfc4007]:
scp file.txt username@[2001:db8:a0b:12f0::1%eth0]/path/
IPv6 addresses in URIs including a zone identifier (zone index)
A zone identifier within an IPv6 address in URIs should be specified separated by "%25" ("%25" is the percent-encoded representation of a literal "%" symbol) [rfc6874]:
RFC 6874 suggests that URI parsers (for example in browsers) accept bare "%" signs when possible:
The IP6.ARPA domain is defined to look up a record given an IPv6 address. The intent of this domain is to provide a way of mapping an IPv6 address to a host name [rfc3596].
The IP6.ARPA address can be formed by the hexadecimal values of an IPv6 address in full notation in reverse order, separated by a dot "." and terminated by the domain "IP6.ARPA".
For example, the IP6.ARPA address of 2001:0db8:0a0b:12f0:0000:0000:0000:0001 would be
Windows UNC (Uniform Naming Convention) path name notation
UNC path names (\\server_ip\share) do not support the colon character. For this reason, Microsoft has created a transcription algorithm to represent IPv6 addresses in UNC path names. Addresses in this notation are directly resolved by Microsoft software without DNS queries. To transcribe an address to this format, replace all colons with dashes (-) and append the second-level domain "ipv6-literal.net" separated by a dot to the address.
The "%" sign to specify a zone index is replaced by an "s" character:
For example, to access the \Misc directory on the server 2001:db8:a0b:12f0::1 use the UNC path \\2001-db8-a0b-12f0--1s4.ipv6-literal.net\Misc.
The integer ID of 2001:db8:a0b:12f0::1 is 42540766414390830568948465903729639425
The hexadecimal ID of 2001:db8:a0b:12f0::1 is 0x20010db80a0b12f00000000000000001
Dotted Decimal ID
The dotted decimal ID of 2001:db8:a0b:12f0::1 is 220.127.116.11.10.11.18.240.0.0.0.0.0.0.0.1
Base 85 ID
The base 85 ID of 2001:db8:a0b:12f0::1 is 9r}Vstbyz7$19|O(~JT0 [rfc1924]
The binary ID of 2001:db8:a0b:12f0::1 is 00100000000000010000110110111000000010100000101100010010111100000000000000000000000000000000000000000000000000000000000000000001
Use a subnet calculator to show more address details.
Fig. 1: IPv6 address processed in GestióIP's online subnet calculator
An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.
An example for an IPv6 unicast address is 3731:54:65fe:2::a7
An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance).
Anycast addresses are allocated from the unicast address space and are not syntactically distinguishable from unicast addresses. Assigning an unicast address to more than one interface makes an unicast address an anycast address. Nodes must be explicitly configured to recognize that an address is an anycast address.
Anycast can be used to increase the avilability and speed of critical servers. All Internet root nameservers are implemented as clusters of hosts using anycast addressing. Anycast is also used by IPv6 transition mechanisms and Content Delivery Networks [rfc7094].
An example for an IPv6 anycast address is 3731:54:65fe:2::a8
An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.
An example for an IPv6 multicast address is FF01:0:0:0:0:0:0:1
There are no broadcast addresses in IPv6, their function being superseded by multicast addresses.
An IPv6 interface is expected to have multiple IPv6 addresses from different scopes associated with it. This is a key difference to IPv4, where an interface has typically only a single address assigned. IPv6 interfaces always have a link local address and typically one or more of a unique local (ULA) or globally unique address.
IANA unicast address assignments are currently limited to the IPv6 unicast address range of 2000::/3 [IANA].
Assignable Global Unicast|
|3731:54:65fe:2::a7||Aggregatable global unicast address format for use in the Internet||[rfc4291][rfc3587]|
|::/128||The unspecified address indicates the absence of an address. One example of its use is in the Source Address field of any IPv6 packets sent by an initializing host before it has learned its own address. It must never be assigned to any node.||[rfc4291]|
|::1/128||The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It must not be assigned to any physical interface. It is treated as having Link-Local scope, and may be thought of as the Link-Local unicast address of a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere||[rfc4291]|
|::ffff:10.0.0.3/96||IPv6 transition mechanism. IPv6 address which contains an embedded 32-bit IPv4 address. IPv4-mapped addresses are used to represent IPv4 addresses using the IPv6 API (e.g., on AF_INET6 sockets). IPv4 packets going to IPv6 applications on a dual-stack node reach their destination because their addresses are mapped by using IPv4-mapped IPv6 addresses.||[rfc4291] [rfc3493][rfc4038][rfc4942]|
IPv4-translatable IPv6 Address|
|64:ff9b::/96 is the Well-Known Prefix (WKP) for IPv4-translatable IPv6 addresses. This type of IPv6 addresses can be assigned to IPv6 nodes for use with stateless translation. They have an explicit mapping relationship to IPv4 addresses. A stateless translator uses the corresponding IPv4 addresses to represent the IPv6 addresses. A stateful translator does not use this kind of addresses, since IPv6 hosts are represented by the IPv4 address pool in the translator via dynamic state. IPv4-translatable IPv6 addresses follow the same format as IPv4-Embedded IPv6 addresses [rfc6052]. See table "Other IPv6 Addresses".||[rfc6144]|
IPv4-translatable IPv6 Address (local use)|
0064:ff9b:0001:1122:0033:4400:0000:0001/48||[rfc8215] reserves 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. This facilitates the coexistence of multiple IPv4/IPv6 translation mechanisms in the same network without requiring the use of a Network-Specific Prefix assigned from the operator's allocated global unicast address space.||[rfc8215]|
Discard-Only Address Block|
|100::/64||Block with the purposes of implementing an IPv6 Remote Triggered Black Hole (RTBH) configuration.||[rfc6666]|
IETF Protocol Assignments|
|Initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned Numbers Authority as an input to the process of developing guidelines for the allocation of IPv6 addresses.||[rfc2928]|
|2001:0000:6dcd:8c74:76cc:63bf:ac32:6a1/64||IPv6 tunneling protocol. Teredo tunneling enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP. Running the service requires the help of "Teredo servers" and "Teredo relays".||[rfc4380]|
Port Control Protocol Anycast|
|2001:1::1/128||The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel.||[rfc7723]|
Traversal Using Relays around NAT Anycast|
|2001:1::2/128||Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.||[rfc8155]|
|2001:0002:cd:65a:753::a1/64||Assigned to the Benchmarking Methodology Working Group (BMWG) for benchmarking IPv6 (corresponding to 198.18.0.0/15 for benchmarking IPv4)||[rfc5108]|
|2001:0003:cd:65a:753::a1/64||Automatic Multicast Tunneling (AMT), is a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.||[rfc7450]|
|2001:4:112:cd:65a:753:0:a1/64||AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.||[raft-ietf-dnsop-as112-dname-06]|
EID Space for LISP (Managed by RIPE NCC)|
|2001:5::/32||For use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.||[rfc7954]|
2001:11::3f4b:1aff:f7b2/28||Deprecated since 2014-03. Overlay Routable Cryptographic Hash Identifiers (ORCHID) is an experimental class of IPv6-address-like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers.||[rfc4843]|
2001:21::3f4b:1aff:f7b2/28||Overlay Routable Cryptographic Hash Identifiers (ORCHID) is a class of IPv6-address-like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm.||[rfc7342]|
2001:db8::a3/64||Used for documentation purpose only.||[rfc3849]|
|2002:6dcd:8c74:6501:fb2:61c:ac98:6be/64||IPv6 tunneling protocol. Connection of IPv6 Domains via IPv4 Clouds. 6to4 uses dedicated relay routers to transport encapsulated IPv6 packets across an IPv4 network. It does not require an explicit tunnel setup. IPv6 packets are encapsulated by adding an IPv4 header with the Protocol field set to 41. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.||[rfc3056]|
Direct Delegation AS112 Service|
|2620:4f:8000::/48||The AS112 project aims to provide a distributed sink for DNS queries for privat addresses in order to reduce the load on the corresponding authoritative servers in the Internet.||[rfc7534]|
Unique Local Addresses (ULAs)|
|fd07:a47c:3742:823e:3b02:76:982b:463/64||IPv6 Unique Local Addresses (Site Local scope) have a globally unique, Well-Known Prefix and are intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. ULAs are comparable to IPv4 private addresses (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16).||[rfc4193]|
|fea3:c65:43ee:54:e2a:2357:4ac4:732/64||Link-Local addresses (Link-Local scope) are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery or when no routers are present. Routers must not forward any packets with Link-Local source or destination addresses to other links.||[rfc4291]|
|::10.0.0.3/96||IPv6 address which contains an embedded 32-bit IPv4 address. An IPv6 address, assigned to an IPv6/IPv4 node, which bears the high-order 96-bit prefix 0:0:0:0:0:0, and an IPv4 address in the low-order 32-bits. IPv4-compatible addresses were used by automatic tunneling; they are now deprecated because the current IPv6 transition mechanisms no longer use these addresses.||[rfc4291]|
::ffff:0:10.0.0.3/96||IPv6 transition mechanism. IPv4-translated Addresses were defined for the Stateless IP/ICMP Translation (SIIT) protocol in RFC 2765. RFC 6145 obsolates RFC 2765 and do not longer mention IPv4-translated Addresses. For various reasons it is not recommended to use this type of addresses. The problem with IPv4-translated addresses is the prefix they use and the structure of the address. For example, the prefix is not generally exchanged in BGP.||[rfc2765]|
IPv4-Embedded IPv6 Address|
64:ff9b::/96 (Well-Known Prefix)
|IPv6 address which contains an embedded 32-bit IPv4 address constructed according to the rules defined in RFC 6052. IPv4-Embedded IPv6 addresses are composed of a variable-length prefix, the embedded IPv4 address, and a variable-length suffix. Bits 64-71 must be set to 0. The IPv6 prefix can either be the IPv6 well-known prefix (ff9b::/96) or a network-specific prefix that is unique to the organization; for the latter case, the IPv6 prefix length must be one of 32, 40, 48, 56, 64, or 96. IPv4-Embedded IPv6 Addresses with a prefix length of /96 (Well-Known Prefix) may alternatively be represented using IPv4 addresses represented in dotted decimal notation.||[rfc6052]|
IPv4-converted IPv6 Address||see IPv4-Embedded IPv6 Address||IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They have an explicit mapping relationship to IPv4 addresses. Both stateless and stateful translators use IPv4-converted addresses to represent IPv4 addresses. IPv4-converted IPv6 addresses follow the same format as IPv4-Embedded IPv6 addresses [rfc6052].||[rfc6144]|
|Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is a mechanism that connects IPv6 hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP interface identifiers are constructed in Modified EUI-64 format ([rfc4291], Appendix A).||[rfc4214]|
SLAAC allows a host to generate its own (global) addresses using a combination of locally available information (e.g. interface's MAC address) and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. The SLACC mechanism is one of the key benefits of IPv6 over IPv4 because it eliminates the need of DHCP or manual configuration.
There are different approaches for creating EUI-64 addresses. An example is an EUI-64 address with embedded MAC address [rfc4862].
IPv6 EUI-64 address's "interface identifier" with embedded MAC addresses are formed by inserting the hex value fffe in the middle of the MAC address and inverting the 7. bit of the MAC address. Here an example of an EUI-64 address created from the MAC address 12:34:56:78:90:00:
IPv6 multicast addresses are limited to scopes. The scopes are determined by the value of the 4th nibble (bits 13-16) of the multicast address (ff0X::/8).
RFC 7346, which updates RFC 4291, defines the following values:
0 - reserved
1 - Interface-Local scope spans only a single interface on a node, and is useful only for loopback transmission of multicast. Packets with interface-local scope received from another node must be discarded.
2 - Link-Local multicast scopes span the same topological region as the corresponding unicast scope.
3 - Realm-Local. The definition of any Realm-Local scope for a particular network technology should be published in an RFC.
4 - Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration.
5 - Site-Local scope is intended to span a single site.
6 and 7 are unasigned
8 - Organization-Local scope is intended to span multiple sites belonging to a single organization.
9 to D are unasigned
E - Global scope.
F - reserved
IPv6 Multicast addresses examples
|FF01:0:0:0:0:0:0:1||Interface-Local scope||All Nodes Address||[rfc2375]|
|FF01:0:0:0:0:0:0:2||Interface-Local scope||All Routers Address||[rfc2375]|
|FF02:0:0:0:0:0:0:1||Link-Local scope||All Nodes Address||[rfc2375]|
|FF02:0:0:0:0:0:0:2||Link-Local scope||All Routers Address||[rfc2375]|
|FF02:0:0:0:0:0:0:12||Link-Local scope||VRRP - Virtual Router Redudancy Protocol||[rfc2375]|
|FF05:0:0:0:0:0:0:101||Site-local scope||All NTP servers||[rfc2375]|
|FF0E:0:0:0:0:0:0:101||Global scope||All NTP servers||[rfc2375]|
For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex), then
FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface (i.e., the same node) as the sender.
FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the sender.
FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the sender.
FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.
Discover all nodes on the same link (link-local scope) using the "All Nodes Address":
ping6 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::74e6:b5f3:fe92:830e eth0: 56 data bytes 64 bytes from fe80::6ae3:b5ff:fe92:330e: icmp_seq=1 ttl=64 time=0.037 ms 64 bytes from fe80::20ab:16d8:a479:238d: icmp_seq=1 ttl=64 time=0.537 ms 64 bytes from fe80::2a1:9bff:fe9b:f268: icmp_seq=1 ttl=64 time=0.545 ms 64 bytes from fe80::1c60:4bff:fa71:1a56: icmp_seq=1 ttl=64 time=0.561 ms 64 bytes from fe80::2a3:aeff:fe53:743e: icmp_seq=1 ttl=64 time=0.565 ms ...
Ping all NTP server on the same site (site-local scope):
ping6 -I eth0 ff05::101 PING ff05::101(ff05::101) from 2001:db8::a:74e6:b5f3:fe92:830e eth0: 56 data bytes 64 bytes from 2001:db8::b:2f4:4bff:fa71:1a56: icmp_seq=1 ttl=64 time=0.561 ms 64 bytes from 2001:db8::c:69b:aeff:fe53:743e: icmp_seq=1 ttl=64 time=0.565 ms ...