IPv6 uses a 128 bit address - in order to make this human readable the 128 bits are divided up into 32 of 4 bit sections, and a hexadecimal number is used to quantify each 4 bit section.
The 32 hexadecimal numbers are divided up into 8 groups of 4 hexadecimal numbers seperated by colons.
The alphabetical characters in the hexadecimal numbers should always be written in lower case.
So an IPv6 address looks like -
2001:0db8:ac10:27bc:01af:0000:3456:789a
There are two rules which allow this address to be shortened -
The first is that leading zero`s in each group can be omitted - so this address can be written as
2001:db8:ac10:27bc:1af:0:3456:789a
The second is that a group of all zero`s can be omitted and replaced with a double colon - so this address can be written as
2001:db8:ac10:27bc:1af::3456:789a
This can be done with multiple adjacent groups of zeros - so the address
2001:0db8:ac10:27bc:01af:0000:0000:0000
can be written as
2001:db8:ac10:27bc:1af::
But this can only be done once in any address as otherwise the address becomes indeterminant.
Like the use of IPv4 Classless Inter-Domain Routing (CIDR) notation, IPv6 can use address prefixes to indicate how many of the leftmost bits of the address comprise the prefix.
So an IPv6 address becomes ipv6-address/prefix-length - so for example the above address could become
2001:0db8:ac10:27bc:01af:0000:0000:0000/48
or
2001:db8:ac10:27bc:1af::/48
The documentation address is a reserved address that should be used within documentation as an example IPv6 address - starts with 2001:0db8:
In IPv6 there are three distinct types of address - unicast, anycast and multicast.
This is different from ipv4 in which there are three types of address - unicast, multicast, and broadcast.
IPv6 doesn`t use specific broadcast addresses - but the functionality of broadcast addresses is performed by a particular type of multicast address.
There are several types of unicast address some of which are shown below.
Global unicast
Global unicast addresses are similar to public addresses in ipv4 - global unicast addresses always start with 2001:
In Global unicast addresses the 128 bit address is usually divided up into three sections -
the first section - usually 48 bits - is the Global Routing Prefix - that is - the internet network adddress
the second section - usually 16 bits - is the Subnet ID - used for the identity of subnets within the organisation
the third section - usually 64 bits - is the Interface ID - used to uniquely identify each device or interface on the subnet
RFC4291 stipulates that Interface IDs are required to be 64 bits long on all Unicast addresses except those beginning with binary 000.
Unique local
Unique local addresses are similar to the private addresses of 10.0.0.0/8 and 192.168.0.0/16 in ipv4 - unique local addresses always start with fc--: or fd--:
Routable within an organisation, but shouldn`t ever see the internet.
In Unique local addresses the 128 bit address is divided up into four sections -
the first section is 8 bits - it is the prefix which gives fc--: or fd--:
the second section is 40 bits - it is somewhat confusingly known as the Global ID
the third section is 16 bits - it is the Subnet ID - used for the identity of subnets within the organisation
the fourth section is 64 bits - it is the Interface ID - used to uniquely identify each device or interface on the subnet
There is a rather complicated algorithm which should be used to create the Global ID part of the Unique local address - by using this algorithm the Global ID address will end up as a unique address.
Although in theory Unique local addresses can start with fc--: or fd--:, in practice it is more complicated than that - the eighth bit is defined as a flag -
if it is a zero this means the address will start with fc--: - but the meaning of the flag hasn`t been defined, so shouldn`t be used.
if it is a one this means the address will start with fd--: - and this state of the flag means the address had been locally assigned.
So effectively Unique local addresses will always start with fd--:
Link local
Link local addresses are somewhat similar to 169.254.0.0/16 in ipv4 if there is no dhcp.
They are created by the network interface to uniquely identify that interface - not routed, they only exist on the local network - always start with fe80:
To be an active IPv6 interface an interface must have a Link local address - an interface can have a Global unicast address or Unique local unicast address as well as a Link local address.
Link-Local addresses have the following format:
the first ten bits have the value of binary 1111111010
the next 54 bits are all zeroes
the last 64 bits are the interface ID
Site local
Site-Local addresses were originally designed to be used for addressing inside of a site without the need for a global prefix.
Site-local addresses are now deprecated but can be continued to be used in existing installations
Site-Local addresses have the following format:
the first ten bits have the value of binary 1111111011
the next 54 bits are the subnet ID
the last 64 bits are the interface ID
Loopback address
The loopback address is similar to 127.0.0.0 in ipv4 - the full IPv6 loop back address is
0000:0000:0000:0000:0000:0000:0000:0001
Using the rules above this can be written as ::1 - or maybe more correctly as ::1/128
The loopback address cannot be assigned to an interface.
A packet arriving at an interface with a loopback address must be dropped.
Routers will not forward packets with a loopback address.
A packet with a loopback address should never leave the device.
Unspecified address
The unspecified address has the full IPv6 address of
0000:0000:0000:0000:0000:0000:0000:0000
Using the rules above this can be written as :: - or maybe more correctly as ::/128.
It can be used by an initializing host as the source address of any IPv6 packets sent by the host before it has learned its own address.
It cannot be assigned to an interface and it cannot be used as a destination address.
Routers will not forward packets with an unspecified address.
IPv4 embedded address
This is an IPv6 address that has an IPv4 address embedded in it - there are two forms of IPv4 embedded addresses -
IPv4-Compatible IPv6 Addresses
IPv4-Compatible IPv6 Addresses are assigned to devices that are both IPv6 and IPv4 capable -
the first 80 bits of the IPv6 address are all zeroes
the next 16 bits are all zeroes
the last 32 bits are the IPv4 address written in the standard IPv4 form of dotted decimal notation.
So an IPv4-Compatible IPv6 address looks like
0000:0000:0000:0000:0000:0000:IPv4 address
or
::IPv4 address.
According to IANA and RFC4291 the IPv4-Compatible IPv6 address is now deprecated because the current IPv6 transition mechanisms no longer use these addresses.
IPv4 Mapped IPv6 Addresses
IPv4 Mapped IPv6 Addresses - are assigned to devices that are only IPv4 compatible
the first 80 bits of the IPv6 address are all zeroes
the next 16 bits are all ones
the last 32 bits are the IPv4 address written in the standard IPv4 form of dotted decimal notation.
So an IPv4 mapped IPv6 address looks like
0000:0000:0000:0000:0000:ffff:IPv4 address
or
::ffff:IPv4 address.
There are three ways that an interface can be given an Interface ID
Manually
Just as was often done with IPv4 - can be administratively time consuming but quite feasible for smaller installations - often done for servers in smaller data centres.
One advantage of this method is that the alphabetic characters a - f can be used to create names.
Modified EUI-64
Modified EUI-64 is a defined procedure to use MAC addresses to create interface ID`s - MAC addesses are unique for each network card, so the resultant interface ID`s would also be unique.
The procedure is not intuitive - first of all the twelve heaxadecimal characters of the MAC address are split into two, and four additional hexadecimal characters - ff and fe - are inserted in the middle. This expands the 48 MAC address bits up to the 64 bits used in IPv6 interface ID`s.
So a 48 bit MAC address such as 12-34-56-78-9a-bc
becomes a 64 bit word of 12-34-56-ff-fe-78-9a-bc
Then bit 7 of the resultant 64 bit word is flipped from a zero to a one or from a one to a zero.
So the 64 bit word becomes 10-34-56-ff-fe-78-9a-bc
and is written as 1034:56ff:fe78:9abc
This is now the interface ID.
So a full IPv6 address would look like
fe08:0db8:abcd:abcd:1034:56ff:fe78:9abc/64
This procedure is now deprecated because of security issues - the use of the interface ID derived from the MAC address made it too easy to track a device through the internet.
Random ID`s
Random ID`s are created by a defined algorithm that involves time as an input and also an MD5 hash - RFC 4941 describes this in detail.
Random ID`s change every few hours or days, so this makes tracking the device more difficult.
They are now used in preference to modified EUI-64 derived ID`s.
----------------------------
IPv6 keeps on changing and it looks like - but it is by no means certain - that in the early days of IPv6 interfaces calculated their own interface ID`s using modified EUI-64, and IPv6 DHCP provided only the network prefix.
Then when modified EUI-64 was deprecated, IPv6 DHCP was changed so that it could provide the whole 128 bit address.
Some websites suggest that only the network prefix is provided, but RFC 8415 suggests that an IPv6 DHCP server can provide the whole address - paragraphs 6.2 and 6.5 are particularily relevant.
Anycast addresses are unicast addresses that are assigned to more than one interface - usually the interfaces are on different devices.
Routers send the data packets to one of the interfaces - the routers send the packets to the nearest interface, decided by the routing protocol involved.
The devices being given an anycast address must be specifically programmed to know they are anycast addresses.
Anycast addresses have the same formats as unicast addresses, and look just the same.
Anycast addresses must not be used as the source address of an IPv6 packet.
Anycast requires that the routers are specifically configured to know about Anycast.
Anycast technology isn`t covered well in websites about IPv6, even RFC 4291 doesn`t cover it in any depth.
Multicast addresses in IPv6 are a lot more complicated than Unicast addresses because there are a lot of different types of multicast address.
Multicast addressing in IPv6 is basically similar to multicasting in IPv4 - in IPv4 multicast uses the address range of 224.0.0.0/4 - so they range from 224.0.0.0 through to 239.255.255.255.
An IPv6 multicast address defines a group of devices known as a multicast group, and is always a destination address, never a source address.
Data sent to a multicast group always has a unicast source address as it comes from a single device.
Multicast is very dependent on router configuration and needs specific multicast related router configuration to work - particularily rendezvous points.
Multicast also requires Protocol Independent Multicast - or PIM - a family of routing protocols that sit above the core routing protocol.
-----------------------
There seems to be two distinct variations in the construction of a multicast address in IPv6 - some websites describe it as
the first 8 bits are all ones - so multicast addresses always start with ff--:
the next four bits are a set of flags - the first three flags are reserved, and always set to zeroes - if the fourth flag is set to zero then it is indicates the address is a permanent or well known multicast address - if the fourth flag is set to one then it indicates the address is a transient multicast address
the next four bits indicate the scope of the address - that is how much physical network the multicast address covers - ranging from a single device through subnets, organisational networks, up to the global internet
the last 112 bits are the Group ID of the multicast address
Other websites describe the construction of a multicast address as follows :-
the first 8 bits are all ones - so multicast addresses always start with ff--:
the next four bits are the same flags as above, but they all now have a function
the next four bits are the scope as above
the next four bits are another set of flags reserved for future use
the next four bits are reserved for future use
the next eight bits indicate the number of bits in the network prefix field
the next 64 bits indicate the network prefix
the last 32 bits indicate the Group ID of the multicast address
Here are the decimal values of the 4 bit Scope field as defined by IANA :-
0 -- reserved
1 -- single device
2 -- subnet or Link local scope
3 -- realm local
4 -- admin local
5 -- site network
6 --
7 --
8 -- organisation wide network
9 --
10 --
11 --
12 --
13 --
14 -- global wide
15 -- reserved
There are a number of reserved multicast addresses which should never be assigned to a multicast group.
There are sixteen addresses all with the form
ff0X:0000:0000:0000:0000:0000:0000:0000
in which X is each of the sixteen hexadecimal values from 0 to f.
IANA publishes quite long lists of well known or permanently assigned multicast addresses and can be seen on the IANA website.
Two worth noting are -
ff02::1
the multicast address with the form
ff02:0000:0000:0000:0000:0000:0000:0001 - or ff02::1
is the IPv6 equivalent of the broadcast address in IPv4.
ff02::2
the multicast address with the form
ff02:0000:0000:0000:0000:0000:0000:0002 - or ff02::2
is the IPv6 equivalent of the multicast address in IPv4.
Solicited-node multicast addresses can be used in a similar way to ARP and broadcasts in IPv4 for layer 3 to layer 2 address resolution - this is done using Neighbor Discovery Protocol.
They are automatically created using a mapping of the last 24 bits of a device’s unicast address or anycast address to the last 24 bits of the solicited-node multicast prefix to create
ff02:0000:0000:0000:0000:0001:ff00:0000/104.
This means that solicited-node multicast addresses have the range of values between
ff02:0000:0000:0000:0000:0001:ff00:0000
and
ff02:0000:0000:0000:0000:0001:ffff:ffff.
Solicited-node multicast addresses are automatically created for every unicast address and anycast address on a device.
----------------------------
The 24 bits comes from the concept that a unicast address of a device uses the MAC address of the network card to create the Interface ID part of the unicast address, and the last 24 bits of a MAC address are unique for each network card - so a solicited-node multicast address uniquely identifies an interface - ie, the network card.
So what happens with anycast - as each device with the same anycast address will have a different network card and hence a different MAC address.
And what happens now that using the MAC address to create the Interface ID using the modified EUI-64 format is now deprecated ?
A rendezvous point is a router that acts as the place where sources and receivers of multicast data can find each other.
A device which is the source of the multicast traffic sends its data to the rendezvous point - the rendezvous point then distributes the data to the devices that want to receive it.
A router has to be specifically configured to be a rendezvous point.
Protocol Independent Multicast is a family of routing protocols that make multicasting possible - they sit above the normal routing protocols and use the routing provided by them - it doesn`t matter what type of normal routing protocol is being used.
Protocol Independent Multicast is often known as PIM.
IPv6 multicast can use either a PIM-Sparse Mode (PIM-SM) or PIM-Source Specific Multicast (PIM-SSM) operation, or both PIM-SM and PIM-SSM can be used together.
PIM-SM
PIM-Sparse Mode is used in a multicast network when relatively few devices are involved in each multicast and these devices do not forward multicast packets for a group, unless there is an explicit request for the traffic.
PIM-SSM
PIM-Source Specific Multicast is the routing protocol that supports the implementation of SSM and is derived from PIM-SM.
PIM-SSM requires the protocol Multicast Listener Discovery version 2 to be operating.
In very basic terms, devices that are interested in receiving data flowing to a particular multicast group must join the group by signaling their local router - this is done using the protocol called Multicast Listener Discovery.
More technically, Multicast Listener Discovery is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4.
The protocol is embedded in ICMPv6 instead of using a separate protocol.
Multicast Listener Discovery version 1 is similar to IGMPv2 and Multicast Listener Discovery version 2 is similar to IGMPv3.
The protocol specifically discovers which multicast addresses are of interest to its neighboring nodes and provides this information to the active multicast routing protocol that makes decisions on the flow of multicast data packets.
Multicast Listener Discovery version 2 is supported on modern versions of Windows, Linux, and MacOS.
IPv6 doesn`t use ARP as is used in IPv4.
Instead it uses Neighbor Discovery Protocol to perform a number of network functions at the Layer 2 level using various message types of ICMPv6 - including a replacement for ARP
The functions it performs include :-
----------------------------
Neighbor Discovery Protocol uses ICMPv6 messages to perform all its functions - there are five different message types used :-
NB - some websites say that a Neighbor Solicitation message is requesting the MAC address of the remote host - it looks like the MAC address is one type of link-layer address.
----------------------------
Neighbor Discovery Protocol maintains four caches or lists in each device :-
Neighbor cache
The neighbor cache is similar to the ARP cache in IPv4 - it lists the neighbours to the device and maintains a table of the ip addresses and the MAC addresses.
The contents of the cache can be viewed on Windows using the command :-
netsh interface ipv4 show neighbors
or
netsh interface ipv6 show neighbors
for IPv4 and IPv6 respectively.
On Linux using the command :-
ip -4 neigh
or
ip -6 neigh
for IPv4 and IPv6 respectively.
Destination cache
The destination cache lists the addresses used for delivering or forwarding IPv6 packets to their destinations. The entries in the cache could refer to the actual destination if it is located on the local subnet, or to the next-hop address.
The contents of the cache can be viewed on Windows using the command :-
netsh interface ipv6 show destinationcache
Default Router List
The default router list includes all known routers that regularly contact the device. Only active routers are listed because the expiration date is automatically defined for all representatives.
The contents of the cache can be viewed on Windows using the command :-
netsh interface ipv6 show potentialrouters
Prefix cache
The prefix cache or list is used to manage all prefixes that apply to the network where the client resides.
----------------------------
I haven`t found a Windows tool that allows the contents of the prefix cache to be viewed.
I haven`t found any Linux tools that allow the contents of the destination cache, the default router list, or the prefix cache to be viewed.
However the following commands that are provided through iproute2 may provide some relevant information - as shown on the ip man page :-
There are also a number of other Linux tools which are of relevance to IPv6 in general and to NDP in particular - they include the following, but there are probably more :-
ndptool
Neighbor Discovery Protocol tool is a Linux tool which is related to Neighbor Discovery Protocol messages.
It has a number of options, and two commands -
ndptool monitor - monitor incoming NDP messages and print them out.
ndptool send - send NDP message of specified type.
ndisc6
The package called ndisc6 actually has a number of tools included in it :-
ndisc6 - implements the ICMPv6 Neighbor Discovery in userland (it is normally done by the kernel). It is used to lookup the link-layer address (layer 2 address, MAC in the case of Ethernet) of any on-link IPv6 node - the IPv6 address of the node must be specified, as well as the networking interface on which to perform the lookup. And there are a number of options.
rdisc6 - implements the ICMPv6 Router Discovery in userland (it is normally done by the kernel). It is used to lookup the list of on-link routers and IPv6 prefixes - it can also be used to force the kernel to update the state of a given IPv6-autoconfigured network interface - the name of the network interface to probe routers for must be specified.
rltraceroute6 - an IPv6 traceroute implementation - by default, rltraceroute6 sends UDP probe packets toward the destination - it displays the list of hops along the network route between the local system and specified destination, by sending packets while incrementing their hop limit, until the final destination is reached. It has an extensive list of options.
tcptraceroute6 - a TCP/IPv6-based traceroute implementation - uses TCP/IPv6 instead of sending out either UDP or ICMP ECHO packets with a TTL of one, and incrementing the TTL until the destination has been reached. This has advantages in getting through firewalls which frequently stop UDP or ICMP packets.
tracert6 - similar to traceroute - some sources say it uses UDP, some sources say it uses ICMPv6
tcpspray6 - a TCP/IP Discard/Echo bandwidth meter.
ndpmon
ndpmon is a monitoring software for ipv6 Neighbor Discovery - it observes the local network to see if nodes using neighbor discovery messages behave properly - it syslogs activity and reports by email malicious ND messages.
ndpmon uses libpcap to listen for icmp6 packets and libxml2 to use configuration and neighbor cache files. It has an extensive list of options.
chiron
Chiron is a security assessment framework for IPv6. It provides several modules including an IPv6 scanner, IPv6 Local Link, IPv4-to-IPv6 proxy, IPv6 attack module, and IPv6 proxy. These modules help to perform an assessment, like a penetration test.
The tool uses IPv6 extension headers to create a headers chain. This may allow evading security devices like IDS, IPS, and firewalls. Due to the flexibility of the framework, the tool can also be used to perform fuzzing of the IPv6 stack of a device.
Commonly used for network analysis, network security monitoring, network traffic analysis, or threat discovery. Target users for this tool are network administrators, security professionals, and system administrators.
addrwatch
Similar to arpwatch, addrwatch will monitor the pairing between ethernet and IP addresses.
Works on both IPv4 and IPv6.
Aware of packet types associated with Neighbor Solicitation, Neighbor Advertisemnt, and Duplicate Address Detection.
ipv6toolkit
The SI6 Networks IPv6 Toolkit is a security assessment and trouble-shooting toolkit for IPv6 networks and implementations. It provides a number of tools to send abitrary IPv6 packets, perform IPv6 address-scans, analyze IPv6 addresses, and more.
Some websites list 13 tools, some websites list 17 tools, some list 19 tools - may be different versions.
thc-ipv6
Its full title is The Hacker Choice's IPv6 Attack Toolkit - it is a very large toolkit containing over 50 different tools, far too many to describe here - it is described as a complete tool set to attack the inherent protocol weaknesses of IPv6 and ICMPv6.
The thc-ipv6 toolkit is commonly used for network analysis, penetration testing, or security assessment - the target users for this tool are pentesters and security professionals.
subnetcalc
This is an IPv4/IPv6 subnet address calculator. For given IPv4 or IPv6 address and netmask or prefix length, it calculates network address, broadcast address, maximum number of hosts and host address range. Also, it prints the addresses in binary format for better understandability.
Works on both IPv4 and IPv6.
Knows about different kinds of IPv6 address like global addresses, unique local addresses, loopback address, unspecified address, multicast addresses - as well as address prefixes.
This is a command line tool, but it has a sort of GUI feel to it.
Very useful as a way to visualise IPv6 addresses in how they work and how they compare to the way IPv4 addresses work.