The Time Is Still Now for IPv6
Why can’t IPv6 be avoided? How insanely big is the IPv6 address space, and can we actually run out of IPv6 addresses? Is IPv6 faster and more secure than IPv4? Understanding the answers to these questions is key to understanding and working with IPv6 as its adoption expands.
Now — while we still have time before the vast majority of the Internet is using IPv6 — is the ideal time to prepare ourselves for and educate others about this “new” protocol, which was actually designed in the late 90s. The latter is the focus of a college course I’ve been teaching for 10 years to equip the next generation of our fellow Internet community members for the future of our online world. Read on for the answers to those critical questions and much more in this CliffNotes® version of my IPv6 college course.
The New Internet IPv6 Hall of Fame
From the time I wrote my first blog post for the American Registry for Internet Numbers (ARIN) nearly six years ago, a lot has happened!
It was a great honor and privilege to receive a certificate and to be inducted into the IPv6 Forum’s New Internet IPv6 Hall of Fame as an IPv6 Evangelist on 22 November 2021. The IPv6 Forum created the Evangelist honor to recognize efforts of individuals who push forward the development and deployment of IPv6, and the designation will show my future students how connected I am to the new protocol.
I created and taught for Finger Lakes Community College (FLCC) what I believe to be the first college course in the world dedicated solely to IPv6. The course ran for the first time in the summer of 2012. Ten years later, I continue to teach CSC 206 (I purposely requested that this 200-level course get the number 206 as a tribute to IPv6) — a course simply known as “IPv6” — as a summer session course. In addition to providing college credit, it prepares students for the IPv6 Forum Certified Network Engineer (Silver) certification, which verifies students’ knowledge of and hands-on skills in IPv6. My students take the certification exam at the end of the course.
Why We Need IPv6
32-bit IPv4 (Internet Protocol version 4) addresses consist of four decimal (base 10) numbers between 0 and 255 (with restrictions), separated by periods in dotted-decimal notation (ex. 192.168.1.1).
128-bit IPv6 (Internet Protocol version 6) addresses are four times the length of IPv4 addresses, and consist of 32 hexadecimal (base 16) digits (shortcut notations can be used to represent the addresses with less than 32 hex digits), with groups of four digits separated by colons (ex. 2001:0db8:000f:0052:0000:0000:0000:1337, which can be expressed as 2001:db8:f:52::1337). Each group of four digits is referred to as a hextet.
IPv6 provides identification and location, through an IP address, to allow computers and devices to find each other and communicate locally on networks as well as remotely, including via routing through the Internet. IPv6 is designed to replace IPv4, the almost-40-year-old protocol. Deployed 1 January 1983, the historical “flag day” when the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite replaced Network Control Program (NCP) for the Advanced Research Projects Agency Network (ARPANET), IPv4 has failed to keep up with the proliferation of Internet connected devices.
ARIN ran out of IPv4 addresses in 2015, as detailed in these stories from Ars Technica: It’s official: North America out of new IPv4 addresses and North America is out of IPv4 addresses—for really real this time.
Four of the five Regional Internet Registries (RIRs) are out of IPv4 addresses. New companies, Internet Service Providers (ISPs), many mobile devices per person, and, of course, the tens of billions of Internet of Things (IoT) devices wouldn’t exist today without IPv6. Specifically, the exponential growth of both mobile devices and IoT devices required immediate usage of IPv6.
Some examples of IoT usage include:
- Smart homes (containing lights, fans, air conditioners, smoke detectors, locks, washing machines, refrigerators, crock pots, pill bottles)
- Wearable health monitors (including smart clothes, wristwear, and glasses; medical wearables)
- Disaster management (using forest sensors that monitor temperature and carbon content)
- Farming (with sensors that monitor moisture content of soil to trigger an irrigation pump, select the best nutrient restoring crops, and sense the requirement of fertilizer)
- Process automation (through machines and conveyor belts that share information, status, and data)
- Smart cars (that exchange location, speed, and dynamics information)
- Biometric security systems (that dump data to machines for future use)
- Shopping malls (with barcode scanners sending information to a computer connected to a billing machine)
- Sports (apparel that can help correct biomechanics, boost fitness, optimize training and recovery, correct form, technique, and timing; footwear that can analyze running style, measure strain, impact and balance, make suggestions that support training goals, prevent injury; equipment that monitors, tracks, analyzes and improves performance and provides enhanced health and safety; facility management that identifies frequently used areas for ventilation, energy, cleaning, maintenance, waste removal, and supply monitoring; fan experiences which include directions to seats, updates on a facility’s services, location of concession stands, merchandise vendors and restrooms with short lines)
There are many privacy and security concerns related to IoT devices, most of which come with little to no security (or even the capability for security). My favorite story exemplifying this involves a casino that got hacked through its Internet-connected fish tank thermometer.
As the expression goes: “The S in IoT stands for security.”
The Vastness of IPv6 Address Space
Going from 32-bit IPv4 addresses to 128-bit IPv6 addresses means going from a potential number of around 4.3 billion IPv4 addresses to a potential of 340,282,366,920,938,463,463,374,607,431,768,211,456 IPv6 addresses. What’s that in words? Three hundred forty undecillion, two hundred eighty-two decillion, three hundred sixty-six nonillion, nine hundred twenty octillion, nine hundred thirty-eight septillion, four hundred sixty-three sextillion, four hundred sixty-three quintillion, three hundred seventy-four quadrillion, six hundred seven trillion, four hundred thirty-one billion, seven hundred sixty-eight million, two hundred eleven thousand, four hundred and fifty-six. For reference, there are tens of billions of IoT devices already, and that number is expected to exponentially skyrocket with each new year.
Do you like to go to the beach? IPv6’s address space size is more than 10 million trillion times the total number of grains of sand on all of the world’s beaches.
It doesn’t get smaller than atoms, so try this comparison on for size: an IPv6 address could be assigned to each and every single atom on the Earth’s surface with enough left over to do the same for more than 100 other “Earths.”
Let’s say a new unique IPv6 address was assigned at every picosecond (one trillionth of a second) for one trillion years. After that, many IPv6 addresses would still be available!
How We’ll Run Out of IPv6 Addresses
As if those analogies weren’t enough to make your head spin, this might make it spin in the other direction. In his presentation “The Art of Running Out of IPv6 Addresses” at RIPE 77 (the October 2018 meeting of the European, Central Asia, and Middle East Regional Internet Registry where ISPs, network operators, and other interested parties gathered to discuss issues of interest to the Internet community), Benedikt Stockebrand explained that we can actually run out of IPv6 addresses if allocation policies become short-sighted or wasteful. This will occur by wasting bits, not by wasting addresses.
Stockebrand detailed a rough estimate that we will outgrow IPv6 in 50 to 100 years! Watch the video of his presentation.
IPv6 Address Allocation
Typically, the following are the allocations at the various levels:
- A Regional Internet Registry (RIR) gets a /12 from the Internet Assigned Numbers Authority (IANA). IANA is run Public Technical Identifiers (PTI) which is an affiliate of the Internet Corporation for Assigned Names and Numbers. (ICANN).
- An Internet Service Provider (ISP) typically gets a /32 from an RIR. This provides 2^16 (65,536) customer site addresses (prefixes/network IDs).
- Each site gets a /48 (minimum), which allows for 2^16 (65,536) subnets for that organization.
- One possible site prefix for homes is /56, which only allows you to have 256 LANs at home.
- Each link/LAN gets a /64, which allows for 2^64 (18,446,744,073,709,551,616) — more than 18 quintillion — interface addresses. That’s for both at work and at home, even though you wouldn’t realistically put more than a few dozen device interfaces on each LAN anyway.
- Each device interface gets a /128 address.
More Than the Number of Addresses
IPv6 itself is more than just an insane amount of addresses. The designers of IPv6 saw an opportunity to make the protocol more efficient and simplified than IPv4, and that’s just what they did.
Each IPv6 network’s prefix (“network ID” in IPv4 lingo) has a /64 prefix length (“subnet mask” in IPv4 lingo). This standard and fixed prefix length allows devices to autoconfigure themselves after receiving a router’s Router Advertisement (which is, at a minimum, always used to configure clients with a default gateway IP address), instead of leasing an IPv6 address from a DHCPv6 (DHCP for IPv6) server (which is stateless and just gives out certain configurable parameters, like DNS server IP addresses). DHCPv6 can be stateful, too, and act like DHCP servers do in the world of IPv4, but that’s not the preferred method.
A system can have different types of IPv6 unicast addresses including:
Global Unicast Address (GUA)
(the equivalent of an IPv4 public address)
The prefix/prefix length for a GUA is 2000::/3 (the first three bits need to be 001), which means that the first hex digit needs to be either a 2 or a 3, although today only 2s (where the fourth bit, in the 1s column for the first hex digit, is a 0) are seen as the first digit instead of 3s (where the fourth bit, in the 1s column for the first hex digit, is a 1).
GUAs can be temporary or non-temporary. Temporary GUAs, which have short lifetimes (hours or days) are used for traffic originated by the device (the device initiates the connection). At times, a device will have multiple temporary addresses, as the old ones are phased out but kept alive for existing connections, while the new ones are used in subsequent connections. With temporary addresses, a device has a form of privacy. However, for connections to the device initiated from the outside (intended by design), a non-temporary address needs to be used. A device wouldn’t be able to be contacted if its address changed often.
Link-local Address
(the equivalent of the IPv4 zeroconf/APIPA — Automatic Private IP Addressing, what Microsoft calls zeroconf — address in the range of 169.254.0.0/16)
The prefix/prefix length for a link-local address is fe80::/10 (the first 10 bits need to be 1111 1110 01), which allows for some variation in the third and fourth hex digits, although you won’t find anything but fe80 at the start of any link-local address today.
In IPv4, seeing an address in the 169.254.0.0/16 range meant something was wrong, for example, Dynamic Host Configuration Protocol (DHCP) servers were down or traffic to them or from them was being filtered. In IPv4, getting one of these addresses is never a good thing, as there will never be any default gateway on that subnet to deal with your traffic. Unlike its IPv4 counterpart, this IPv6 link-local address is always used by devices for local communication. Link is the IPv6 term for network/LAN/subnet. A device gives itself a link-local address first, and then uses that link-local address to ask a router (through a Router Solicitation message) for a prefix (network ID in IPv4 lingo) and prefix length (subnet mask in IPv4 lingo). Using the prefix and prefix length, a device interface gives itself a GUA.
Link-local addresses are stable and constant, unlike GUAs that can change over time.
Unique Local Address (ULA)
(the equivalent of an IPv4 RFC 1918 private address)
The prefix/prefix length for a ULA is FC00::/7 (the first seven bits need to be 1111 110), which means that the first hex digit needs to be an F but the second hex digit can be either a C (if the eighth bit, in the 1s column for the second hex digit, is a 0) or a D (if the eighth bit, in the 1s column for the second hex digit, is a 1).
However, IPv6 does not use Network Address Translation (NAT) to translate these into GUAs.
IPv6 actually does have a form of NAT, however, it doesn’t serve the same purpose as the NAT in IPv4. For IPv4, NAT is a technology that enables many network clients on a TCP/IP network to share a single public IP address and, in essence, a connection to the Internet. The inside hosts use their own unique private IP addresses internally, but out on the Internet, all hosts from within that network use and share the same single public IP address. Industry-level routers and SOHO routers have built-in NAT functionality.
While there are many different flavors of NAT for IPv4, the one most often referred to simply as NAT is Port Address Translation (PAT), which maps an inside socket (local IP address, local source port, and protocol) to a translated/pseudo socket (shared public outside IP address, a source port that’s unique in the NAT mapping table, and protocol).
NAT was designed for one reason and one reason only, to slow down the depletion of IPv4 addresses. NAT was not designed for any form of security. Thinking NAT is security is an example of “security through obscurity,” relying on something being kept secret for security and thinking that hiding vulnerabilities is the same as securing them. If NAT was, in fact, essential network security, why are so many devices in homes and organizations around the world infected with malware and attacked? The statefulness of NAT is what causes most people to think NAT is a form of security. The same statefulness can be deployed through firewalls.
Even though NAT blocks unsolicited direct access from computers on the Internet to computers on a private network behind NAT, phishing attacks involving malicious links and files, as well as users simply visiting malicious sites, will allow ways in for the cybercriminals.
The following websites explain this in greater detail:
- https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/
- https://blog.ipspace.net/2011/12/is-nat-security-feature.html
- https://www.internetsociety.org/blog/2015/01/ipv6-security-myth-3-no-ipv6-nat-means-less-security/
A classic video from 2010, “Fanboy” series - IPv6 and NATs, has been used as further explanation that NAT should not be chosen over IPv6.
What if you want to host a website or an online game? Nobody would be able to directly access your computer with NAT enabled, since state is established with packets leaving your private inside network. When servers on the private inside network must be accessed from the outside world directly—for example, Web servers, File Transfer Protocol (FTP) servers, and more—port forwarding is the way it’s done. Playing online games through Xbox One, Nintendo Switch, and more has been troublesome, with connectivity issues due to NAT.
The main IPv6 versions of NAT, IPv6 to IPv4 and IPv4 to IPv6, are for protocol translation. This involves translating headers and addresses between IPv6 and IPv4 to allow IPv6-only and IPv4-only devices to communicate. This is, of course, not meant to be a long-term solution, but allows for a migration to IPv6 as well as the transparent translation of services by Web sites to IPv6-only clients.
IPv6-to-IPv6 Network Prefix Translation (NAT66) and Network Prefix Translation version 6 (NPTv6) were created to allow for address independence (a site not having to renumber internal addresses when an ISP changes prefixes or if the site changes ISPs and gets a new prefix), not translating between GUAs (public) and ULAs (private). See RFC 5902 IAB Thoughts on IPv6 Network Address Translation and RFC 6296 IPv6-to-IPv6 Network Prefix Translation.
A device interface can have multiple instances of each type of unicast address, unlike in IPv4, where a device has one singular IPv4 address. Duplicate Address Detection (DAD) is required (with some exceptions) for all unicast addresses regardless of the type or even if they were statically configured. This ensures devices that are giving their interfaces IPv6 addresses are not duplicating already deployed addresses and causing IP address conflicts. IPv6 addresses are associated with interfaces (hence the term interface ID as the second part of an IPv6 address, which follows the prefix) as opposed to IPv4 addresses being associated with hosts/devices (hence the term host ID as the second part of an IPv4 address, which follows the network ID).
In addition to an IPv6 neighbor cache, the equivalent of an IPv4 Address Resolution Protocol (ARP) cache that maps known IP addresses to discovered MAC addresses, there is an IPv6 destination cache for remote communications that maps remote IP addresses to the default gateway’s MAC address.
ICMPv6
IPv4 can block some or all of Internet Control Message Protocol (ICMP), but for IPv6, ICMPv6 (ICMP for IPv6, not the sixth version of ICMP) is a way of life.
Neighbor Discovery Protocol (NDP), which is run through ICMPv6, consists of five messages:
- Router Solicitation (RS, the IPv6 equivalent of a DHCP Discover)
- Router Advertisement (RA, the IPv6 equivalent of a DHCP Offer)
- Neighbor Solicitation (NS, the IPv6 equivalent of an ARP request)
- Neighbor Advertisement (NA, the IPv6 equivalent of an ARP reply)
- Redirect (how routers that are default gateways for PCs let the PCs know if there is a more optimal router on the network to send traffic to for a specific destination)
There is no broadcasting in IPv6 (unicast, multicast, and anycast remain), which means ARP can’t exist. Broadcasts are flooded by switches to each device on an IPv4 network, and the broadcasts are processed and read by each device. In the case of ARP requests, there are many bytes that each device needs to read, before all devices but one on the network realize it’s not meant for them. Solicited node multicasts, through NS and NA messages are filtered by NICs at Layer 2 (in the OSI model), and thus are more efficient than their IPv4 equivalents. Each IPv6 unicast address (no matter which type it is) has a solicited node multicast address that is easily derived, and is used as the destination IPv6 address for neighbor solicitation messages.
Router advertisements can follow one of three patterns:
- They can tell hosts to use Stateless Address Autoconfiguration (SLAAC) and not to use DHCPv6 at all. This is possible if the router sends out Domain Name System (DNS) information and the client can process this information, as specified in RFC 6106 IPv6 Router Advertisement Options for DNS Configuration.
- They can tell hosts to use SLAAC and use stateless DHCPv6 to get DNS server IP addresses.
- They can tell hosts to use stateful DHCPv6 for everything, except a default gateway IP address, which will always come from the RA itself. In certain cases, this could result in hosts having both a stateful DHCP address as well as a SLAAC address.
More Changes in IPv6
IPv6 routing, using Border Gateway Protocol (BGP), is global and hierarchical from the start. Consider the following example. Routers in South America can have a single route that covers all IPv6 addresses used in North America. Routers in North America can have a single route that covers all IPv6 addresses under the control of a single ISP in North America. That ISP can have a single route that covers all addresses for each of its customer sites. This keeps the size of routing tables on the Internet backbone routers down and ensures that minimal changes would be needed to the routing tables in the future. For example, if an ISP in North America got another customer site, that ISP’s routers would need to add a route to the new customer site, but that’s it. The routers of the other ISPs in North America as well as the routers from other continents would not need to make any changes to their routing tables.
IPv4 routing has not followed this neat pattern, and, as of 31 January 31 2021, there were 861,418 BGP routes in the Internet backbone routers. That large number not only adds to the latency for routing, but also is approaching the maximum number of routes (1,048,576) that can be stored in certain routers.
In IPv6, all 0s and all 1s can be used for the interface ID portion of an IPv6 address (not that you’d want to or you’d even need to). In IPv4, a device ID can’t be all 0s (which would conflict with the network ID) or all 1s (which would conflict with the subnet’s broadcast address).
In IPv6, subnetting is just counting in hex, unlike the very involved IPv4 subnetting process. Using the 3-1-4 rule, the first three hextets are assigned to your organization by an ISP or RIR, the fourth hextet is the subnetting octet, and the last four hextets are for the interface ID. Let’s say your organization gets the prefix 2001:db8:b0b::/48. Subnetting is just counting in hex in the fourth hextet.
The first 11 subnets would be:
- 2001:db8:b0b:0::/64
- 2001:db8:b0b:1::/64
- 2001:db8:b0b:2::/64
- 2001:db8:b0b:3::/64
- 2001:db8:b0b:4::/64
- 2001:db8:b0b:5::/64
- 2001:db8:b0b:6::/64
- 2001:db8:b0b:7::/64
- 2001:db8:b0b:8::/64
- 2001:db8:b0b:9::/64
- 2001:db8:b0b:a::/64
Simple!
The IPv6 Header
Some fields in the IPv6 header have the same name as fields in the IPv4 header:
- The Version field has the same name, but, of course, the value of 6 is there instead of 4.
- The Source Address and Destination Address fields retain their name, but, of course, in the IPv6 header, they are filled with 128 bits, unlike the 32 bits in the IPv4 header.
Some fields in the IPv6 header have been renamed:
- The IPv4 Differentiated Services field has been renamed Traffic Class in the IPv6 header. The functionality remains the same—to classify and manage network traffic by providing quality of service (QoS).
- The IPv4 field Time to Live (TTL) has been renamed to a more logical Hop Limit in the IPv6 header. The value in this field is decremented by routers each time a packet is sent out of an interface to prevent routing loops. It’s also used by tracert/traceroute for troubleshooting connection issues (tracert/traceroute is not used to view someone’s IP address and connection speed as this notorious video claims).
- The Protocol field has been renamed Next Header. IPv6 uses a fixed-length 40-byte (32 bytes of which are the source and destination addresses) header, which is more efficient than IPv4’s variable-length header, although IPv4 options that would raise the minimum 20-byte header (potentially up to the limit of 60 bytes) aren’t used today because of security concerns. IPv6 extension headers, used instead of options, include Hop-by-Hop Options, Routing, Fragment, Encapsulating Security Payload (ESP), Authentication Header (AH), Destination Options, Mobility, Host Identity Protocol, and Shim6 Protocol.
Some fields from the IPv4 header do not appear in the IPv6 header in any form:
- The Header Length field is not needed in the IPv6 header because the IPv6 header is a fixed-length header, as mentioned previously.
- The Identification, Flags, and Fragment Offset fields do not appear in the IPv6 header. These fields deal with fragmentation, and unlike IPv4 routers, IPv6 routers don’t fragment packets. If a packet exceeds a link’s maximum transmission unit (MTU), a router will send an ICMPv6 Packet Too Big error message. Then, the source will use a Fragment extension header. Since IPv6 routers don’t fragment packets, latency is reduced between communicating devices over a link that has an MTU that requires fragmentation.
- There is no Header Checksum field in the IPv6 header, There’s error checking in the frames at Layer 2 and in TCP segments or UDP datagrams at Layer 4. Therefore, there’s really no need to check for errors at Layer 3. However, the UDP checksum, which was optional in IPv4, is now mandatory in IPv6.
- There are no Options in the IPv6 header. As mentioned, extension headers take the place of Options.
- There is no Padding in the IPv6 header. Padding is needed in IPv4 when Options leave the size of a packet on a non-32-bit-boundary. Since there are no Options in IPv6 and also because the size of an IPv6 header is always a fixed-length 40 bytes, there is no need for a Padding field in the IPv6 header.
One field in the IPv6 header has been changed from its counterpart in the IPv4 header:
- The Total Length field in the IPv4 header, which calculated the number of bytes, including Layer 3 and above, has been renamed and changed to the Payload Length field, which just calculates the number of bytes after the main IPv6 header (including extension headers, Layer 4 headers, and upper-layer data). Again, the IPv6 header is fixed-length, and its size will always be 40 bytes.
One brand-new field with no connection to the IPv4 header has been added to the IPv6 header:
- The Flow Label field tags and identifies packets in a single flow or stream.
Adding to the efficiency, each IPv6 field starts on a 64-bit boundary, a multiple of 64. This allows 64-bit CPUs to read 64 bits at a time, while remaining backward compatible to 32-bit CPUs since 64-bit boundaries are also 32-bit boundaries. This was considered in the 90s, before 64-bit CPUs were even common.
At Layer 2, frames encapsulating IPv4 packets have a hex value in the Type field of 0800, while frames encapsulating IPv6 packets have a hex value in the Type field of 86dd.
Curious about IP versions besides IPv4 and IPv6? Read this companion blog post by Jonathan S. Weissman: IPv4, IPv6 … What Happened to All the Other Numbers?
No Major Gain Until More Adopt IPv6
Many benefits from IPv6 won’t be fully realized until IPv6 gains more traction. It’s like companies are playing chicken, waiting for others to go to dual-stacked first, and then IPv6 only. Companies that have enough IPv4 addresses with no desire to develop and advance from a technical standpoint are holding others back.
Gateways exist to allow IPv4-only hosts to access IPv6-only servers and vice versa. One example is Cloudflare’s Automatic IPv6 Gateway.
Since ARIN ran out of IPv4 addresses in 2015, more and more networks and sites continue to be created as IPv6-only infrastructures. The sooner other companies make the migration, the quicker everyone will realize more benefits.
With the COVID-19 pandemic, budgets are even tighter. Investing, deploying, and training for IPv6, from both a hardware and software perspective, are possibly moving in the wrong direction. When you think of applications that need to be upgraded for IPv6, it’s even worse. In addition to major, large corporations, ISPs and telecommunication companies need to adopt IPv6, and so do small to medium enterprises. Without them, IPv6 deployment will continue to be slow. However, costs for compatibility, security, training, education, and more could be less than costs for missed opportunities. Furthermore, ARIN has stated there are “extra costs associated with staying IPv4-only, which will likely increase over time.”
IPv6 vs. IPv4 in Speed
According to articles like this, Apple tells app devs to use IPv6 as it’s 1.4 times faster than IPv4, and this, Why is IPv6 faster?, some benefits of IPv6 can be realized immediately.
Why is IPv6 faster? explains that IPv6 won’t have performance improvements over IPv4 because network hardware and software have been optimized over many years for IPv4, and that could hinder IPv6 performance. Another belief is that that IPv6 is mostly faster, but current dual-stack deployments can give the false impression that IPv6 is faster, when it really isn’t.
Other articles like this one, IPv4 vs. IPv6 FAQ, indicate that you won’t be able to notice any performance improvements with IPv6 because of latency caused by NAT, latency from MTU and packet sizes, and differences in IPv4 and IPV6 global route optimizations. Another article, IPv4 vs. IPv6: What’s the Difference?, notes that since IPv4 networks have been around for a while and have had many optimizations, few differences in speed will be realized at this point.
This article, IPv4 vs IPv6: The differences between two that you should know today, reports that in some cases IPv4 was actually quicker than IPv6, possibly due to the larger-sized packets of IPv6.
IPv6 vs. IPv4 in Security
Just as some reports will say IPv6 is faster and others will say IPv4 is faster, some reports will say IPv6 is more secure, while others will say IPv6 is less secure.
Those that erroneously say that IPv6 is more secure are using information in RFC 4301 Security Architecture for the Internet Protocol from 2005. RFC 6434 from 2011 changed RFC 4301’s requirement of IPv6-enabled devices and applications to use IPsec to optional and recommended with the word “should.” RFC 6434 was obsoleted in 2019 by RFC 8504.
Since there is no guarantee of the use of IPsec for IPv6, IPv6 is not more secure than IPv4. Also, remember, the earlier discussion on NAT means that IPv4, with the use of private IP addresses and NAT, is not more secure than IPv6 either!
Never a Better Time to Learn
I said it in 2016, and I’ll say it again now in 2022: There is little to no pressure right now to start learning IPv6. As the days, weeks, and months go by, that will become less and less true. The Internet of Things and mobile devices are, of course, the big factors driving the need for IPv6 right now. Before other factors come into play and add pressure, now is the time to start learning IPv6. There will never be a better time!
Post written by:
Any views, positions, statements, or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness, or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions, or errors contained in a guest blog post.
Recent blogs categorized under: IPv6
GET THE LATEST!
Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.
SIGN ME UP →Blog Categories
IPv6 • Business Case for IPv6 • Internet Governance • Public Policy • Elections • ARIN Bits • Fellowship Program • Grant Program • RPKI • Caribbean • Outreach • Training • Updates • IPv4 • Security • Data Accuracy • Tips • Customer Feedback • IRR
