Understanding IPv6: Complete Migration Guide from IPv4 to IPv6
Table of Contents
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"
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 |
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
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
IPv4: 232 = 4,294,967,296 addresses
IPv6: 2128 = 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.
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).
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:
- Hop-by-Hop Options header
- Routing header
- Fragment header
- Destination Options header
- Authentication header
- 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.
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.
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.
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.
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
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
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
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:
- Scenario 1: Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure
- Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network infrastructure
- Scenario 3: IPv6 dominant network infrastructure with some IPv4-capable nodes/applications
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:
- 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
- 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.
No comments:
Post a Comment