Skip to main content

IPv4 guide

IPv4 vs IPv6: Key Differences and Migration Guide

Understanding-the-Difference-Between-Ipv4-and-IPv6-Thumbnail-ilease

IPv4 vs IPv6: the short answer

IPv4 and IPv6 are two versions of the Internet Protocol that identify interfaces and carry packets between networks. IPv4 uses 32-bit addresses such as 192.0.2.10; IPv6 uses 128-bit addresses such as 2001:db8::10. IPv6 provides a vastly larger address space and a different packet and configuration model, but it does not automatically make a service faster, encrypted, private, or publicly reachable.

For most public services, the practical decision is not an immediate choice of one protocol. It is how to provide and observe both paths while users, networks, applications, and dependencies still have different capabilities. Dual stack gives a service native IPv4 and IPv6 reachability. Some controlled environments can instead use IPv6-only access with translation or application gateways for remaining IPv4 destinations. The right design follows measured client reachability, dependency support, security policy, operating capacity, and rollback requirements.

If a workload still needs IPv4, treat that need as an explicit continuity plan rather than a reason to postpone IPv6. Record the required prefix size, regions, origin ASN, routing and RPKI authority, reputation criteria, term, abuse responsibilities, and exit plan before reviewing managed IPv4 leasing or an IPv4 transfer purchase.

IPv4 and IPv6 differences at a glance

Operational differences between IPv4 and IPv6
AreaIPv4IPv6What an operator should verify
Address size32 bits128 bitsAddress and prefix plans, IPAM support, logs, databases, APIs, and user interfaces
Text formFour decimal octets, for example 192.0.2.10Hexadecimal groups with defined zero compression, for example 2001:db8::10Parsers accept valid forms and store addresses as addresses, not undersized strings or integers
DNSA recordsAAAA recordsEvery published address reaches the intended service through routing, firewall, load balancer, and application layers
Typical local scopeRFC 1918 private space is widely used with NAT44Link-local addresses are fundamental; Unique Local Addresses can serve local scopesScope, route, source-address selection, DNS, and policy—not the spelling of the address—match the intended use
ConfigurationManual configuration and DHCPv4 are commonRouter Advertisements, SLAAC, DHCPv6, prefix delegation, and manual configuration can have different rolesHosts receive addresses, default routes, DNS information, lifetimes, and delegated prefixes as designed
Neighbor discoveryARP is commonly used to map local IPv4 addresses to link-layer neighborsNeighbor Discovery uses ICMPv6 and also supports router discovery and address-resolution functionsLayer-2 controls, ICMPv6 policy, first-hop security, and monitoring understand the actual protocol
Packet headerA variable-length header with options and a header checksumA 40-byte base header plus optional extension headers, with no checksum in the base headerFirewalls, load balancers, telemetry, and middleboxes correctly process the traffic they claim to support
FragmentationA source or an IPv4 router can fragment when allowedOnly the source fragments; routers do notPath MTU Discovery and required ICMP or ICMPv6 messages work across the complete path
BroadcastSupports broadcast as well as unicast and multicastHas no broadcast; uses unicast, multicast, and anycastDiscovery and operational tools do not assume IPv4 broadcast behavior
SecurityCan use IPsec and higher-layer encryptionCan use IPsec and higher-layer encryptionEncryption, authentication, filtering, patching, and monitoring are actually configured and tested
CoexistenceCannot directly exchange IP packets with IPv6-only endpointsCannot directly exchange IP packets with IPv4-only endpointsNative paths, DNS, translation, proxies, or tunnels cover every required dependency and failure mode

Address space, notation, and prefixes

IPv4's 32-bit field provides exactly 232 possible values before subtracting protocol-reserved, special-purpose, private, and otherwise non-publicly usable space. IPv6 expands the field to 128 bits. The larger space supports more addressing hierarchy and far more interface addresses, but prefix policy still matters: a large numeric pool is not permission to invent arbitrary routes or ignore provider and registry allocation rules.

Both protocols use CIDR prefix lengths. In 192.0.2.0/24, the first 24 bits identify the IPv4 prefix. In 2001:db8:1234:5678::/64, the first 64 bits identify the IPv6 prefix. A slash value is not found by counting visible zeros. Read it from the allocation, route, interface, Router Advertisement, DHCP, or IPAM record. The IPv4 address guide explains IPv4 format and usable scope; the IPv6 prefix guide covers compression, on-link lengths, and delegated prefixes.

Do not turn the address size into a host-count target. A sound IPv6 plan reserves hierarchy for sites, regions, security zones, and future change. It also distinguishes the provider or RIR allocation, a delegated site prefix, a subnet prefix, and an interface address. Those are related records, not interchangeable labels.

Public, private, local, and reachable are different facts

RFC 1918 defines three private IPv4 ranges for internal use. These addresses are not expected to be routed across the public Internet, so networks commonly translate them to public IPv4 addresses at an edge. IPv6 has link-local addresses and Unique Local Addresses for different non-global scopes. A ULA is not the IPv6 spelling of an RFC 1918 address with identical behavior, and it should not be placed in public DNS as if it were globally reachable.

A global IPv6 address also does not mean “open to the Internet.” A packet still needs a route, an accepting firewall or security policy, a listening service, and a valid return path. Conversely, NAT is not a firewall. Translation changes address or port information and may create state, but access policy, segmentation, authentication, patching, and logging remain separate controls.

Address and reachability questions to answer for both protocols
QuestionEvidenceCommon mistake
Which scope is intended?Allocation, IPAM entry, prefix length, interface, VRF or segment, and route tableTreating every non-public address as interchangeable
Can the path route it?Origin and upstream routes, local routes, return path, external observations, and failure testsAssuming address assignment creates reachability
Will policy admit it?Firewall, security group, ACL, load balancer, host policy, and application listenerUsing NAT presence or absence as the security verdict
Can names resolve correctly?Authoritative and recursive DNS tests for A and AAAA, TTLs, split views, and negative answersPublishing AAAA before the IPv6 service path is ready
Can operations see it?IPv4- and IPv6-capable logs, metrics, traces, flow data, abuse records, and alertsLaunching a path that disappears into an IPv4-only dashboard or field

Headers, fragmentation, and Path MTU

The IPv6 base header is fixed at 40 bytes, but that does not mean every IPv6 packet has a fixed total header length. Optional information is carried in extension headers between the base header and the upper-layer protocol. IPv4 keeps options in its variable-length header. Equipment that recognizes only the common case can still drop, misclassify, or obscure valid traffic, so support claims need packet-level and application-level tests.

IPv4 routers may fragment a packet unless policy and the Don't Fragment behavior prevent it. IPv6 routers do not fragment forwarded packets; the source adjusts to the path and may use a Fragment header. Both designs depend on useful control messages and correct Path MTU handling. Blocking all ICMPv6 because “ICMP is unsafe” can break basic IPv6 operation. Test large responses, tunnels, VPNs, encapsulation, and asymmetric paths rather than validating only a tiny ping.

IPv6 removes the checksum from its base header, while upper-layer protocols and link layers still provide their own integrity checks. That protocol difference alone does not prove lower latency or higher throughput. Packet size, extensions, hardware support, routes, congestion, loss, DNS, connection setup, content location, and application behavior can dominate.

Is IPv6 faster than IPv4?

Neither protocol is universally faster. IPv6 can perform better when it receives a cleaner native route or avoids overloaded translation. IPv4 can perform better when an IPv6 route, peering relationship, resolver answer, firewall, tunnel, or content edge is weaker. Connection-racing techniques can hide some failures by trying usable destinations in a controlled order, but they do not repair a broken path.

Measure both paths from real client networks. Separate DNS time, connection setup, TLS, time to first byte, throughput, loss, retransmissions, Path MTU behavior, and application errors. Keep protocol labels in telemetry so an aggregate success rate does not conceal an IPv6-only regression. Compare the same content, region, cache state, and test window before attributing a difference to the IP version.

Do not optimize against one global adoption percentage. Public dashboards use different populations and methods, and a worldwide average does not describe a specific customer base or dependency. Use fresh measurements from the networks and regions the product actually serves.

Is IPv6 more secure than IPv4?

IPv6 is not automatically encrypted. IPsec provides network-layer security services for both IPv4 and IPv6, and it protects traffic only when suitable policies, peers, algorithms, keys, and operational controls are configured. TLS, SSH, application authentication, and other higher-layer protections remain necessary according to the threat model.

A large address space can change the economics of broad address scanning, but it does not remove exposed services, guessed addresses, DNS discovery, on-link attacks, compromised endpoints, credential abuse, route leaks, or application vulnerabilities. IPv6 also introduces protocol-specific operating surfaces, including Neighbor Discovery, Router Advertisements, extension headers, multiple addresses, and ICMPv6 dependencies. Security tooling and staff need visibility and policy for both families.

Apply equivalent intent rather than mechanically copying IPv4 rules. Deny unneeded inbound traffic, allow required control traffic precisely, validate source and route policy where appropriate, protect the first hop, patch endpoints, monitor egress, and test every enforcement point. If an application is reachable over IPv6, an IPv4-only WAF rule, allowlist, rate limit, inventory, or incident query is incomplete.

SLAAC, DHCPv6, and IPv6 address privacy

IPv6 hosts normally create a link-local address and can learn prefixes and a default router through Router Advertisements. SLAAC combines an advertised prefix with an interface identifier. The identifier is not universally the device's permanent MAC address: current systems may use stable, semantically opaque identifiers, temporary randomized identifiers, or implementation-specific methods. DHCPv6 can supply addresses or other configuration, while prefix delegation can assign a larger prefix to a downstream router. The roles of Router Advertisements and DHCPv6 are not identical.

An interface can hold several IPv6 addresses at once, including link-local, stable, temporary, or service-specific addresses. Source-address selection decides which candidate is used for a connection. RFC 8981 temporary addresses reduce one window for simple address-based correlation; they do not hide the network prefix, packet timing, DNS name, cookies, authenticated identity, or payload metadata. Privacy claims must therefore describe the whole system, not one address-generation option.

Before deployment, verify router lifetimes, DNS configuration, duplicate-address detection, prefix withdrawal and renumbering, host behavior after sleep or roaming, and what happens when only one configuration service fails. A host having an IPv6 address is not proof that it has a working default route, DNS, Path MTU, or destination path.

DNS and dual-stack service readiness

DNS normally maps a name to IPv4 with an A record and to IPv6 with an AAAA record. Publishing both allows a capable client to choose a destination using its network and address-selection behavior. It also creates two production paths that must reach equivalent service content, certificates, redirects, authentication, rate limits, and observability.

Validate from IPv4-only, IPv6-only, and dual-stack networks. Query the authoritative and recursive answers, connect to each address directly with the intended Host name and TLS SNI, and follow redirects. Check CDN or load-balancer origin health, source-IP handling, forwarded headers, allowlists, webhooks, email, third-party APIs, monitoring agents, and administrative access. A successful browser load on the one network is not end-to-end evidence.

IPv4 and IPv6 coexistence patterns

Common coexistence patterns and their operating tradeoffs
PatternBest fitWhat it addsAcceptance evidence
Native dual stackPublic services and networks that must accept both client families directlyTwo address, DNS, routing, security, and observation pathsEquivalent service behavior and explicit failure tests over native IPv4 and IPv6
IPv6-only with NAT64 and DNS64Controlled client networks whose IPv4 destinations and applications have been inventoriedTranslation state, synthesized DNS answers, literal-address and protocol compatibility concernsEvery required IPv4 dependency works through the translator, including failure and capacity cases
Application proxy or gatewayHTTP, API, load-balancing, or other bounded services where the gateway can terminate one family and originate the otherTrust, identity, logging, header, certificate, capacity, and availability boundariesClient identity and policy remain correct, and gateway loss has a tested response
TunnelSpecific links or temporary reachability where native service is unavailableEncapsulation, overhead, MTU, route, provider, monitoring, and failure dependenciesPath MTU, failover, route withdrawal, security, ownership, and removal criteria are documented and tested

Translation is not exclusive to IPv4. NAT64 translates between IPv6 clients and IPv4 servers under a defined architecture, and other translation approaches exist. However, translation does not make the protocols directly interoperable or remove application assumptions. Literal IPv4 addresses, address data embedded in protocols, inbound connections, referrals, logging formats, and access rules can all require special handling.

A practical IPv4-to-IPv6 migration workflow

  1. Define the service outcome. Name the users, networks, applications, availability target, compliance boundary, address-family requirement, and business reason. Decide what “IPv6 ready” will mean in observable terms.
  2. Inventory the complete path. Record DNS, addresses, prefixes, IPAM, RIR or provider records, routes, ASN, RPKI, firewalls, load balancers, hosts, containers, applications, databases, libraries, identity controls, dependencies, monitoring, support, and abuse workflows.
  3. Measure the baseline. Capture success, latency, loss, errors, traffic share, client regions, dependency behavior, and incidents by address family. Preserve enough IPv4 evidence to detect regressions during change.
  4. Design addressing and routing. Obtain legitimate IPv6 space, allocate a hierarchy, document prefix and route ownership, prepare route filters and RPKI where applicable, and avoid address plans tied to one short-lived topology.
  5. Make security and operations family-complete. Update policy, first-hop controls, DDoS handling, WAF and rate limits, logs, SIEM fields, inventory, vulnerability scans, backups, support runbooks, and escalation paths for IPv6.
  6. Enable one bounded path. Start with an internal service, test hostname, selected region, or small client cohort. Do not publish broad AAAA records before the entire route to the intended application is healthy.
  7. Test protocol and application behavior. Use IPv4-only, IPv6-only, and dual-stack clients. Test DNS, TLS, redirects, authentication, uploads, large responses, PMTU, APIs, webhooks, email, third parties, administrative access, failure, recovery, and rollback.
  8. Observe a staged rollout. Compare family-specific service levels, route visibility, resolver behavior, security events, help requests, and dependencies. Expand only against stated thresholds and keep a named rollback owner.
  9. Choose the long-term coexistence model. Keep native dual stack where both client families remain material; use IPv6-only plus a verified transition service only where the controlled environment and dependencies support it.
  10. Review IPv4 continuity separately. Forecast the prefixes, regions, routing authority, term, reputation, abuse, renewal, and exit needs that remain. Use the IPv4 operations knowledge base to turn those needs into verifiable controls.

Should you use IPv4, IPv6, or both?

A new public service usually needs evidence for both protocols because the reachable audience and upstream dependencies are mixed. Supporting IPv6 expands native reachability for IPv6-capable networks; retaining IPv4 supports users and systems that have not completed the transition. The exact answer can differ for a public website, enterprise branch, mobile access network, data center, private service, embedded product, or isolated management plane.

An IPv6-only design can be a good controlled target when client platforms, DNS, translation or proxy requirements, dependencies, operations, and rollback have been proven. Removing IPv4 merely because IPv6 addresses exist is not proof. Likewise, keeping an undocumented pool of scarce IPv4 space forever is not a strategy. Assign an owner, measurement, review date, and exit condition to each dependency.

i.lease focuses on IPv4 resource continuity: qualified address supply, registry and routing context, reputation, abuse operations, and lifecycle controls within the agreed service scope. It does not make an application IPv6-compatible or replace the customer's network architecture and security review. A useful request states the remaining IPv4 need and the IPv6 migration boundary separately.

IPv4 vs IPv6 FAQ

What is the main difference between IPv4 and IPv6?

The most visible difference is address size: IPv4 uses 32 bits and IPv6 uses 128 bits. They also differ in header design, configuration, local discovery, fragmentation, DNS records, and operating practices. Applications and networks must explicitly support each protocol path.

Is IPv6 faster than IPv4?

Not universally. Either path can be faster depending on routing, peering, translation, DNS, content placement, MTU, loss, congestion, and implementation. Measure equivalent transactions by address family from the client networks that matter.

Is IPv6 automatically more secure?

No. IPv6 does not automatically encrypt traffic or apply a firewall. IPsec can protect IPv4 or IPv6 when configured, and both protocols still require appropriate filtering, authentication, patching, monitoring, and application security.

Does IPv6 replace NAT and firewalls?

IPv6's large address space reduces the address-conservation reason for NAT44, but translation mechanisms such as NAT64 still exist. Translation and firewall policy are different functions. Global IPv6 addresses can and should be filtered according to service policy.

Can a device use IPv4 and IPv6 at the same time?

Yes. A dual-stack device can hold addresses and routes for both families and select a usable destination for each connection. Operators still need to test DNS, source-address selection, failure behavior, policy, and observability for both paths.

Should a new service support both IPv4 and IPv6?

Many public services should plan for both while their users and dependencies remain mixed. The decision should come from measured audience reachability, dependency support, security and operations readiness, service objectives, and a tested rollback—not a global average alone.

How do I test whether a site really supports IPv6?

Resolve its AAAA record, connect over an IPv6-capable network with the intended hostname and TLS SNI, and test the complete user journey. Also validate IPv6-only and dual-stack behavior, redirects, APIs, third parties, large transfers, monitoring, and failure recovery.

Will IPv6 make IPv4 disappear?

IPv6 reduces dependence on scarce IPv4 space, but the protocols continue to coexist across users, services, and dependencies. Plan remaining IPv4 as an explicit, reviewed requirement while expanding and verifying IPv6 instead of relying on a universal retirement date.

Primary technical sources

Tags

  • #ipv4
  • #ipv6
Back to Blog