Understanding IPv6

Understanding IPv6: Complete Migration Guide from IPv4 to IPv6

Table of Contents

1. Common Perspectives on IPv6
2. IPv6 Architecture
3. The Structure of the IPv6 Protocol
4. Business Benefits of IPv6
5. IPv6 Transition Mechanisms
6. Dual-Stack Design
7. IPv6-over-IPv4 Tunnels
8. IPv6 Architectural Components & Deployment
9. Phased Deployment Strategy
10. Conclusion

Common Perspectives on IPv6

Exhaustion of IPv4 Address Space

For over 50 years, IPv4 has contributed greatly to the growth of networking and the Internet. But that growth has led to problems and threatens to halt the expansion of the Net. IPv6 is the next generation network communication protocol that provides numerous benefits compared to IPv4, specifically expanded addressing, streamlined packet processing, and many other improvements.

The basic framework was standardized by IETF in the 1990s and continues to evolve since then. IPv6 is being deployed worldwide on hosts, applications, and networking equipment.

The Making of the "Perfect Storm"

🚨 IPv4 Address Depletion: The IPv4 address space is expected to run out. The central allocation authority provided the preliminary last block of IPv4 addresses in February 2011.

IPv6 is on a network close to you. Most operating systems and equipment vendors already ship IPv6 as part of their product, and IPv6 is often enabled by default. IPv6 is already running on most networks although this is often a rogue or unwitting deployment. Most network managers lack the tools to manage, monitor, or even detect IPv6 usage in their networks.

Perspectives on IPv6: Myths and Reality

Myth 1: "Didn't NAT kill IPv6?"

Before NAT (RFC 1631 from 1994), in the early days of the Internet, if a host could reach the Net, everyone on the Net could reach that host. After NAT was introduced, we lost transparency. Extremely complex mechanisms are in place to circumvent NAT obstacles.

Myth 2: "Mostly an Asian activity"

Wrong! IPv4 addressing is not sustainable long term. IPv4 is expanding faster than the capacity of the routing infrastructure.

Problems with IPv4 Addressing:

• Early address allocation was not efficient. Addresses were not reclaimed after they were no longer in use.
• CIDR solution was introduced in 1994 which eased routing table growth, but:
• Lack (difficulty) of renumbering when networks migrate to new ISPs is fragmenting the IPv4 address space.

Myth 3: "Give it another decade or two!"

WRONG. The time for IPv6 deployment is NOW.

Additional Concerns with IPv4

Issue	Description
Communication Between Local Devices	IPv4 has limitations in efficient local device communication
IPv4 Administration	Labor intensive, complex, slow, and error prone
Security	IPv4 was developed when networking was a closed system. While security specifications were added over time, these are optional and there is no single standard.
Quality of Service (QoS)	IPv4 QoS mechanisms are limited and complex
Mobile IPv4	Not as scalable, efficient, or secure as it needs to be given the number of mobile devices online now and expected in the future

✅ IPv6 Solutions: IPv6 solves many other IPv4 problems such as seamless mobility, security, network plug-n-play, and extensibility.

Eye of the Storm - Everything Over IP

IPv6 analysis must be viewed from both a theoretical and a practical deployment perspective. We are at the dawn of a second revolution in network usage:

• Proliferation of mobile devices, consumer appliances, home networking
• Problem is more acute in certain geographic areas, e.g., Asia
• Businesses assume the Internet already provides pervasive connectivity, unconcerned with the technical challenges
• Business plans are made on the assumption of low cost connectivity

⚠️ Critical Question: 65% of the world population is not yet connected. What will happen when the rate of consumption of Internet addresses changes because of a new convergence model or new government stimulus? What will happen when everything in our homes, cars, offices, all the products we buy, all food and medicine packaging, and perhaps even humans themselves are IP addressable?

IPv6 is a Business Continuity Issue

IPv6 must be part of any investment plan NOW:

Time to Strategically Invest in IPv6

• Integration of IPv6 is the only viable option
• Requirement for new capabilities and future growth
• Cost of supporting IPv6 is very small when you make it part of the general IT roadmap

IPv6 is a Business Continuity Issue

• Customer-facing systems will not be visible to users on the new IPv6 Internet unless IPv6 is supported
• Internal network users will need IPv6 connections to ensure they can reach the entire internet
• Cost of doing nothing. Cost of missed opportunities. Cost of IPv4 rationing.

IPv6 Architecture

Evolution, Not Revolution

IPv4 has been an integral part of the genesis and growth of the Internet for many years. IPv6 follows the key design principles of this proven protocol. But to address modern networking needs, IPv6 has been modified in the following areas:

1. Evolved Addressing

• 128-bit addresses: Every grain of sand on the planet can have multiple addresses
• Address types: Unicast, Multicast, Anycast – but NOT broadcast

📊 Address Space Comparison:
IPv4: 2³² = 4,294,967,296 addresses
IPv6: 2¹²⁸ = 340,282,366,920,938,463,463,374,607,431,770,000,000 addresses

2. Streamlined Efficient Headers

• Fixed Size IPv6 Header with fewer fields
• 40 bytes vs. 20 bytes for IPv4 header without options
• Ordered Extension Headers
• Extensible to support future payloads
• Only processed when present
• 64-bit aligned

3. A Set of Optimizing Behaviors

• Larger MTU, No fragmentation en-route
• No checksum at the network layer
• Hop-by-hop options

4. A Set of New Protocols and Protocol Extensions

• ICMPv6
• DHCPv6
• Mobile IPv6
• Routing Extensions
• DNS Extensions

5. Automated Configuration

• Neighbor Discovery: ARP + Router Discovery + Router Redirect
• Autoconfiguration: 'Stateless', 'Stateful' (DHCPv6)
• Automatic Renumbering for Hosts and Routers

6. Secured with IPSec

• Encryption and Authentication

7. Transition Mechanisms

• To fit 'every' circumstance

IPv6 Advantages

Expanded Address Space

By expanding the address space to 128 bits, IPv6 solves the IPv4 address shortage:

• Enables many more levels of hierarchical addressing to simplify routing and renumbering
• Renders NAT expendable?
• The network is transparent again, easing the administrative burden

IPv6 Simplified Header

• IPv4 was not designed for today's gigabit and terabit routers
• IPv6 header is much simpler than its predecessor
• The redesign also provides greater flexibility for future modifications

IPv6 Security

• IPsec is an integral part of the IPv6 specification
• Full end-to-end security is deployable with NAT removed from the equation
• Standards-based security promotes interoperability

The Structure of the IPv6 Protocol

Now it's time to explain the structure of the IPv6 header and to compare it to the IPv4 header. This section also discusses Extension headers, which are new in IPv6. Understanding the structure of a protocol header and the type of information that comes with it is the best foundation for working with a protocol. This understanding helps you to identify how the protocol can best be configured and what the options are. It also helps you to identify possible sources of problems and issues when troubleshooting.

The header structure of an IPv6 packet is specified in RFC 2460. The header has a fixed length of 40 bytes. The two fields for Source and Destination addresses each use 16 bytes (128 bits), so there are only 8 bytes for general header information. The base IPv6 header is therefore much simpler and clearer than the IPv4 header, allowing for more efficient processing and, as we will see, more flexibility in extending the protocol to meet future needs.

General Header Structure

In IPv6, five fields from the IPv4 header have been removed:

• Header Length
• Identification
• Flags
• Fragment Offset
• Header Checksum

Why Header Length Was Removed

The Header Length field was removed because it is not needed in a header with a fixed length. In IPv4, the minimum header length is 20 bytes, but if options are added, it can be extended in 4-byte increments up to 60 bytes. Therefore, with IPv4, the information about the total length of the header is important. In IPv6, options are defined in Extension headers.

Why Fragmentation Fields Were Removed

The Identification, Flags, and Fragment Offset fields are the fields that are used for the fragmentation of a packet in the IPv4 header. Fragmentation happens if a large packet has to be sent over a network that supports only smaller packet sizes. In that case, the IPv4 router splits the packet into smaller slices and forwards multiple packets. The destination host collects the packets and reassembles them. If only one packet is missing or has an error, the whole transmission has to be redone; this is very inefficient.

In IPv6, a host learns the Path Maximum Transmission Unit (MTU) size through a procedure called Path MTU Discovery, which has been defined in RFC 1981.

📝 Path MTU Discovery in IPv4 vs IPv6:
In IPv4, the Don't Fragment Bit (DF-Bit) was used for Path MTU Discovery. If a router could not forward a packet due to its size and could not fragment it because the DF-Bit was set, it sent back an ICMP "Packet Too Big" message to the source node.

If a sending IPv6 host wants to fragment a packet, it will use an Extension header to do so. IPv6 routers along the path of a packet do not provide fragmentation as they did with IPv4. So the router always sends back a "Packet Too Big" message to the source node. This is the reason that the Identification, Flags, and Fragment Offset fields were removed from the IPv6 header and will be inserted in an Extension header by the source host if needed.

Why Header Checksum Was Removed

The Header Checksum field was removed to improve processing speed. If routers do not have to check and update checksums, processing becomes much faster. At the time when IPv4 was developed, checksumming at the media access level wasn't common, so the Checksum field in the IPv4 header made sense. Today, the risk for undetected errors and misrouted packets is minimal. There is also a checksum field at the transport layer (UDP and TCP).

⚠️ Important Change: With IPv4, a UDP Checksum is optional; with IPv6, a UDP checksum is mandatory. Since it is a best-effort delivery protocol, it is the responsibility of upper layer protocols to ensure integrity.

Renamed and New Fields

• The Traffic Class field replaces the "Type of Service" field in IPv4
• IPv6 has a different mechanism to handle preferences
• The Protocol Type field in IPv4 has been renamed to Next Header field
• The Time-to-Live (TTL) field has been renamed to Hop Limit
• A Flow Label field was added

The Fields in the IPv6 Header

Here is a detailed overview of each field:

Version (4 bits)

This 4-bit field contains the version of the protocol. In the case of IPv6, the number is 6. Version number 5 could not be used because it was already assigned to the experimental stream protocol (RFC 1819).

Traffic Class (1 byte)

This field replaces the Type of Service field in IPv4. It facilitates the handling of real-time data and any other data that requires special handling, and sending nodes and forwarding routers can use it to identify and distinguish between different classes or priorities of IPv6 packets.

RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" explains how the Traffic Class field in IPv6 can be used. RFC 2474 uses the term DS Field to refer to the Type of Service field in the IPv4 header, as well as to the Traffic Class field in the IPv6 header.

Flow Label (20 bits)

This field distinguishes packets that require the same treatment in order to facilitate the handling of real-time traffic. A sending host can label sequences of packets with a set of options. Routers keep track of flows and can process packets belonging to the same flow more efficiently because they do not have to reprocess each packet's header. The flow label and address of the source node uniquely identify the flow.

Nodes that do not support the functions of the Flow Label field are required to pass the field unchanged when forwarding a packet and to ignore the field when receiving a packet. All packets belonging to the same flow must have the same Source and Destination IP address.

Payload Length (2 bytes)

This field specifies the payload, i.e., the length of data carried after the IP header. The calculation in IPv6 is different from the one in IPv4. The Length field in IPv4 includes the length of the IPv4 header, whereas the Payload Length field in IPv6 contains only the data following the IPv6 header. Extension headers are considered part of the payload and are therefore included in the calculation.

The fact that the Payload Length field has 2 bytes limits the maximum packet payload size to 64 KB. IPv6 has a Jumbogram Option, which supports bigger packet sizes if needed. The Jumbogram Option is carried in a Hop-by-Hop Option header. Jumbograms are relevant only when IPv6 nodes are attached to links that have a link MTU greater than 64 KB; they are specified in RFC 2675.

Next Header (1 byte)

In IPv4, this field is called the Protocol Type field, but it was renamed in IPv6 to reflect the new organization of IP packets. If the next header is UDP or TCP, this field will contain the same protocol numbers as in IPv4 - for example, protocol number 6 for TCP or 17 for UDP. But if Extension headers are used with IPv6, this field contains the type of the next Extension header. Extension headers are located between the IP header and the TCP or UDP header.

Hop Limit (1 byte)

This field is analogous to the TTL field in IPv4. Originally, the IPv4 TTL field contained a number of seconds, indicating how long a packet can remain in the network before being destroyed. In fact, IPv4 routers simply decrement this value by one at each hop. This field has been renamed to Hop Limit in IPv6 to reflect the purpose. The value in this field expresses a number of hops. Every forwarding node decrements the number by one. If a router receives a packet with a Hop Limit of 1, it decrements it to 0, discards the packet, and sends the ICMPv6 message "Hop Limit exceeded in transit" back to the sender.

Source Address (16 bytes)

This field contains the IP address of the originator of the packet.

Destination Address (16 bytes)

This field contains the IP address of the intended recipient of the packet. This can be the ultimate destination or, for example, if a Routing header is present, the address of the next hop router.

Extension Headers

The IPv4 header can be extended from a minimum of 20 bytes to a maximum of 60 bytes in order to specify options such as Security Options, Source Routing, or Timestamping. This capacity has rarely been used because it causes a performance hit. For example, IPv4 hardware forwarding implementations have to pass the packet containing options to the main processor (software handling).

The simpler a packet header, the faster the processing is. IPv6 has a new way to deal with options that has substantially improved processing: it handles options in additional headers called Extension headers. Extension headers are inserted into a packet only if the options are needed. And in most cases, the Extension headers are only processed by the final destination, not by intermediate devices.

Six Standard Extension Headers

The current IPv6 specification defines six Extension headers, which must be supported by all IPv6 nodes:

1. Hop-by-Hop Options header
2. Routing header
3. Fragment header
4. Destination Options header
5. Authentication header
6. Encapsulating Security Payload header

There can be zero, one, or more than one Extension header in an IPv6 packet. Extension headers are placed between the IPv6 header and the upper-layer protocol header. Each Extension header is identified by the Next Header field in the preceding header.

💡 Flexibility: This architecture is very flexible for developing additional Extension headers for future uses as needed. New Extension headers can be defined and used without changing the IPv6 header. A good example is the Mobility header defined for Mobile IPv6 (RFC 6275). There is no defined upper limit per packet. The IPv6 specification theoretically allows an unlimited number of extension headers as long as the maximum packet size (normally 65,535 bytes) is not exceeded.

1. Hop-by-Hop Options Header

The Hop-by-Hop Options header carries optional information that must be examined by every node along the path of the packet. It must immediately follow the IPv6 header and is indicated by a Next Header value of 0.

For example, the Router Alert (RFC 2711) uses the Hop-by-Hop Options header for protocols such as Resource Reservation Protocol (RSVP), Multicast Listener Discovery (MLD) messages, or the Jumbogram Option.

⚡ Performance Benefit: With IPv4, the only way for a router to determine whether it needs to examine a datagram is to at least partially parse upper-layer data in all datagrams. This process slows down the routing process substantially. With IPv6, in the absence of a Hop-by-Hop Options header, a router knows that it does not need to process router-specific information and can route the packet immediately to the final destination. If there is a Hop-by-Hop Options header, the router needs only to examine this header and does not have to look further into the packet.

Jumbogram Option

This Hop-by-Hop Option Type supports the sending of IPv6 Jumbograms. The IPv6 Payload Length field supports a maximum packet size of 65,535 bytes. The Jumbo Payload Option (RFC 2675) allows for larger packets to be sent. In the IPv6 header of a packet with the Jumbo Payload option, the Payload Length field is set to 0. The Next Header field contains the value 0, which indicates a Hop-by-Hop Options header. The Option Type value of 194 indicates the Jumbo Payload option. The Jumbo Payload Length field has 32 bits and therefore supports the transmission of packets that are between 65,536 and 4,294,967,295 bytes.

Router Alert Option

This Option Type indicates to the router that the packet contains important information to be processed when forwarding the packet. The option is currently used mostly for MLD (Multicast Listener Discovery) and RSVP (Resource Reservation Protocol). It is specified in RFC 2711, which has been updated by RFC 6398.

RSVP uses control packets containing information that needs to be interpreted or updated by routers along the path. These control packets use a Hop-by-Hop Options header, so only routers process the packet. Regular data packets do not have this Extension header and are therefore forwarded immediately without further inspection by the router.

2. Routing Header

The Routing header is used to give a list of one or more intermediate nodes that should be visited on the packet's path to its destination. In the IPv4 world, this is called the Loose Source Route option. The Routing header is identified by a Next Header value of 43 in the preceding header.

⚠️ Note: The Loose Source Route option is a (now obsolete and insecure) IPv4 header option that allowed the sender to partially control the path a packet takes through the network.

3. Fragment Header

An IPv6 host that wants to send a packet to an IPv6 destination uses Path MTU discovery to determine the maximum packet size that can be used on the path to that destination. If the packet to be sent is larger than the supported MTU, the source host fragments the packet. Unlike in IPv4, with IPv6 a router along the path does not fragment packets. Fragmentation occurs only at the source host sending the packet. The destination host handles reassembly.

A Fragment header is identified by a Next Header value of 44 in the preceding header.

4. Destination Options Header

A Destination Options header carries optional information that is examined by the destination node only (the Destination address in the IPv6 header). A Next Header value of 60 identifies this type of header.

The Destination Options header can appear twice in an IPv6 packet. When inserted before a Routing header, it contains information to be processed by the routers listed in the Routing header. When inserted before the upper-layer protocol headers, it contains information for the final destination of the packet.

5 & 6. Authentication Header and Encapsulating Security Payload Header

These headers are used for IPsec and are covered in security-related RFCs.

New Extension Header Format

With the exception of the Hop-by-Hop and Routing header, Extension headers are usually only processed by the final destination of a packet. In practice there are devices on the path of a packet, such as routers and firewalls, which are capable of parsing past or ignoring Extension headers at wire speed.

In order to accommodate real-world implementations and to optimize Extension header processing and inspection of Extension headers, a new format for Extension headers has been defined in RFC 6564, "A Uniform Format for IPv6 Extension Headers."

Business Benefits of IPv6

Industry IPv6 Readiness

Operating Systems

Chrome OS, Apple macOS, BSD, HP-UX, AIX, Windows Vista, Windows Server 2008, Linux SUSE, Linux RedHat, and Solaris, etc. ALL major operating systems are shipping with IPv6 which are often enabled by default.

Mobile Operating Systems

Android, Windows Mobile 5 and 6, Symbian, and WebOS...

Applications

On top of these platforms application vendors are at various stages of implementing IPv6 in their products. Examples: Sony PlayStation Network, Windows Server 2008 Network Load Balancing, Windows Vista Peer-to-Peer framework, Apple "Back to My Mac" (BTMM), Mozilla Firefox, Facebook, YouTube, Netflix, etc.

Network Infrastructure

Routers, Switches, Firewalls, Load balancers, Optimization Devices, and Proxies

Service Providers

NTT, AT&T, Sprint, Free, Hurricane Electric, Bechtel, Google, Yahoo, Comcast, Verizon, Rogers...

Content Distribution Networks

Akamai, Limelight

Government Country Mandates

US Government, Europe, France, Japan, Korea, India, and China. Most world regions (and governments) have IPv6 on their road maps and requirements.

Key Business Benefits

Benefit	Description
Lower Network Administration Costs	Autoconfiguration and hierarchical addressing make networks easier to manage and reduce operational costs
Optimized for Next Generation Networks	Larger address space of IPv6 makes NAT unnecessary, thus re-enables the peer-to-peer model for communications and mobility solutions
Protection of Assets	Integrated security provides for a unified security strategy for the network
Investment Protection	IPv6 transition and translation mechanisms enable phased deployment

IPv6 Transition Mechanisms

IPv6 Will Not Replace IPv4

IPv6 will be deployed alongside IPv4 where needed:

Hosts:

• Dual stack, both v4 and v6 addressing
• Builds packets based on v6 availability of destination

EDGE Switch/Access Point:

• Dual stack (IPv6 host) for management
• Layer 2 (MAC) forwarding of data
• Does not care if it is IPv4, IPv6, NetBIOS, AppleTalk
• Support MLD snooping for L2 multicast

Distribution/Intelligent EDGE Switch:

• Dual stack
• IPv4 and IPv6 routing
• IPv4 and IPv6 services (QoS and ACL's)
• Support MLD snooping for L2 multicast

Interconnect/CORE/WAN:

• Dual stack
• IPv4 and IPv6 routing & multicast
• IPv4 and IPv6 services (QoS and ACL's)

Three Main Categories of Transition Mechanisms

1. Dual Stack

• Provide complete support for IPv4 and IPv6 protocols
• Can communicate with both IPv4 and IPv6 nodes

2. Tunneling

• Encapsulates IPv6 packets in IPv4 headers (and in certain cases IPv4 packets in IPv6 headers)
• Dual-stack devices required at either end of the connection

3. Translation

• Translates IPv6 addresses into IPv4 addresses

Dual-Stack Design

Recommended Customer Transition Technology

For hosts, routers, servers, applications! IPv4 and IPv6 protocol stacks are implemented on the same device.

• IPv6/IPv4 devices interoperate with IPv6-only devices using IPv6 packets, and IPv4-only devices using IPv4 packets.
• IPv6-aware applications can service IPv4-only nodes and new IPv6 nodes without having to run two separate applications for that purpose.

Application Layer: Telnet, FTP, Etc. Transport Layer: TCP, UDP, Etc. Network Layer: [IPv4] [IPv6] Data-Link Layer: Ethernet, ATM, Etc. IPv4 Node → IPv4 TCP → IPv4 IPv4/IPv6 Router IPv6 Node → IPv6 TCP → IPv6

Dual-Stack Considerations

While dual-stack devices offer the greatest flexibility, the following is also true:

• An IPv4 address must be available for every dual-stack device
• Dual-stack routers must maintain two routing tables
• Dual-stack nodes require additional memory and CPU power
• Each network requires its own routing protocol
• Firewalls must be configured with security concepts and rules appropriate to each
• A DNS resolver capable of resolving both IPv4 and IPv6 addresses is required
• All applications must be able to determine whether communication is with an IPv4 or IPv6 peer
• Separate network management commands are required

IPv6-over-IPv4 Tunnels

Quick and Inexpensive Solution

• Endpoints must be upgraded to dual stack
• The rest of the traversed network can remain as is
• 41 in the Protocol field identifies the IPv6 encapsulation
• Tunnel endpoints' IPv4 addresses are identified in the Source and Destination fields

IPv4 Header: +--------+--------+--------+--------+ |Version |Head Len|Type of Service | +--------+--------+--------+--------+ | Total Length | +--------+--------+--------+--------+ | Identification |Flags|Fragment| +--------+--------+--------+--------+ |Time to |Protocol| Header Checksum| | Live | = 41 | | +--------+--------+--------+--------+ |Source Address = Tunnel endpoint | +--------+--------+--------+--------+ |Destination Address = Tunnel endpt| +--------+--------+--------+--------+ |Options and Padding | +--------+--------+--------+--------+ IPv6 Header | TCP/UDP Data

Tunneling Considerations

Benefits:

• Upgrade wherever and whatever, at own pace
• Connect isolated IPv6 nodes and networks whether or not the ISP has upgraded to IPv6
• Take advantage of emerging IPv6 services while remaining connected to the IPv4 world

Drawbacks:

• Encapsulation and decapsulation take time and CPU power
• Tunnel endpoints can be single points of failure
• Tunnels can be vulnerable to security attacks
• Encapsulation can complicate troubleshooting and network management as well

💡 Recommendation: Recommended for site-to-site connections.

DNS and Transition Mechanisms - Address Selection

The dual-stack node must determine the type and scope of address to use for the source and destination:

• The set of address selection rules is described in RFC 3484
• The DNS infrastructure must contain both types of resource records
• Dual-stack nodes can use either domain

Stage 1: DNS request sent ↓ Stage 2: DNS server sends answer ↓ Stage 3: Application selects correct address ↓ Stage 4: Application connects to destination host

IPv6 Architectural Components & Deployment

Enterprise Deployment Considerations

Organizational Goals and Drivers

• Overall business case for IPv6 in the enterprise
• IPv6 is not JUST a network problem!

Data Architecture

• Sources and Types of Data to be modified
• Address Plans, Firewall Policies, and ACL's

Application Architecture

• Applications need to be IPv6 aware
• Which Processes Data and Support Business Process

Technology Architecture

• Infrastructure needs to be IPv6 aware
• Network, Compute, Middleware, and End Points

Understanding IPv6 Transition

Provide an initial template of those components required for transition to IPv6:

• Will help in choosing the most appropriate transition plan
• Many IPv6 building blocks are already on your network

3 "Typical" IPv6 Transition Scenarios

NOT an exhaustive set but a base set of general cases:

1. Scenario 1: Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure
2. Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network infrastructure
3. Scenario 3: IPv6 dominant network infrastructure with some IPv4-capable nodes/applications

⚠️ First Step: Must first understand existing Network Infrastructure

Plan Your Transition - Layer-by-Layer Considerations

Layer	Considerations
Application Layer	Purchased applications, Homegrown applications and the IP socket libraries, FTP, SNMP, Telnet, protocols that embed IP address information; access control
Sockets Layer	Application programming interfaces for network communication
Transport Layer	TCP/UDP compatibility and modifications
Network Layer	IPv6 addressing, IPsec, IPv6 routing, multicasting, NAT, firewall rules, IPv6 header
Data-Link Layer	IPv4/IPv6 MTU values and corresponding fragmentation issues
Physical Layer	Network's natural growth, IPv4 network management infrastructure

Phased Deployment of IPv6 Design

Migration to IPv6 can be done at application, host, and subnet level.

Key Design Considerations

1. Planning of IPv6 Hierarchical Addressing & Address Configuration Mechanism

• Identify the various IPv6 address configuration modes you want to support in your network

2. Network Topology Layout

• Understand how you want the network topology
• E.g., Do you want separate IPv4 and IPv6 networks or do you want to overlay them?

3. Transition Mechanisms

• Design how IPv4 and IPv6 networks will communicate with each other

4. Network Security Architecture

• Ensuring that security is not weakened by deploying IPv6
• Deploy a streamlined security architecture facilitated by IPv6

Conclusion

Understanding IPv6 is critical for modern network infrastructure. This guide has covered the essential aspects of IPv6 migration:

🎯 Key Takeaways:

• IPv6 is Inevitable: With IPv4 exhaustion complete, IPv6 deployment is a business continuity issue
• Evolution, Not Revolution: IPv6 builds on IPv4's proven foundation while addressing modern requirements
• Simplified and Efficient: 40-byte fixed header, extension headers, and eliminated checksum improve performance
• Multiple Transition Paths: Dual-stack, tunneling, and translation provide flexibility
• Enterprise-Wide Impact: IPv6 affects all layers from applications to infrastructure
• Phased Deployment: Strategic planning enables gradual, controlled migration
• Business Benefits: Lower costs, better security, improved mobility, and future-proofing

📚 Next Steps:

• Assess your current infrastructure IPv6 readiness
• Develop an IPv6 address plan
• Create a phased deployment strategy
• Test dual-stack operation in a lab environment
• Train IT staff on IPv6 fundamentals
• Begin pilot deployment in non-critical segments
• Monitor, measure, and adjust your approach

The time to act on IPv6 is now. Organizations that strategically invest in IPv6 as part of their IT roadmap will be positioned for success in the evolving Internet landscape, while those who delay may face significant challenges and costs in the future.

Migrating from IPv4 to IPv6

Migrating from IPv4 to IPv6: Complete Overview Guide

📋 Prerequisites: This course requires theoretical knowledge and skills in IPv4, TCP/IP, Routing, NAT/NAPT, and QoS.

🎯 Course Objectives:

• Describe the primary differences between IPv4 and IPv6
• Understand operations of IPv6, RIPng, OSPFv3, DHCPv6, NAT-PT, MBGP, BGP4+, and transition technologies
• Design an IPv6 infrastructure solution for enterprise needs
• Design OSPFv3 routing solutions to meet organizational requirements

Table of Contents

1. Why IPv6?
2. What's New in IPv6?
3. Simplification of Header Format
4. Unicast, Multicast, and Anycast Addresses
5. Address Notation
6. Prefix Notation
7. Global Routing Prefixes
8. Interface IDs and EUI-64
9. Special Addresses
10. IPv6 Addresses with Embedded IPv4 Addresses
11. 6to4 Addresses
12. Link-Local and Unique Local Addresses
13. Anycast Addresses
14. Multicast Addresses

Why IPv6?

The IP version currently used in networks and the Internet is IP version 4 (IPv4). IPv4 was developed in the early '70s to facilitate communication and information sharing between government researchers and academics in the United States. At the time, the system was closed with a limited number of access points, and consequently the developers didn't envision requirements such as security or quality of service.

To its credit, IPv4 has survived for over 50 years and has been an integral part of the Internet revolution. But even the most cleverly designed systems age and eventually become obsolete. This is certainly the case for IPv4. Today's networking requirements extend far beyond support for web pages and email. Explosive growth in network device diversity and mobile communications, along with global adoption of networking technologies, new services, and social networks, are overwhelming IPv4 and have driven the development of a next-generation Internet Protocol.

📚 Historical Reference: RFC 2235, "Hobbes Internet Timeline," provides an interesting and humorous overview of the history of the Internet, starting in 1957 with the launch of Sputnik and the formation of ARPA by the Department of Defense in the United States. The RFC contains a list of yearly growth rate of hosts, networks, and domain registrations in the Internet.

The Evolution and Maturity of IPv6

IPv6 has been developed based on the rich experience we have from developing and using IPv4. Proven and established mechanisms have been retained, known limitations have been discarded, and scalability and flexibility have been extended. IPv6 is a protocol designed to handle the growth rate of the Internet and to cope with the demanding requirements on services, mobility, and end-to-end security.

When the Internet was switched from using Network Control Protocol (NCP) to Internet Protocol (IP) in one day in 1983, IP was not the mature protocol that we know today. Many of the well-known and commonly used extensions were developed in subsequent years to meet the growing requirements of the Internet. In comparison, hardware vendors and operating system providers have been supporting IPv6 since 1995 when it became a Draft Standard. In the decade since then, those implementations have matured, and IPv6 support has spread beyond the basic network infrastructure and will continue to be extended.

⚠️ Strategic Importance: It is very important for organizations to pay attention to the introduction of IPv6 as early as possible because its use is inevitable in the long term. IPv6 should be included in strategic planning. If organizations think about possible integration scenarios ahead of time and consider its introduction when investing in IT capital expenditures, organizations can save considerable cost and enable IPv6 more efficiently when it is needed.

Address Space Crisis and Regional Distribution

For historic reasons, organizations and government agencies in the United States used the largest part of the allocatable IPv4 address space. The rest of the world had to share what was left over. Some organizations used to have more IPv4 address space than the whole of Asia (where more than 50% of the world's population live). This is one explanation of why the deployment of IPv6 in Asia is much more common than in Europe and the United States.

The IPv4 address space has a theoretical limit of 4.3 billion addresses. However, early distribution methods allocated addresses inefficiently. Consequently, some organizations obtained address blocks much larger than they needed, and addresses that could be used elsewhere are now unavailable. If it were possible to reallocate the IPv4 address space, it could be used much more effectively, but this process is not possible, and a global reallocation and renumbering is simply not practical. In addition to that it would not buy much, as even 4.3 billion addresses would not suffice for long at the current growth rate.

We have to take into account that in the future we will need IP addresses for billions of devices. Vendors in all industries are developing monitoring, control, and management systems based on IP. The Autoconfiguration capability of IPv6 will be a necessity for many complex networks of today and tomorrow, and for the number of IP devices of all types. The management of such services can't be accomplished with traditional addressing methods, and Stateless Address Autoconfiguration will also help to reduce administrative costs for organizations.

The Problem with NAT

The extended address space and the restoration of the original end-to-end model of the Internet allows for the elimination of Network Address Translation (NAT), in which a single or a few public IPv4 address(es) are used to connect a high number of users with private addresses to the Internet by mapping the internal addresses to the public address(es). NATs were introduced as a short-term fix for solving the address space limitations with IPv4, since IPv6 was not ready yet (refer to RFC 1631; the original NAT specification was obsoleted by RFC 3022 in 2001).

NATs have become pretty common in IPv4 networks, but they create serious disadvantages in management and operation: in order to do the address mapping, NATs modify end node addresses in the IP header. Very often, Application Level Gateways (ALG) are used in conjunction with NAT to provide application-level transparency. There is a long list of protocols and applications that create problems when used in a NAT environment. IPsec and peer-to-peer applications are two well-known examples.

🚫 NAT Issues: Another known issue with NAT is the overlapping of private address space when merging networks, which requires either the renumbering of one of the networks or the creation of a complex address-mapping scheme. The amplification of limited address space, the primary benefit of NAT, is not needed with IPv6 and therefore is not supported by design.

Broadband Growth and Connected Devices

By introducing a more flexible header structure (Extension headers), the protocol has been designed to be open and extensible. In the future, new extensions can easily be defined and integrated in the protocol set. Based on the fact that IPv4 has been in use for more than 50 years, the development of IPv6 was based on the experience with IPv4 and focused on creating an extensible foundation; you can expect it to last a long time.

Broadband penetration rates in many countries continue to accelerate and, in some cases, have reached 65% or more. This level of always-on connectivity with substantial bandwidth capacity means that there is greater opportunity for devices to be connected. And many consumer electronic manufacturers have taken advantage of this. Online gaming is no longer the sole purview of games on PCs.

Gaming stations, such as Sony's PlayStation, Xbox, or Nintendo, have added capabilities to take them online. Many telecommunication carriers are providing television-type services (movies, audio content, etc.) over their IP networks. Even appliances, such as refrigerators, stoves, water heaters, and bathtubs, are getting connected. Many of these devices are being connected to facilitate things such as power management, remote control, and troubleshooting, and for telemetry/monitoring purposes.

🏙️ Smart Buildings and Cities: We are entering the age of smart buildings and smart cities. The end result of this network-enablement process is a greater number of devices that need addressing, many of which will have a minimum of one user interface. In these cases, the IPv6 address space, coupled with features such as Neighbor Discovery, Stateless Autoconfiguration, and Mobile IPv6, will help to usher in a new era of computerization in the home, but hopefully without the enormous deployment headache that it would cause if it were attempted with the current protocol.

The Wireless and Mobility Revolution

The growth of the wireless industry (both cellular and wireless networks) has been nothing short of phenomenal. In more and more countries the number of cell phones actually exceeds the number of people. In this world of continuous reachability and reliance on the ability to access information at any time, the mobility requirements for end users have become exceptionally important. From the carriers' perspective, especially those supporting multiple media access, leveraging IP as the method of transporting and routing packets makes sense. Smartphones access the Internet, play games with other users, make phone calls, and even stream video content.

Instead of supporting all of these functions using different transport protocols and creating intermediary applications to facilitate communications, it is far more efficient to leverage the existing network infrastructure of the Internet and a company's network. From a technical perspective, Mobile IPv6 is very elegant in its design, supporting mobile users in a highly efficient manner and providing the overlay mechanisms for users to maintain their connections when moving between networks, even if those networks do not use the same type of media access.

What's New in IPv6?

IPv6 is an evolution of IPv4. The protocol is installed as a software upgrade in most devices and operating systems. If you buy up-to-date hardware and operating systems, IPv6 is usually supported and needs only activation or configuration. In many cases it is activated by default. Currently available transition mechanisms allow the step-by-step introduction of IPv6 without putting the current IPv4 infrastructure at risk. Here is an overview of the main changes:

Extended Address Space

The address format is extended from 32 bits to 128 bits. This provides multiple IP addresses for every grain of sand on the planet. In addition, it also allows for hierarchical structuring of the address space in favor of optimized global routing.

Autoconfiguration

Perhaps the most intriguing new feature of IPv6 is its Stateless Address Autoconfiguration (SLAAC) mechanism. When a booting device in the IPv6 world comes up and asks for its network prefix, it can get one or more network prefixes from an IPv6 router on its link. Using this prefix information, it can autoconfigure for one or more valid global IP addresses by using either its MAC identifier or a private random number to build a unique IP address.

In the IPv4 world, we have to assign a unique IP address to every device, either by manual configuration or by using DHCP. SLAAC should make the lives of network managers easier and save substantial cost in maintaining IP networks.

💡 Practical Benefit: Furthermore, if we imagine the number of devices we may have in our homes that will need an IP address in the future, this feature becomes indispensable. Imagine reconfiguring your DHCP server at home when you buy a new television! Stateless Address Autoconfiguration also allows for easy connection of mobile devices, such as a smartphone, when moving to foreign networks.

Simplification of Header Format

The IPv6 header is much simpler than the IPv4 header and has a fixed length of 40 bytes. This allows for faster processing. It basically accommodates two times 16 bytes for the Source and Destination address and only 8 bytes for general header information.

Improved Support for Options and Extensions

IPv4 integrates options in the base header, whereas IPv6 carries options in so-called Extension headers, which are inserted only if they are needed. Again, this allows for faster processing of packets. The base specification describes a set of six Extension headers, including headers for routing, Quality of Service, and security.

The IPv4 Address Space and IPv6 Address Types

An IPv4 address has 32 bits and looks familiar. An IPv6 address has 128 bits and looks wild at first glance. Extending the address space was one of the driving reasons to develop IPv6, along with optimization of routing tables, especially on the Internet. This section will help you become familiar with the extended address space and will also explain how IPv6 addressing works and why it has been designed to be the way it is. There is a lot more to understand than just the 128-bit address. The address architecture has been extended and the large address space offers opportunity for new address designs. The IPv6 addressing architecture is defined in RFC 4291.

IPv4 knows unicast, broadcast, and multicast addresses. With IPv6, the broadcast address is not used anymore; multicast addresses are used instead. This is good news because broadcasts are a problem in most networks. The anycast address, a type of address introduced with RFC 1546, has already been used in the IPv4 world but will be used on a wider basis with IPv6.

Unicast, Multicast, and Anycast Addresses

An IPv6 address can be classified into one of three categories:

Address Type	Description
Unicast	A unicast address uniquely identifies an interface of an IPv6 node. A packet sent to a unicast address is delivered to the interface identified by that address.
Multicast	A multicast address identifies a group of IPv6 interfaces. A packet sent to a multicast address is processed by all members of the multicast group.
Anycast	An anycast address is assigned to multiple interfaces (usually on multiple nodes). A packet sent to an anycast address is delivered to only one of these interfaces, usually the nearest one.

Some General Rules

IPv6 addresses are assigned to interfaces as in IPv4, not to nodes as in OSI, so each interface of a node needs at least one unicast address. A single interface can also be assigned multiple IPv6 addresses of any type (unicast, multicast, and anycast). A node can therefore be identified by the address of any of its interfaces. It is also possible to assign one unicast address to multiple interfaces for load-sharing reasons, but if you do this, you need to make sure that the hardware and drivers support it.

🔍 Address Scope: IPv6 supports addresses of different scopes. There are global and nonglobal (e.g., link-local) scopes. Operationally, the use of nonglobal addresses has been introduced with IPv4 by using IP addresses from the private range or administratively scoped multicast addresses. The design of IPv6 includes the address scope in the base architecture. Every IPv6 address other than the unspecified address has a specific scope, which is a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. The scope of an address is encoded as part of the address. You can find a description of scopes in RFC 4007, "IPv6 Scoped Address Architecture."

Address Notation

An IPv6 address has 128 bits, or 16 bytes. The address is divided into eight 16-bit hexadecimal blocks separated by colons. For example:

2001:0db8:0000:0000:0262:b3ff:fe1e:8329

To make life easier, some abbreviations are possible. For instance, leading zeros in a 16-bit block can be skipped. The example address now looks like this:

2001:db8:0:0:262:b3ff:fe1e:8329

A double colon can replace consecutive zeros or leading or trailing zeros within the address. If we apply this rule, our address looks as follows:

2001:db8::262:b3ff:fe1e:8329

⚠️ Important Rule: Note that the double colon can appear only once in an address. The reason for this rule is that the computer always uses a full 128-bit binary representation of the address, even if the displayed address is simplified. When the computer finds a double colon, it expands it with as many zeros as are needed to get 128 bits. If an address had two double colons, the computer would not know how many zeros to add for each colon.

So the IPv6 address 2001:0db8:0000:0000:0056:abcd:0000:1234 can be represented in the following ways (note the two possible positions for the double colon):

2001:0db8:0000:0000:0056:abcd:0000:1234
2001:0db8:0:0:56:abcd:0:1234
2001:0db8::56:abcd:0:1234
2001:0db8:0:0:56:abcd::1234

Standardization of Address Representation

There are so many different ways to write and abbreviate IPv6 addresses and this can cause operational troubles. If you want to do lookups in a database or a spreadsheet, you have to make sure that everybody uses the same format to store addresses; otherwise, you won't be able to find out if an address is already in the list. For this purpose the best option is probably to just use the full format, as it's the only unambiguous format. Also be aware that some systems are case sensitive, so you need to define whether to use capitals or not.

For the purpose of making administration easier, an RFC was written to standardize IPv6 address representation. It also discusses the issues that can arise when storing IPv6 addresses in databases and spreadsheets for lookup. You need solid rules for address representation to be able to find addresses. Probably for these cases it is best to use the full address representation, as it is the only unambiguous one. For all other cases, RFC 5952 recommends using the following rules:

• Leading zeros must be suppressed.
• A single 16-bit 0000 field must be represented as 0 and should not be replaced by a double colon.
• Shorten as much as possible.
• Use a double colon whenever possible.
• Always shorten the largest number of zeros.
• If two blocks of zero are equally long, shorten the first one.
• Use lowercase for a, b, c, d, e, f.

Mixed IPv4/IPv6 Notation

In environments where IPv4 and IPv6 nodes are mixed, another convenient form of IPv6 address notation is to put the values of an IPv4 address into the four low-order bytes of the address. An IPv4 address of 192.168.0.2 can be represented as x:x:x:x:x:x:192.168.0.2, and an address of 0:0:0:0:0:0:192.168.0.2 can be written as ::192.168.0.2. If you prefer, you can also write ::C0a8:2. This is the hex representation for 192.168.0.2.

For the representation of an IPv6 address followed by a port number, the best way is to put the IPv6 address in square brackets, followed by a colon and the port number. So it may look like this:

[2001:db8::1]:443

Prefix Notation

The notation for prefixes has also been specified in RFC 4291. A global routing prefix is the high-order bits of an IP address used to identify the subnet or a specific type of address. It was called the format prefix in earlier RFCs. The prefix notation is very similar to the way IPv4 addresses are written in CIDR (Classless Interdomain Routing) notation, and it is also commonly used for subnetted IPv4 addresses. The notation appends the prefix length, written as a number of bits with a slash, which leads to another format:

IPv6 address/prefix length

The prefix length specifies how many leftmost bits of the address specify the prefix. This is another way of noting a subnet mask. Remember, a subnet mask specifies the bits of the IPv4 address that belong to the network ID. The prefix is used to identify the subnet that an interface belongs to and is used by routers for forwarding.

Consider the IPv6 prefix notation 2001:db8:1200::/40. The /40 indicates that the first 40 bits represent the network prefix, and the remaining 88 bits are available for host addressing within that network.

Global Routing Prefixes

The current assignment of reserved prefixes and special addresses, such as link-local addresses or multicast addresses, is outlined in the IPv6 address architecture. The major part of the address space (over 80 percent) is unassigned with the exception of a few special cases. This leaves room for future assignments. All address ranges not listed in the standard tables are currently reserved or unassigned. The Internet Assigned Numbers Authority (IANA) currently assigns only out of the binary range starting with 001.

Some special addresses are assigned out of the reserved address space with the binary prefix 0000 0000. These include the unspecified address, the loopback address, and IPv6 addresses with embedded IPv4 addresses, which we discuss in detail later.

Unicast addresses can be distinguished from multicast addresses by their prefixes. Globally unique unicast addresses have a high-order byte starting with 001. An IPv6 address with a high-order byte of 1111 1111 (ff in hex) is always a multicast address. Anycast addresses are taken from the unicast address space, so they can't be identified as anycast just by looking at the prefix. If you assign the same unicast address to multiple interfaces, thereby making it an anycast address, you have to configure the interfaces so they all know that this address is an anycast address.

Global Unicast Address Format

Global unicast addresses are identified by the binary prefix 001. RFC 4291 defines the global unicast address format as follows:

Field	Description
Global Routing Prefix	The global routing prefix identifies the address range allocated to a site. This part of the address is assigned by the international registry services and the Internet Service Providers (ISPs) and has a hierarchical structure.
Subnet ID	The subnet ID identifies a link within a site. A link can be assigned multiple subnet IDs. A local administrator of a site assigns this part of the address.
Interface ID	The interface ID identifies an interface on a subnet and must be unique within that subnet. The interface ID is always 64 bits, so therefore an IPv6 subnet is always a /64 subnet.

International Registry Services and Current Address Allocations

The international allocation of IPv6 addresses has been delegated to several regional registry services:

• ARIN (American Registry for Internet Numbers) for North America and Sub-Saharan Africa
• RIPE NCC (Reseau IP Europeens Network Coordination Centre) for Europe, the Middle East, Central Asia, and North Africa
• APNIC (Asia Pacific Network Information Centre) for the Asia/Pacific region
• LACNIC (Latin American and Caribbean Internet Addresses Registry) for Latin America
• AfriNIC (African Network Information Centre) went into operation in 2005 to cover Africa in the future

Each of these registries has information on its site about address allocation issues, current practices, and procedures.

The Interface ID

Addresses in the prefix range 001 to 111 should use a 64-bit interface identifier that follows the EUI-64 (Extended Unique Identifier) format (except for multicast addresses with the prefix 1111 1111). The EUI-64 is a unique identifier defined by the Institute of Electrical and Electronics Engineers (IEEE). Appendix A of RFC 4291 explains how to create EUI-64 identifiers.

An interface uses an identifier following the EUI-64 format during Stateless Address Autoconfiguration. For example, when an interface autoconfigures for a link-local address on an Ethernet interface using its MAC address, the 64-bit interface identifier has to be created from the 48-bit (6-byte) Ethernet MAC address.

Creating an EUI-64 Interface Identifier

First, the hex digits 0xff-fe are inserted between the third and fourth bytes of the MAC address. Then the universal/local bit, the second low-order bit of 0x00 (the first byte) of the MAC address, is complemented. The second low-order bit of 0x00 is 0, which, then complemented, becomes 1; as a result, the first byte of the MAC address becomes 0x02.

Therefore, the IPv6 interface identifier corresponding to the Ethernet MAC address 00-02-b3-1e-83-29 is 02-02-b3-ff-fe-1e-83-29. This example discusses only the EUI-64 creation process. Many other steps occur during Stateless Address Autoconfiguration.

🔗 Link-Local Address Example: The link-local address of an interface is the combination of the prefix fe80::/64 and a 64-bit interface identifier expressed in IPv6 colon-hexadecimal notation. Therefore, the MAC-based link-local address of the previous example interface, with prefix fe80::/64 and interface identifier 02-02-b3-ff-fe-1e-83-29, is fe80::0202:b3ff:fe1e:8329. This is described in RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks."

Special Addresses

There are a number of special addresses that we need to discuss. The first part of the IPv6 address space with the prefix of 0000 0000 is reserved. Out of this prefix, special addresses have been defined as follows:

The Unspecified Address

The unspecified address has a value of 0:0:0:0:0:0:0:0 and is therefore also called the all-zeros address. It is comparable to 0.0.0.0 in IPv4. It indicates the absence of a valid address, and it can, for example, be used as a Source address by a host during the boot process when it sends out a request for address configuration information.

If you apply the notation conventions discussed earlier in this chapter, the unspecified address can also be abbreviated as ::. It should never be statically or dynamically assigned to an interface, and it should not appear as a Destination IP address or within an IPv6 Routing header. It is sometimes used in configuration files for software to tell a program to use any IPv6 address configured on an interface.

The Loopback Address

The IPv4 loopback address, 127.0.0.1, is probably familiar to you. It is helpful in troubleshooting and testing the IP stack because it can be used to send a packet to the protocol stack without sending it out on the subnet. With IPv6, the loopback address works the same way and is represented as 0:0:0:0:0:0:0:1, abbreviated as ::1. It should never be statically or dynamically assigned to an interface.

IPv6 Addresses with Embedded IPv4 Addresses

Because the transition to IPv6 will be gradual, two special types of addresses have been defined for backward compatibility with IPv4. Both are described in RFC 4291:

IPv4-Compatible Address (Deprecated)

This type of address is used to tunnel IPv6 packets dynamically over an IPv4 routing infrastructure. IPv6 nodes that use this technique are assigned a special IPv6 unicast address that carries an IPv4 address in the low-order 32 bits. This address type has so far rarely been used and was deprecated in RFC 4291. New or updated implementations will no longer need to support this type of address.

IPv4-Mapped IPv6 Address

This type of address is used to represent the addresses of IPv4-only nodes as IPv6 addresses. An IPv6 node can use this address to send a packet to an IPv4-only node. The address also carries the IPv4 address in the low-order 32 bits of the address.

The two addresses are pretty much the same. The only difference is the 16 bits in the middle. When they are set to 0, the address is an IPv4-compatible IPv6 address; if these bits are set to 1, it is an IPv4-mapped IPv6 address.

6to4 Addresses

The IANA has permanently assigned a 13-bit TLA* identifier for 6to4 operations within the global unicast address range (001). 6to4 is one of the mechanisms defined to let IPv6 hosts or networks communicate over an IPv4-only infrastructure. The prefix has a total length of 48 bits. The IPv4 address in the prefix must be a public IPv4 address and is represented in hexadecimal notation.

For instance, if you configure an interface for 6to4 with an IPv4 address of 62.2.84.115, the 6to4 prefix is 2002:3e02:5473::/48. Through this interface, all IPv6 hosts on this link can tunnel their packets over the IPv4 infrastructure.

📝 Note: * A TLA Identifier was the top-level part of the early IPv6 global unicast address format, meant to identify large ISPs or national registries.

Link-Local and Unique Local IPv6 Addresses

With IPv4, organizations often use IP addresses from the private ranges as defined in RFC 1918. The addresses reserved for private use should never be forwarded over Internet routers but should instead be confined to the organization's network. For connection to the Internet, Network Address Translation (NAT) maps internal private addresses to publicly registered IPv4 addresses. The original IPv6 specification allocated two separate address spaces (scopes) for link- and site-local use, both identified by their prefixes. The prefix for site-local addresses was fec0::/10.

Link-Local Addresses

A link-local address is for use on a single link and should never be routed. It doesn't need a global prefix and can be used for Autoconfiguration mechanisms, for Neighbor Discovery, and on networks with no routers, so it is useful for creating temporary networks.

💻 Practical Example: Let's say you meet your friend in a conference room and you want to share files on your computers. You can connect your computers using a wireless network or a cable between your Ethernet interfaces, and you can share files without any special configuration by using the link-local address.

In hexadecimal notation, a link-local address is identified by the prefix fe80::/10.

Unique Local IPv6 Unicast Addresses (ULA)

The replacement for site-local addresses is called Unique Local IPv6 Unicast Address (ULA). It is specified in RFC 4193. These addresses are globally unique but should not be routed to the global Internet. They are designed to be used within corporate sites or confined sets of networks.

The characteristics of unique local IPv6 unicast addresses are the following:

• Have a unique, global prefix which allows for filtering at network boundaries
• Allow for private connection of networks without the risk of address conflicts and the consequence of having to renumber one of the sites
• Are independent of ISP
• Can be used for internal communication without an Internet connection
• Can be used by applications just like regular global unicast addresses

For the unique-local IPv6 address, RFC 4193 specifies a prefix of fc00::/7. The 8th bit is currently set to 1 and specifies local administration of the prefix. Setting the 8th bit to 0 may be used in the future for centrally administrated addresses. For the moment, it was decided to standardize only a locally assigned version. The centrally assigned form may be defined in the future if a strong need is identified.

Anycast Address

Anycast addresses are designed to provide redundancy and load balancing in situations where multiple hosts or routers provide the same service. Anycast was not created for IPv6; it was defined in RFC 1546 in 1993 as an experimental specification to be used with IPv4. The RFC allots a special prefix for anycast, which would make an anycast address recognizable as such based on the prefix. Anycast was meant to be used for services such as DNS and HTTP. The RFC discusses possible modifications to TCP to deal with these addresses that are not globally unique.

In practice, anycast has not been implemented as it was designed to be. Often a method called shared unicast address is chosen. This method is implemented by assigning a regular unicast address to multiple interfaces and creating multiple entries in the routing table. In this case the network and transport layer assume that it is a globally unique IP address.

🌐 DNS Root Servers: An exception to this rule is if the application uses independent stateless request/reply transactions - for instance, DNS over UDP. The root DNS servers in the Internet are set up using shared unicast addresses. As this procedure does not require any support from the network layer, it can also be used with IPv6.

From the beginning, the IPv6 developers considered anycast to be incorporated in the network layer according to RFC 1546. No special prefix was assigned. IPv6 anycast addresses are in the same address range as global unicast addresses, and each participating interface must be configured to have an anycast address. Within the region where the interfaces containing the same anycast addresses are, each host must be advertised as a separate entry in the routing tables.

Anycast Use Cases

Within one network where a group of routers can provide access to a common routing domain, they can be assigned a single address. When a client sends a packet to this address, it will be forwarded to the next available router. One example is the 6to4 relay anycast address that is specified in RFC 3068. The Mobile IPv6 specification also uses anycast addresses.

⚠️ Anycast Limitations: When using anycast addresses, we have to be aware that the sender has no control over which interface the packet will be delivered to. This decision is taken on the level of the routing protocol. When a sender sends multiple packets to an anycast address, the packets may arrive at different destinations due to routing table instability or changes during the requests. If there is a series of requests and replies or if the packet has to be fragmented, this may cause problems.

Multicast Address

This section covers the multicast address format. For a description of multicast and Multicast Listener Discovery (MLD), also known as Multicast Group Management, refer to the relevant RFCs.

A multicast address is an identifier for a group of nodes identified by the high-order byte ff, or 1111 1111 in binary notation. The multicast prefix is ff00::/8. A node can belong to more than one multicast group. When a packet is sent to a multicast address, all members of the multicast group process the packet. Multicast exists in IPv4, but it has been redefined and improved for IPv6.

Multicast Address Format

The first byte identifies the address as a multicast address. The next four bits are used for Flags, defined as follows:

• The first bit of the Flag field must be zero; it is reserved for future use.
• The second bit indicates whether this multicast address embeds the Rendezvous Point. A Rendezvous Point is a point of distribution for a specific multicast stream in a multicast network (RFC 3956).
• The third bit indicates whether this multicast address embeds prefix information (see also RFC 3306).
• The last bit of the Flag field indicates whether this address is permanently assigned, one of the well-known multicast addresses assigned by the IANA—or a temporary multicast address. A value of zero for the last bit defines a well-known address; a value of one indicates a temporary address.

The Scope field is used to limit the scope of a multicast address.

Well-Known Multicast Addresses

According to RFC 4291, the last 12 bits of the address carry the multicast group ID. RFC 3307, "Allocation Guidelines for IPv6 Multicast Addresses," refers to a 32-bit group ID. RFC 2375 defines the initial assignment of IPv6 multicast addresses that are permanently assigned. Some assignments are made for fixed scopes, and some assignments are valid over all scopes.

Multicast Address	Description
FF02::1	All nodes on the local network segment
FF02::2	All routers on the local network segment
FF02::5	All OSPF routers
FF02::6	All OSPF designated routers
FF02::9	All RIPng routers

Conclusion

This overview has covered the fundamental concepts of IPv6 and the compelling reasons for migrating from IPv4. We've explored the extended address space, simplified header format, autoconfiguration capabilities, and the various address types including unicast, multicast, and anycast.

Key takeaways include:

• IPv6 provides virtually unlimited address space with 128-bit addresses
• Stateless Address Autoconfiguration (SLAAC) simplifies network management
• The simplified header format improves routing efficiency
• IPv6 eliminates the need for NAT, restoring end-to-end connectivity
• Multiple address types support various networking scenarios
• Transition mechanisms allow gradual migration from IPv4

📚 Next Steps: With this foundation in IPv6 addressing and architecture, you're now prepared to explore advanced topics such as routing protocols (RIPng, OSPFv3), DHCPv6 configuration, transition mechanisms, and enterprise deployment strategies. Strategic planning and early adoption will position your organization for long-term success in the IPv6 era.