Internet Protocol Version 6 (IPv6) Tutorial

This tutorial has been designed to help beginners understand the basic concepts of IPv6 required to work with any TCP/IP-based protocols. After completing this tutorial, you will find yourself at a moderate level of expertise of IPv6 where you can then take yourself to next levels.

Introduction to IPv6

RFC 8200 covers IPv6.

Problems IPv6 Solves

IPv6 addresses several limitations inherent in IPv4, improving both the scalability and efficiency of the internet.

Address Exhaustion: The most significant issue IPv6 resolves is the shortage of available IP addresses. IPv4 uses a 32-bit addressing scheme, which limits the total number of unique IP addresses to about 4.3 billion. As the number of internet-connected devices continues to explode, this limit has become unsustainable, leading to the depletion of IPv4 addresses. IPv6, by contrast, uses 128-bit addresses, offering an almost inexhaustible pool of addresses - approximately 340 undecillion (3.4 x 10^38) unique IPs - ensuring that the world will never run out of IP addresses for the foreseeable future.

Network Address Translation (NAT) Complexity: IPv6 eliminates the need for NAT, which was a workaround introduced in IPv4 to conserve addresses by allowing multiple devices on a local network to share a single public IP address. While effective, NAT introduced complexities in network management, security, and performance, and made peer-to-peer (P2P) communication and certain applications (e.g., VoIP) more difficult to implement. IPv6, with its vast address space, allows each device to have a unique global address, simplifying network configurations and improving end-to-end connectivity.

Efficient Routing: IPv6 improves the efficiency of routing by reducing the size of routing tables. IPv6 uses hierarchical address allocation, which allows for more aggregation of routes, meaning fewer entries in global routing tables. This makes routing more streamlined and less resource-intensive for ISPs and large organizations, improving overall network performance and scalability.

Improved Multicasting: IPv6 introduces better support for multicasting, a method of transmitting data to multiple destinations simultaneously. While IPv4 has limited multicast capabilities, IPv6's expanded addressing structure makes it much easier to efficiently deliver content to multiple nodes, improving use cases such as streaming media, online gaming, and conferencing.

Enhanced Security Features: Although IPv6 has been retrofitted with security protocols like IPSec, IPv6 was designed with security in mind from the start. IPv6 mandates support for IPSec, ensuring that the protocol has robust security features baked in, including better support for authentication and encryption.

Problems IPv6 Creates

While IPv6 solves many of the problems found in IPv4, its adoption has created a few challenges of its own:

Lack of Backward Compatibility: One of the most significant challenges with IPv6 is that it is not backward-compatible with IPv4. This means that devices running IPv4 cannot directly communicate with those using IPv6. This incompatibility requires either dual-stack implementations (where both IPv4 and IPv6 run concurrently) or the use of tunneling protocols to enable communications between IPv4 and IPv6 networks. These solutions, while functional, add complexity to network management during the transition phase, as both protocols need to be supported.

Application Layer Protocol Issues: Certain application-layer protocols that rely on IPv4-specific implementations can break when transitioning to IPv6. For instance, protocols that embed IPv4 addresses within their payloads - such as FTP (File Transfer Protocol) and NTP (Network Time Protocol) - may malfunction unless they are updated to handle IPv6 addresses. This issue requires developers to adapt legacy applications, which can be time-consuming and costly.

Security Misconfigurations: Although IPv6 includes improved security features, its complexity can lead to misconfigurations, exposing vulnerabilities. For example, security tools and firewalls that were designed with IPv4 may not be fully configured to handle IPv6 traffic, potentially leaving networks open to attack if administrators do not implement IPv6-specific security policies.

Deployment Costs: The rollout of IPv6 can be expensive for organizations, requiring upgrades to network infrastructure, hardware, and software to support the new protocol. Additionally, personnel need training to manage and secure IPv6 networks properly, which adds further costs and learning curves to the transition.

IPv6 offers a host of improvements over IPv4, from addressing scalability issues to enhancing network performance; however, the protocol also presents challenges, particularly during the transition phase, requiring careful planning and investment to fully harness its potential benefits.

IPv6 Addresses

IPv6 addresses use a 128-bit format, a significant expansion from IPv4's 32-bit addresses. These addresses are written as eight groups of four hexadecimal digits, separated by colons, such as "2001:0db8:0000:0042:0000:8a2e:0370:7334."

In IPv6, the "prefix" (analogous to IPv4's netmask) defines the network portion of the address. Typically, the prefix consists of the first 64 bits, leaving the remaining 64 bits for the host identifier part of the address.

The massive address space of IPv6 eliminates the problem of address scarcity. Internet Service Providers (ISPs) can now allocate enormous blocks of addresses, often as many as 18 quintillion (18,446,744,073,709,551,616) public IP addresses per customer, ensuring there will be no shortage of addresses in the foreseeable future.

Address Types and Scopes

IPv6 defines three main types of addresses, each that serve a specific purpose:

1. Unicast Addresses: These deliver a packet to a single interface. They are used for one-to-one communications, similar to how IPv4 works. A common example is the global unicast address used to uniquely identify devices on the internet.

2. Multicast Addresses: These deliver a packet to multiple interfaces simultaneously, making them ideal for one-to-many communications. All multicast addresses start with the prefix ff00::/8 (e.g., the first eight bits are 11111111). Multicast enables efficient distribution of data, such as in streaming or group communications scenarios.

3. Anycast Addresses: These deliver a packet to the nearest interface (in terms of routing distance) among multiple interfaces, typically spread across different nodes. Anycast is useful for load balancing and ensuring that network traffic reaches the closes available server.

Address Scopes

IPv6 addresses have different scopes, which define the range in which the address is valid:

Link-local Addresses: These are confined to a single subnet, meaning they cannot be routed outside the local network. Every interface must have a link-local address, and they are typically used for local communications between devices on the same network. Link-local unicast addresses begin with the prefix fe80::/10 (e.g., 1111111010).

Global Addresses: These are routable on the public internet and function similarly to that of IPv4 public addresses. They are used for devices that need to communicate globally.

Node-local Addresses: These have a scope restricted to the local device itself. An example is the loopback unicast address ::1/128, which is used for local testing. Multicast node-local addresses include ff01::01, which targets all nodes on the local device.

Special IPv6 Addresses

IPv6 also includes several special-purpose addresses, such as:

Loopback Address: The loopback address ::1/128 functions similarly to the IPv4 loopback address 127.0.0.1, used for testing or local communications on the same device.

Documentation and Examples Range: The address range 2001:db8::/32 is reserved for use in documentation and technical examples. It ensures that these addresses are not used in actual network traffic.

Unique Local Addresses (ULA): While the deprecated "site-local" addresses once fulfilled local routing needs, ULAs now serve a similar role. They are designed for local communications within a private network and are not intended for routing on the public internet.

For more information on special-purpose IPv6 addresses, please see the IANA IPv6 Special-Purpose Address Registry.

Link-Local Addresses

On startup, a host automatically generates a link-local address for each network interface, regardless of whether the interface is later configured manually or through an automatic method like DHCP.

The link-local address is constructed by combining the reserved prefix fe80::/10 with the device's MAC address and the operating system's interface identifier. This results in addresses like fe80::7985:c2df:fb11:62ec%em1, where the %em1 represents the interface name or zone index.

Why Use the Interface Name as a Zone Index?

Since all link-local addresses share the same network prefix (fe80::/10), even across different network interfaces, there needs to be a way to distinguish which interface to use for sending link-local traffic. The appended interface name (or a numeric interface index) acts as a zone index, allowing the operating system to select the correct interface for outbound traffic. Without this, the system wouldn't know whether to send the traffic through, for example, a wired Ethernet interface or a WiFi interface when both have a fe80:: address.

It's important to note that in some operating systems like Windows, IPv4 and IPv6 maintain separate interface indexes, which adds a layer of complexity.

Characteristics of Link-Local Addresses

Scope: Link-local addresses are only valid and reachable within their specific LAN or broadcast domain. They cannot be routed beyond the local network, making them unusable for communications outside the subnet.
Routing: Despite their local-only nature, link-local addresses play a crucial role in routing. They are often used as the "next hop" address in a router's forwarding table, helping to determine the path traffic should take across a local network.

In sum, the combination of the link-local address's limited scope and the use of a zone index helps ensure that the correct interface is chosen for local communications, while preventing any routing issues outside the local broadcast domain.

ICMPv6

Like ICMPv4, ICMPv6 (Internet Control Message Protocol for IPv6) handles essential tasks such as error reporting, flow control, and first-hop gateway redirection; however, ICMPv6 introduces additional capabilities, such as fragmentation management, neighbor discovery, and Stateless Address Autoconfiguration (SLAAC), which are vital for the functionality of IPv6 networks.

One key difference between ICMPv4 and ICMPv6 is the level of reliance: while IPv4 nodes can sometimes function with ICMP blocked, IPv6 is heavily dependent on ICMPv6 for core operations. Blocking ICMPv6 can lead to significant network disruptions, as it plays a central role in IPv6 packet processing and network functions. This dependency is outlined in RFC 4443, which defines the protocol.

Fragmentation in ICMPv6

In IPv6, fragmentation is handled solely by the host, unlike IPv4 where routers fragment packets in transit. If a router encounters a packet that is too large for the next link, the router does not fragment the packet. Instead, it drops the packet and sends an ICMPv6 message back to the sender, specifically a "Packet Too Big" message - an ICMP type 2 message, respectively.

This message informs the sender that the packet exceeds the Maximum Transmission Unit (MTU) size of the link, and it includes the MTU value of the next hop. The sender can then adjust the packet size or use fragmentation on its end before retransmitting the data.

It's important to note that ICMPv6 type 2 ("Packet Too Big") messages must be allowed to flow end-to-end, even from external networks. Blocking these messages can break communications badly, as hosts would have no way of knowing that their packets need to be fragmented for successful transmission.

ICMPv6 Message Types

Here is a list of key ICMPv6 message types and their meanings, as defined in RFC 4443 and other related RFCs:

Error Messages (Type 0-127)

1. Destination Unreachable (Type 1)
Indicates that the destination is unreachable for some reason. The specific reason is detailed in the code field:

Code 0: No route to destination
Code 1: Communication with destination administratively prohibited (e.g., by a firewall)
Code 2: Beyond scope of source address
Code 3: Address unreachable
Code 4: Port unreachable
Code 5: Source address failed ingress/egress policy
Code 6: Reject route to destination

2. Packet Too Big (Type 2)
Sent by a router when it receives a packet that is too big for the next hop link. This message contains the MTU size of the next hop, allowing the sender to adjust the packet size accordingly.

3. Time Exceeded (Type 3)
Indicates that the hop limit of a packet has been exceeded (similar to the TTL in IPv4). The reasons are specified by the code field:

Code 0: Hop limit exceeded in transit (packet discarded)
Code 1: Fragment reassembly time exceeded

4. Parameter Problem (Type 4)
Indicates an issue with the header fields of a packet. The codes define the specific problem:

Code 0: Erroneous header field encountered
Code 1: Unrecognized next header type
Code 2: Unrecognized IPv6 option encountered

Informational Messages (Type 128-255)

5. Echo Request (Type 128)
This message is used to test connectivity between two devices, similar to the "ping" request in IPv4. The device receiving the request will respond with an Echo Reply.

6. Echo Reply (Type 129)
This message is sent in response to an Echo Request (Type 128), indicating that the target device is reachable and functioning.

Neighbor Discovery Protocol (NDP) Messages (Type 133-137)

7. Router Solicitation (Type 133)
Sent by a host to request information from routers on the network, specifically to prompt them to send Router Advertisements. This message is useful during the network configuration process.

8. Router Advertisement (Type 134)
Routers send this message periodically or in response to a Router Solicitation. It provides network configuration information such as prefixes for address autoconfiguration, the hop limit, and whether DHCPv6 is available.

9. Neighbor Solicitation (Type 135)
Sent by a node to discover the link-layer address of a neighboring node or to verify the reachability of a neighbor. This message replaces ARP in IPv6.

10. Neighbor Advertisement (Type 136)
Sent in response to a Neighbor Solicitation. It provides the link-layer address of a node and confirms its availability on the network.

11. Redirect (Type 137)
Sent by a router to inform a host of a better first-hop router for a destination. It helps optimize the routing of packets within a local network.

Other Important ICMPv6 Message Types

12. Multicast Listener Query (Type 130)
Sent by a router to determine if any nodes on a local network are listening to a specific multicast address.

13. Multicast Listener Report (Type 131)
Sent by a node to report that it is listening to a multicast address.

14. Multicast Listener Done (Type 132)
Sent by a node to indicate that it is no longer interested in a multicast group.

15. Router Renumbering (Type 138)
Allows routers to change their addressing information and notify other routers about the changes (as defined in RFC 2894 - Router Renumbering for IPv6).

These ICMPv6 messages form the backbone of many IPv6 network operations, from error handling and diagnostics to address resolution and router discovery.

For more information regarding Neighbor Discovery for IP version 6, please have a look at RFC 4861.

Stateless Address Autoconfiguration (SLAAC) and ICMPv6

Stateless Address Autoconfiguration (SLAAC) enables IPv6 hosts to automatically configure most of their network settings without the need for a server like DHCP. SLAAC is based on the Neighbor Discovery Protocol (NDP), which relies on ICMPv6 messages.

How SLAAC Works

1. Router Advertisement (RA) Messages: Hosts listen for periodic Router Advertisement (RA) messages multicast by local routers. These messages contain key configuration information, including the network prefix (used for address generation) and other settings like the default gateway.

2. Router Solicitation (RS) Messages: To speed up the process, a host may send a Router Solicitation (RS) message when it joins the network, prompting nearby routers to send an RA more quickly.

3. Address Generation: Once the host receives the network prefix from an RA, it generates a tentative IPv6 address. This address is formed by combining the network prefix from the RA with the host's interface identifier, which is typically derived from its MAC address (though privacy extensions may be used, which I'll cover shortly).

4. Duplicate Address Detection (DAD): Before finalizing the address, the host performs Duplicate Address Detection (DAD) to ensure that no other device on the network is using the same address, which can lead to many network conflicts. This step helps avoid those address conflicts.

5. Finalizing the Address: If DAD confirms that the address is indeed unique, the host finalizes the address and begins using it for full duplex communications.

Privacy Considerations

Using a device's MAC address for the interface identifier can compromise privacy by making the device's activities easily trackable. To address this, IPv6 supports privacy extensions, which allow hosts to generate temporary, randomized addresses instead of using their permanent hardware (MAC) address.

Alternatives to SLAAC

While SLAAC simplifies IPv6 configurations, it may not be suitable for all application types. Alternatives may include:

DHCPv6: Provides stateful configuration, allowing more granular control over IP address allocation and additional configuration parameters (e.g., DNS servers).
Manual Static Configuration: Suitable for environments where network settings must be explicitly defined.

Prefix Length Requirement (/64)

SLAAC requires a prefix length of /64. This requirement stems from how the interface identifier (usually 64 bits long) is combined with the network prefix. IPv6's designers specified a 64-bit boundary between the network prefix and the host identifier to ensure compatibility with the underlying address-generation mechanisms and to future-proof the protocol for security and scalability.

Attempts to use prefix lengths other than /64 with SLAAC typically results in errors or the inability to automatically generate an address. Although there are ongoing discussions in the IETF community about this limitation, as of the time of this writing, the /64 requirement remains in place.

For more details, see RFC 2462: IPv6 Stateless Address Autoconfiguration.

Duplicate Address Detection (DAD in ICMPv6)

Duplicate Address Detection (DAD) is a mechanism used by IPv6 nodes to ensure that the address they intend to use is unique within the local network. DAD is essential to prevent IP address conflicts, except for specific cases like anycast and loopback addresses, which do not undergo DAD.

How DAD Works

1. Joining the All-Nodes Multicast Group
When a node starts an interface, it automatically joins the link-local All-Nodes multicast group (FF02::1), allowing it to receive multicast traffic sent to all nodes on the local network.

2. Creating a Solicited-Node Multicast Address
For DAD, the node constructs a Solicited-Node Multicast Address by combining the reserved Solicited-node prefix (FF02::1:FF00:0000/104) with the last 24 bits of the tentative unicast address. This process limits the scope of DAD traffic to only nodes that might be interested in the tentative address, making it more efficient than sending messages to all nodes on the network.

3. Neighbor Solicitation (NS) for the Tentative Address
The node sends a Neighbor Solicitation (NS) message to the Solicited-Node Multicast Address corresponding to its tentative IPv6 address. This is effectively a "probe" to check whether any other node on the network is already using that address.

4. Response Handling
If another node on the network is already using the same address:

It will respond with its own Neighbor Solicitation (NS) message (with the tentative address as the target).
Alternatively, it may respond with a Neighbor Advertisement (with the tentative address as the source). In either case, if the originating node receives such as message, it realizes the address is not unique and abandons the configuration of that address.

If no response is received within a certain timeout period, the address is deemed unique and is officially assigned to the interface.

DAD is a vital component in IPv6's Neighbor Discovery Protocol (NDP) and helps avoid address duplication, which could lead to connectivity issues on the local network.

Privacy Concerns in SLAAC

Going into a bit more detail on privacy concerns in SLAAC in this section, one of the privacy concerns with Stateless Address Autoconfiguration (SLAAC) is that it typically generates addresses using the interface's MAC address. Since the MAC address is a unique hardware identifier, any SLAAC-generated IPv6 address is also unique to the device, effectively tagging the node's internet traffic with a permanent identifier. This raises privacy concerns, as it can be used to track user's activities across different networks and locations.

You may be wondering, "How can it be used to track user's activities across different networks and locations?" Well, I'll tell you how.

The privacy concerns of SLAAC stem from how IPv6 addresses are generated using the MAC address of a device's network interface, as mentioned previously. Since the MAC address is unique to each network interface, any IPv6 address created with it can act as a persistent identifier for the device. Let's explore a bit more on how SLAAC and MAC address-based IPv6 addresses enable tracking.

1. Persistent Identifier Across Networks:

IPv6 addresses in SLAAC are formed by combining a network prefix (from the local router) with an Interface Identifier (derived from the device's MAC address).
The Interface Identifier portion of the address (typically the last 64 bits) remains constant across different dispersed networks. This means that even when a device moves between different hard-wired or even WiFi networks or switches from hone to work, its IPv6 address will have the same Interface Identifier as long as SLAAC is used.
Consequently, any third-party (such as websites, ISPs, or advertising networks) monitoring the device's network traffic can observe this constant identifier and recognize that it's the same device, even though the network prefix may change with different networks. This allows them to track the user's activities across multiple locations.

2. Global Reachability:

Unlike IPv4, where devices behind routers often share the same public IP address due to NAT (Network Address Translation), IPv6 provides publicly routable addresses to each device. This means that devices configured with SLAAC have globally reachable addresses, making it easier for external entities to directly correlate traffic to individual devices. If an IPv6 address based on the MAC address appears on the internet, it can be traced back to that specific device, not just a household or certain network.

3. Long-Term Observation:

Because a MAC address is typically static and does not change over the life of the device (unless manually altered), the resulting IPv6 address will also remain static as long as the same interface is used This means that even over long periods of time, organizations or trackers that observe the traffic can build a detailed profile of the device's activities, including:

Which networks the device frequently connects to (e.g., at home, work, cafes).
Which websites the user frequently visits.
Any online services or interactions the user has across different sessions, services, and platforms.

This persistent nature of the address makes it very easy for advertisers, analytics companies, or even malicious actors to track a device, correlating its behaviors across both time and location.

4. Correlation Across Networks and Services:

Entities that monitor traffic at different points of the internet (such as ISPs. websites, or cloud providers) can recognize and correlate the same IPv6 address (with the same Interface Identifier) appearing across multiple networks. For example, if a user connects to a public hotel network, an airport network, or even their home network, any third-party capable of observing the IPv6 traffic could deduce that it's the same device behind these activities being tracked.
This. in turn, enables cross-network tracking, even when a device moves across unrelated networks and services. A user might think they are accessing different services privately, but their IPv6 address with the static MAC-derived Interface Identifier reveals that it's the same device.

Example of a Tracking Scenario

Imagine you connect to your home network and you start browsing the web like normal. Your SLAAC-generated IPv6 address includes the unique Interface Identifier based on your device's MAC address. Later, you decide to go to your favorite cafe and you automatically connect to their public WiFi network. Although the network prefix (the first 64 bits of the IP address) changes to reflect the cafe's network, the last 64 bits, derived from the MAC address, remains the same.

Any website or advertising network you visit can see this constant part of the address and link your activities from home with your activities from the cafe's network. Over time, as you connect to different networks - at home, work, or on mobile - the consistent Interface Identifier in the IPv6 address provides a reliable way to track your browsing behaviors and location changes across the internet.

Potential Privacy Implications

Profiling: By associating the same IPv6 address with different websites or services, a third-party can build a comprehensive dossier of the user's browsing habits, interests, and activities over time.
Location Tracking: Since the user's IPv6 address follows them across networks, it's possible to track their movements from one physical location to another based on where they connect to the internet.
Linking Identities: Even if the user takes steps to anonymize their online behaviors (such as using different usernames or emails), their persistent IPv6 address can still be used to link otherwise unrelated accounts and identities.

With all this SLAAC tracking information you've now just learned about, you may be wondering, "Can SLAAC-generated IPv6 addresses on any of my devices be linked, identified, or tracked if I'm using Tor (The Onion Routing) network?"

When using Tor, SLAAC-generated IPv6 addresses do not directly pose a tracking risk because Tor itself is designed to anonymize network traffic. Below, I will provide a succinct reason as to how Tor can accomplish device anonymization, but first, read this:

I last stated that with linked identities, even if a user takes steps to anonymize their online behaviors, their persistent IPv6 address can still be used to link otherwise unrelated accounts and identities. Now, the key distinction lies in the context of how your network traffic is routed when using Tor versus the usual scenario where a SLAAC-generated IPv6 address is exposed during regular, direct internet usage.

SLAAC and Direct Internet Usage

In a typical non-Tor environment, an IPv6 address generated by SLAAC can expose a persistent identifier (derived from your device's MAC address, and as previously mentioned) to the websites and services you interact with. This persistent identifier can be used to link activities across different sessions and networks because it remains constant. Even if you try to anonymize yourself by using different usernames or email accounts, your SLAAC-generated IPv6 address could still be visible to websites and can acts as a fingerprint for tracking, correlating identities across multiple platforms.

Tor's Role in Anonymizing IP Addresses

When using Tor, the entire mechanism changes because Tor anonymizes internet traffic by relaying it through multiple encrypted nodes. Here's a quick breakdown of how the Tor anonymization feature works and how it addresses SLAAC-related privacy concerns:

1. Tor Reroutes Traffic:

Tor does not allow your real IP address - whether it's IPv4 or IPv6 - generated via SLAAC or any other method - to be exposed to the internet.
All traffic is routed through three layers of relays (entry, middle, and exit nodes), and the destination (e.g., the website you're visiting) only sees the exit node's IP address, not your real one.
Since Tor changes your source IP address, the IPv6 address derived from your MAC address never reaches the website you're connecting to. Instead, the website sees an IP from the exit node, which belongs to the Tor network.

2. End-to-End Encryption:

Tor encrypts your traffic, making it impossible for intermediate network observers (such as ISPs) to see your actual SLAAC-generated IP address. Only the entry node knows your real IP address, but it is the only node that can associate your traffic with your true location. After the traffic enters the Tor network, your SLAAC-based IPv6 address is hidden by layers of encryption.

3. Identity Linking is Prevented by Tor:

When you use Tor, each session or circuit is isolated from one another. This means that even if you visit the same website multiple times, the exit node (and by extension, the website) sees a different IP address each time unless you reuse a specific Tor circuit.
No persistent IPv6 address follows you across Tor sessions because the exit node is the only visible IP address, and Tor uses a new circuit for every website or service you visit, which prevents correlation and linking.

What Tor Protects

Your SLAAC-based IPv6 address is never exposed to the destination website or services. These websites only see the IP address of the Tor exit node, which changes regularly, sometimes more than once in any given day, ensuring that no persistent identifier (such as your MAC-derived IPv6 address) is associated with your traffic.
Linking identities based on your real IP address becomes impossible because your IP is anonymized by the Tor network. Websites and advertisers cannot use your real IPv6 address to track you or link your sessions together across different platforms or services.

Why This Works with Tor, But Not Without It

In normal internet usage (without Tor), your SLAAC-generated IPv6 address is exposed, making it easy for trackers to follow your movements across websites. Even if you take steps to anonymize yourself (e.g., using different accounts), still won't change the fact that your persistent IP address can still be tracked.
However, when using Tor, your real IP address is never exposed as Tor isolates your browsing sessions, rotates exit node IP addresses, and reroutes traffic through encrypted relays/nodes, breaking any correlation between your actual device and the online activities you may partake in.

To put this issue to rest, Tor fully anonymizes your internet traffic, preventing the exposure of your SLAAC-generated IPv6 address by routing all traffic through its vast network of volunteer nodes. This prevents websites from seeing your real IP address, ensuring that tracking methods reliant on persistent IP addresses, like those generated by SLAAC, cannot be used to link identities or track your activities across different websites or networks.

How Tor Works with IPv6

1. Tor and IPv6
Tor anonymizes internet traffic by routing it through multiple nodes, called relays, in the Tor network before reaching the final destination. Tor typically handles outgoing traffic at the application level (e.g., web browsers, applications) and routes traffic through its own internal circuits, which means the source address of your machine - whether IPv4 or IPv6 - isn't visible to the websites or services you may visit.

2. SLAAC Within Tor
Even if your device has an IPv6 address generated through SLAAC (which includes the MAC address in the Interface Identifier, as previously mentioned), Tor hides your real IP address (both IPv4 and IPv6) by substituting it with the exit node's IP address when communicating with the destination server; therefore, websites will see the exit node's IP address rather than your SLAAC-based IPv6 address.

Essentially, Tor prevents any direct exposure of your SLAAC IPv6 address because your traffic is encrypted and re-routed through the Tor network. As a result, your device's MAC address-based identifier is not exposed to external parties.

Addressing SLAAC-Related Privacy Issues in a Tor Scenario

No Direct Exposure of the IP Address:
Websites and services interacting with your Tor-enabled browser cannot see your real IP address - whether it's IPv4 or IPv6 - because Tor completely masks it. Any IPv6 address generated using SLAAC, and containing the MAC address, is not transmitted to websites.
Tor Entry and Exit Nodes:
The entry node will know your real IP address, but this is encrypted from the start and only known to the entry node, which is designed not to log or expose this information per Tor strict volunteer relay guidelines. The exit node communicates with the final destination server but only reveals its own IP address, and not your actual device's IPv4 or IPv6 address.

Potential Risks with Local Traffic and Other Applications

While using Tor provides anonymity at the network level (application traffic sent through Tor is protected), there are still potential privacy concerns in cases where local traffic (not routed through Tor) might be exposed:

Non-Tor Traffic:
If an application or service on your machine does not route its traffic through the Tor network, it could potentially expose your device's real IPv4 or IPv6 address, including any SLAAC-generated IPv6 address(es). This can happen if some background services are misconfigured or if you use both Tor and non-Tor applications simultaneously.
DNS Leaks:
If your system is not properly configured, DNS requests could "leak" outside of Tor, potentially revealing your real IPv4 or IPv6 address. Proper configuration of DNS settings is crucial to avoid leaks when using Tor.

Moreover, if you are routing your traffic through Tor, your SLAAC IPv6 address (and by extension, your MAC address) is not exposed to the websites you visit or external observers, thanks to the anonymity provided by the Tor network; however, it's essential to ensure that all traffic is routed through Tor exclusively, and that applications outside of the Tor network aren't accidentally bypassing Tor, as these could leak your device's real IP address, including your SLAAC-generated ones.

Using privacy extensions (RFC 4941) alongside Tor provides an extra layer of protection by randomizing IPv6 addresses, but in practice, the design of Tor already mitigates this tracking risk.

Solutions to Inherent Risks Posed by SLAAC

The risks posed by SLAACs use of MAC addresses were recognized, which led to the development of Privacy Extensions for IPv6 (defined in RFC 4941). As previously mentioned, these extensions allow the device to generate temporary, randomized addresses for each session or connection, thus:

Rotating the Interface Identifier periodically, so it's not tied to the MAC address.
Breaking the link between the user's IPv6 address and their hardware, making it difficult for third parties to track them across various networks.

Privacy extensions are enabled by default in modern operating systems like Windows and macOS, and are often available on Linux distributions as well; however, they may not be enabled by default, so be sure to check. In addition, privacy extensions are also primarily used for global unicast addresses, which link-local address may still use MAC-derived identifiers.

Privacy Extensions (RFC 4941)

To address this issue, RFCP 4941 proposes Privacy Extensions for SLAAC, which introduces a method to periodically change global-scope IPv6 addresses and include a random element in the address generation process.

Instead of using a static identifier like the MAC address, privacy extensions generate temporary addresses that vary over time.
These temporary addresses still ensure global uniqueness but prevent long-term tracking of a device across different networks.

Address Lifetimes

IPv6 addresses have two lifetimes, after which their usability changes:

1. Preferred Lifetime:
During the preferred lifetime, the address is fully usable and can be assigned to new connections.

2. Valid Lifetime:
After the preferred lifetime expires, the address becomes deprecated, meaning it will no longer be used for new connections, but can still be used by existing sessions. Once the valid lifetime expires, the address becomes invalid and should no longer be used by the interface. The address is effectively removed, as it may eventually be reassigned to another device elsewhere.

These lifetimes can be either manually configured or determined automatically, often based on information received in Router Advertisements. Routers can also refresh, renew, or extend the lifetime of autoconfigured addresses.

Privacy Extensions and Modern OS Support

Windows and macOS enable privacy extensions by default, automatically generating temporary, privacy-preserving addresses.
Many Linux distributions also support privacy extensions, though they may not always be enabled by default.

Inspecting an interface that uses privacy extensions typically shows several IPv6 addresses, including deprecated ones that are still attached but no longer valid for new connections.

In summary, DAD ensure that IPv6 addresses are unique within a local network, preventing conflicts, while privacy extensions help to protect users from long-term tracking by regularly rotating the addresses generated through SLAAC. These mechanisms enhance both the reliability and privacy of IPv6 networks and its users.

IPv6 DHCPv6 Implementation

IPv6 supports DHCP in two main modes:

1. Stateful DHCPv6: In this mode, the DHCP server assigns and tracks specific IP addresses for each client. This works similarly to DHCP in IPv4, where the server manages and leases out addresses.

2. Stateless DHCPv6: In this mode, the DHCP server provides supplementary information such as DNS server addresses but does not manage IP address assignments. Instead, devices obtain their addresses through SLAAC (Stateless Address Autoconfiguration) or manual static assignment. Stateless DHCP is more common, especially in smaller networks.

For small networks with only a few deices on a single link, a DHCPv6 server may not be necessary at all, except for one function: informing clients about DNS servers in the mix. While RFC 6106 proposes a way to deliver DNS server information through Router Advertisements (via NDP), this approach has not yet been widely adopted.

(Reference: RFC 3315 - Dynamic Host Configuration Protocol for IPv6).

Abbreviating an IPv6 Address

Writing out a full 128-bit IP address can be cumbersome, monotonous, and time-consuming to say the least, but there are two ways you can easily abbreviate and shorten them for easier readability:

1. Omit leading zeros in each 16-bit block:

Example: 2001:0db8:0000:000d:0000:0000:0000:003c
Shortened: 2001:db8:0:d:0:0:0:3c

2. Collapse consecutive zero fields using a double colon (::):

Example: 2001:db8:0:d:0:0:0:3c
Abbreviated: 2001:db8:0:d::3c

Note: Only one set of consecutive zero fields can be replaced with :: in an address to avoid ambiguity. For instance, ::1 is the shorthand for the loopback address 0000:0000:0000:0000:0000:0000:0000:0001.

Using these two rules helps to simplify IPv6 addresses and makes them more manageable for us humans.

Literal IPv6 Addresses in URLs and URIs

Since colons (:) are used in URLs to separate the port number, literal IPv6 addresses must be enclosed in square brackets to avoid confusion. For example:

https://[2001:db8::100]:8080/example/

DNS in IPv6

In DNS forward zones, IPv6 uses AAAA records (called "quad A") instead of IPv4's A records to map domain names to IPv6 addresses.
Reverse DNS (rDNS) for IPv6 works similarly to IPv4, using PTR records, but under the ip6.arpa.domain instead.

IMPORTANT: Never publish link-local addresses in public DNS, as they are only valid within a local network.

For dynamic DNS (DDNS), clients with dynamic IP addresses can update DNS records. In some configurations, the clients update the DNS server directly, while, in others, the DHCP server performs the update after assigning addresses to clients; however, SLAAC (Stateless Address Autoconfiguration) complicates this, particularly when privacy extensions are enabled, as these extensions cause IP addresses to change more frequently, affecting DNS record TTLs (Time-to-Live). SLAAC also disrupts configurations where DHCPv6 handles DNS updates. For a node to update DNS, it must first discover the DNS server, which is typically done via DHCPv6 or through Router Advertisements (RAs).

See RFC 4472 for further discussion on IPv6 DNS issues.
RFC 3596: DNS Extensions to Support IPv6.

Jumbograms in IPv6

IPv4 limits packets to a maximum of 65,535 octets (2^16-1). IPv6, on the other hand, supports what are known as jumbogram packets, which can be as large as 4,294,967,295 octets (2^32-1); however, every hop along the path must support these larger packets for them to be used.

Simplified Routing in IPv6

IPv6 shifts many responsibilities to endpoints, simplifying the tasks of routers:

Fragmentation: Unlike IPv4, IPv6 routers do not perform packet fragmentation. Hosts are responsible for performing MTU path discovery and adjusting their packet size accordingly or handling fragmentation themselves.
Checksum Calculation: IPv6 eliminates the need for routers to compute checksums. IPv6 assumes that error detection and correction are handled by higher or lower layers (e.g., TCP). Unlike IPv4, where UDP checksums are optional, UDP checksums are mandatory in IPv6. This simplifies routing since routers do not need to recalculate checksums, for example, when decrementing the packet's time-to-live (TTL).
Hop Limit: IPv6 renames IPv4's "TTL" field to Hop Limit, reflecting that routers are no longer expected to measure the time a packet spends in a queue but simply count the number of hops.

These changes in IPv6 improve efficiency by reducing router workload and overhead and enhancing packet-handling performance and full routing optimization.

Smallest IPv6 Network Blocks We Can Advertise

In IPv6, the smallest network block that can be meaningfully advertised across the internet is generally a /48, though some smaller blocks, like a /64, may be propagated in certain cases.

Why Not Smaller Than /64?

A /64 is the smallest network segment that can be subnetted in IPv6, and anything smaller cannot be subdivided. While it's technically possible to advertise a /64 via BGP (Border Gateway Protocol), it's not guaranteed that all internet routers will propagate such small blocks reliably.

/48 is the Recommended Block Size

If you're more than a very small end user, you'll likely need a /48 block. Most internet backbone providers and routers will propagate /48 announcements without filtering them. Thus, a /48 is often considered the smallest block size that can be confidently advertised globally, though network filtering practices were still evolving as of 2018.

Advertising Larger Blocks

The larger the block, the more likely it is to be accepted across the internet. Here's an overview of block sizes and their significance:

/48 and smaller: These are end-user allocations. Local Internet Registries (LIRs), such as ISPs, or large organizations, usually receive between /47 and /33.
/32 to /24: These blocks are assigned to large ISPs and very large organizations.
/23 and larger: Assigned to Regional Internet Registries (RIRs), like ARIN, RIPE, and APNIC, as well as the largest ISPs and organizations.

Subnetting IPv6 Blocks

The table below shows how many /64 subnets can be derived from larger network blocks:

IPv6 Address Allocation Guidelines (RFC 3177)

ISPs are encouraged to allocate blocks to customers based on the following guidelines:

/48: General case for most users.
/64: When only one subnet is required by design.
/128: When it's known that only one device will connect.

Multi-Homed Networks and Direct Allocations

If you're multi-homed, you can request a /48 or larger assignment directly from ARIN or other regional registries. This ensures you have an address block that is suitable for your needs and likely to propagate reliably over the internet.

For more information, check ARIN's IPv6 policy and guidelines:

IPSec (Internet Protocol Security) and IPv6

IPSec was originally designed as a fundamental part of IPv6 and later adapted for use in IPv4. Its core functionality remains the same across both protocols, providing secure communications over IP by authenticating and encrypting each packet.

RFC 4301: Security Architecture for the Internet Protocol

Secure Neighbor Discovery (SeND)

Neighbor Discovery Protocol (NDP) and Stateless Address Autoconfiguration (SLAAC) in IPv6 are susceptible to spoofing and other network security attacks. To mitigate these issues, RFC 3971 introduces Secure Neighbor Discovery (SeND), which adds RSA public key signatures to NDP messages to ensure authenticity; however, SeND is not yet widely supported at the time of this writing and faces its own issues, including Denial of Service (DoS) vulnerabilities and privacy issues and concerns.

RFC 3971: Secure Neighbor Discovery (SeND)

IPv6 Transition Mechanisms: Translation, Tunneling, and Dual Stack

To facilitate the transition from IPv4 to IPv6, several techniques have been developed for coexistence, including:

1. Dual Stack: In this approach, network devices operate with both IPv4 and IPv6 addresses. The two protocols run in parallel, allowing communications with both IPv4 and IPv6 networks.

2. Tunneling: IPv6 packets are encapsulated within IPv4 packets for transmission over IPv4 infrastructure. Tunneling can be point-to-point (P2P), such as GRE tunnels, or point-to-multipoint, such as the 6to4 tunneling method.

2.1. GRE (Generic Routing Encapsulation) Tunnel: A GRE (Generic Routing Encapsulation) tunnel is a network protocol used to encapsulate a wide variety of network layer protocols inside virtual point-to-point connections over an IP network. GRE is often used to connect two networks or systems across an IP-based network, like the internet, as if they were directly connected, allowing for the transport of data packets of different types, such as IPv6 or non-IP traffic, through an IPv4 network.

Key Features of GRE Tunnels:

1. Encapsulation: GRE encapsulates packets inside a GRE header and an outer IP header. This allows various protocols (e.g., IP, IPv6, or non-IP protocols) to be tunneled inside another IP packet.

2. Transport Layer Independence: GRE is independent of the transport protocol, meaning it can be used to tunnel multiple types of traffic (e.g., IP, IPv6, IPX) through IP networks.

3. Point-to-Point Connections: GRE tunnels establish a virtual point-to-point connection between two devices, usually routers, over an IP network.

4. Stateless: GRE tunnels do not provide encryption or authentication natively. They are often paired with additional security protocols like IPsec for securing traffic.

Use Cases for GRE:

Connecting Networks: GRE is used to link two geographically separate networks across an IP network, simulating a direct connection (like a leased line).
Protocol Transport: GRE can be used to transport protocols that are not routable in the underlying network. For instance, tunneling IPv6 over an IPv4 network using GRE.
Multiprotocol Support: GRE allows for encapsulation of protocols like multicast traffic that some networks do not natively support.

GRE Encapsulation Process

1. Original Packet: This is the original data that needs to be transmitted (e.g., an IPv6 packet).

2. GRE Header: The original packet is encapsulated in a GRE header, which contains information necessary for GRE functionality, like routing or payload type.

3. Outer IP Header: A new outer IP header is added, which contains the source and destination IP addresses of the GRE tunnel endpoints.

Example:

Imagine you have two offices, one in New York and another in London. Both networks use IPv6 internally, but they are connected via the public internet, which uses IPv4. A GRE tunnel allows you to encapsulate IPv6 traffic inside IPv4 packets, effectively letting the two networks communicate as though they are directly connected.

However, since GRE does not provide encryption or security, it is often combined with protocols like IPsec to secure the data transmitted through the tunnel.

2.2. 6to4 Tunneling

6to4 tunneling is an IPv6 transition mechanism that allows IPv6 packets to be transmitted over an IPv4 network. It is designed to facilitate the gradual adoption of IPv6 by enabling IPv6 traffic to pass over an IPv4 infrastructure without the need for a fully native IPv6 network. This method uses a technique known as automatic tunneling, where IPv6 packets are encapsulated within IPv4 packets, allowing them to be routed over an iPv4 network.

Key Features of 6to4 Tunneling:

1. Automatic Tunneling: Unlike manual tunneling (where configurations are needed at both tunnel endpoints), 6to4 is an automatic tunneling mechanism. IPv6 traffic is automatically encapsulated in IPv4 packets without requiring pre-configured tunnel endpoints.

2. IPv4-Compatible IPv6 Addresses: In 6to4, the IPv6 address is derived from the IPv4 address of the device. The IPv4 address is embedded within the IPv6 address. This makes it easy for an IPv6 host to communicate over an IPv4 network because the receiving system knows how to handle the packet.

3. Encapsulation: IPv6 packets are encapsulated within an IPv4 header. The IPv4 header allows the IPv6 packet to be transmitted over an IPv4 network.

4. Tunnel Endpoints: Typically, 6to4 tunnels are created between 6to4 routers (which support both IPv6 and IPv4). The router at the sending side encapsulates the IPv6 packet into an IPv4 header, and the router at the receiving side decapsulates it, delivering the original IPv6 packet to the destination.

6to4 IPv6 Address Format

A 6to4 IPv6 address is constructed by embedding the 32-bit IPv4 address into a specific part of the IPv6 address, creating a unique prefix for that device or network. The structure is as follows:

2002:<IPv4-address-in-hex>::/48

For example, if the IPv4 address of a router is 192.0.2.1, the corresponding 6to4 IPv6 prefix would be:

2002:c000:0201::/48

This allows for up to 65,536 /64 subnets (each subnet can host an enormous number of devices) under the /48 prefix.

How 6to4 Works

1. IPv6 to IPv4 Translation: When an IPv6 host sends data to another IPv6 host over the internet, the local router encapsulates the IPv6 packet in an IPv4 packet, using the 6to4 IPv6 address format.

2. IPv4 Network Routing: The encapsulated packet is transmitted over the IPv4 internet, with the IPv4 address embedded in the IPv6 packet's address.

3. Decapsulation: On the receiving end, the 6to4 router decapsulates the IPv4 header and delivers the original IPv6 packet to its destination.

Limitations of 6to4 Tunneling

Relay Routers: 6to4 requires relay routers to facilitate communications between 6to4 users and native IPv6 networks.
No NAT Compatibility: 6to4 does not work well with NAT (Network Address Translation), a common practice in IPv4 networks. This makes it unsuitable for networks behind NAT'd devices, which is prevalent in most home and corporate environments.
Deprecated: Due to its limitations and the widespread deployment of IPv6, 6to4 has been largely deprecated. RFC 7526 recommends that 6to4 should no longer be used on the open internet, as better transition technologies are available, such as NAT64.

Advantages of 6to4

No Manual Configuration Required: 6to4 allows for the automatic creation of tunnels, which is easier to set up compared to manual tunneling techniques.
IPv4-Compatible: It allows IPv6 devices to communicate over an IPv4 infrastructure without requiring the entire network to be upgraded to IPv6.

In sum, 6to4 tunneling was a useful mechanism in the early days of IPv6 adoption but has been largely phased out in favor of more reliable transition techniques like NAT64 and dual-stack configurations.

3. Translation: A translation mechanisms at the network boundary converts IPv6 addresses to IPv4 and vice versa. This allows IPv4-only devices to communicate with iPv6-only devices. Common translation technologies include NAT64 and DNS64, which map addresses between the two protocols.

These methods enable the gradual transition to IPv6 while maintaining compatibility with existing IPv4 infrastructure.

Special IPv6 Addresses

Unicast Addresses:

::1/128: This is the loopback address, used by applications to send packets back to the same host. The IPv6 stack loops these packets on the same interface, similar to 127.0.0.1/8 in IPv4.
2001:db8:::/32: Reserved for use in documentation and example scenarios. These addresses are not routable on the internet, much like 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 in IPv4.
Unique Local Addresses (ULAs): These are intended for local communications within a site or across cooperating sites. Similar to IPv4 private addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), ULAs do not require NAT and are not routable on the public internet. ULAs are globally unique, allowing different organizations to merge or communicate without addressing conflicts. ULAs use the fd00::/8 prefix, with a 40-bit pseudorandom number to ensure uniqueness. The fc00::/8 prefix is reserved, but no allocation method is defined as of yet.
::/64: Used for discarding traffic, similar to a "blackhole" route.

Multicast Addresses:

ff0X::1: All nodes in an IPv6 network. This address identifies all IPv6 nodes on a local network.
ff0X::2: All routers in an IPv6 network.
ff0X::101: Multicast group for all Network Time Protocol (NTP) servers.
ff05::1:3: Multicast group for all DHCP servers in a site.

Additional Resources:

Multihoming: An IPv6 Challenge

A common setup for small- and medium-sized businesses (SMBs) involves a LAN behind a gateway that connects to two different ISPs, each with its own address space. In IPv4 networks this setup is easily managed using NAT, allowing the LAN to use private address space and simplifying the use of multiple ISPs.

IPv6, however, aims to eliminate the need for NAT to maintain the end-to-end transparency advantage. RFC 7157 outlines the challenges faced by IPv6 networks with addresses from multiple ISPs:

Source address selection: A host may struggle to reliably choose the correct source address when it has multiple addresses from different ISPs, leading to potential dropped responses.

Next-hop selection: A host may have difficulty selecting the right gateway when there are multiple paths through different ISP networks.

DNS server selection: A host may receive incorrect replies if it chooses the wrong DNS server from different upstream networks.

Although RFC 7157 proposes some possible future solutions, none have been widely adopted as of 2024. As a result, IPv6-to-IPv6 Network Prefix Translation (NPTv6) remains the only practical solution to manage multihoming without NAT.

As of 2024, the issues outlined in RFC 7157 regarding IPv6 multihoming without NAT largely persist. While various solutions have been proposed, widespread adoption remains limited. IPv6-to-IPv6 Network Prefix Translation (NPTv6) continues to be one of the few viable options for managing multihoming in IPv6 networks that want to avoid using NAT. Despite efforts to find better approaches, such as using provider-independent (PI) addresses or other emerging solutions, most enterprises still rely on NPTv6 or similar methods when dealing with multiple ISPs.

Newer strategies like using provider-assigned (PA) addresses without NAT (RFC 8678) have been explored but face challenges, particularly in asymmetric routing scenarios where traffic leaves through one ISP and returns via another. Problems with source address selection, traffic filtering by ISPs, and routing asymmetries still complicate multihoming setups. As of now, solutions like PI address space or PA with NPTv6 remain practical but not ideal for all scenarios

RFC 7157: IPv6 Multihoming Without Network Address Translation (NAT)

NPTv6

NPTv6 is a protocol defined in RFC 6296 that enables the translation between an "inside" IPv6 network prefix and an "outside" IPv6 network prefix. Unlike traditional NAT (Network Address Translation) used in IPv4 networks, NPTv6 is designed to be stateless and performs a 1:1 address mapping without modifying the host portion of the address. This means the interface identifier (the lower 64 bits of the address) remains unchanged, preserving end-to-end reachability and allowing applications to function without disruption.

Prefix Translation Only: Unlike traditional NAT (which may modify both the IP address and port), NPTv6 strictly translates between prefixes. It does not perform port translation, meaning it keeps the integrity of the host section of the IPv6 address intact.
Prefix Size Requirement: For NPTv6 to function properly, the internal and external prefixes must be of the same size. This ensures that the mapping between addresses is consistent without any ambiguity.
Stateless Operation: NPTv6 is a stateless process, meaning that no session-specific state is stored by the network device performing the translation. This reduces overhead and avoids many of the issues associated with traditional stateful NAT, such as port exhaustion.
End-to-End Reachability: Since the host portion of the address remains untouched, NPTv6 preserves the end-to-end model of IPv6, allowing for direct communication between hosts without needing to maintain complex NAT tables.

RFC 6296 is the governing standard that outlines the specifics of how IPv6-to-IPv6 prefix translation should operate. It provides guidance on implementation, emphasizing the preservation of transparency and reachability in IPv6 networks.

NPTv6 is especially useful in multihomed environments where a site might have two different IPv6 prefixes assigned by different ISPs, as it allows for seamless translation between those prefixes without breaking the end-to-end nature of IPv6 communication.

Key Features of NPTv6

Stateless Operation: NPTv6 does not maintain any session state information, which simplifies the implementation and reduces the processing overhead on network devices.
1:1 Address Mapping: Each internal IPv6 address is directly mapped to a corresponding external address without altering port numbers or using port translation.
Unmodified Host Portion: The translation affects only the network prefix (the upper bits of the address). The host portion remains the same on both sides of the translation, ensuring consistency for end-to-end communication.
Same Prefix Length Required: It is crucial that both the "inside" and "outside" network prefixes are of the same length. This alignment is necessary for the stateless, algorithmic mapping to function correctly.

Implementation Considerations

Ensure Matching Prefix Lengths: When configuring NPTv6, verify that the internal and external prefixes have identical lengths (e.g., both are /48 or /56). Mismatched prefix lengths can lead to incorrect address translations and connectivity issues.
Routing Adjustments: Update routing tables and policies to account for the translated prefixes. Since NPTv6 changes the network prefix, routers and firewalls must recognize both the internal and external prefixes to route traffic appropriately.
Avoid Address Overlaps: The external prefix should be globally unique and not overlap with any other prefixes to prevent routing conflicts and ensure proper packet delivery across the internet.

Advantages of NPTv6

Preserves End-to-End Connectivity: By not altering the host portion or ports, NPTv6 maintains the integrity of IPv6's end-to-end communication model, allowing protocols that rely on the host identifier to function correctly.

Facilitates Multihoming: NPTv6 can be useful in multihoming scenarios where a network connects to multiple ISPs. It allows the internal network to use provider-independent addressing while mapping to different provider-assigned prefixes externally.

Reduces Complexity Compared to NAT: Being stateless and avoiding port translation simplifies network management and reduces the potential for issues associated with traditional NAT, such as port exhaustion or complex state tracking.

RFC 6296: IPv6-to-IPv6 Network Prefix Translation

By ensuring that the inside and outside network prefixes are the same size and properly configured, NPTv6 provides a practical solution for IPv6 address translation without compromising the benefits of IPv6's design principles.

Working with IPv6

Discovering Other IPv6 Hosts on the LAN:

You can use the following commands to explore and interact with IPv6 hosts on your local network:

1. Ping All Nodes Multicast Address:

Use the ff02::1 address to ping all IPv6 hosts on your LAN:

$ ping6 -c3 -w3 -I eth0 ff02::1

2. View Neighbor Table:

Display the current IPv6 neighbor table (similar to the ARP table for IPv4):

$ ip -6 neigh

3. Ping a Specific Link-Local Address:

Specify the interface when pinging a link-local address:

$ ping6 -c3 fe80::215:65ff:fe9b:c802%eth0

Monitoring ICMPv6 Traffic

To monitor ICMPv6 traffic on a specific interface:

# tcpdump -i em0 'icmp6'

Configuring Firewall Rules for IPv6

Allow some basic IPv6 traffic through `iptables` with these rules:

1. Accept Established Connections:

# ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

2. Allow ICMPv6 Traffic:

# ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

3. Accept Loopback Interface Traffic:

# ip6tables -A INPUT -i lo -j ACCEPT

Enabling SLAAC Privacy Extensions

To activate SLAAC privacy extensions for an interface, update your configuration files:

1. For a Specific Interface (/etc/network/interfaces):

iface eth0 inet6 auto

privext 2

2. System-Wide Default (/etc/sysctl.conf):

net.ipv6.conf.all.use_tempaddr=2

net.ipv6.conf.default.use_tempaddr=2

3. Using NetworkManager:

Check and modify your connection's settings to enable IPv6 privacy extensions:

$ nmcli conn show

$ nmcli conn show "Wired connection 1"

# nmcli conn mod "Wired connection 1" ipv6.ip6-privacy 2

Rate This Article

Thanks for reading: Internet Protocol Version 6 (IPv6) Tutorial, Sorry, my English is bad:)