If you’ve ever been configuring a router or other network device and noticed that you can set up IPv4 and IPv6, you might have wondered what happened to IPv5. Well, thanks to [Navek], you don’t have to wonder anymore. Just watch the video below.
We will warn you of two things. First, the video takes a long time to get around to what IPv5 was. In addition, if you keep reading, there will be spoilers.
The first part of the video covers the general differences between IPv4 and IPv6, especially surrounding addressing. Then, it talks about how IP alone can’t do things you like to do for handling things like voice. For example, the IP layer doesn’t understand how much bandwidth exists between two points. It is only concerned with moving data from one point to another point.
To foster voice communications, there was a proposal for something called the stream protocol. It didn’t catch on. In fact, it was reincarnated as a proposal to move video, too, but it still didn’t catch on. However, the network header used the next number in sequence, which was… five!
So, really, the video title is a bit of a red herring. You didn’t forget IPv5; there simply was never an IPv5. There is, however, network protocol #5, which has little to do with IP and never caught on.
Still, an interesting walk down memory lane to a time when moving voice and video over the network was exotic high-tech. We love diving into the old network stuff like finger and UUCP.
You really should include IPv9 (From 1994-04-01)
https://datatracker.ietf.org/doc/html/rfc1606
The IPv9 protocol just has such a vast number space!
lol. Now they issue 2^64 addresses in a single IOv6 /64.
Of course written on 1st Apr 1994
Maybe in a few weeks!
see? you don’t need a video for this. rambling on with filler content because of advertisements.
Some people process information by seeing better, then with words. Wonder how i could explain this with words better if this isnt ceap enough yet. Or maybe a video, showing graphs, visual examples and maybe a short example story.
I raise Fabien Sanglard’s blog, featured multiple times here. In my not so humble opinion it’s a pinnacle of technical writing. Full of graphs and visual examples but no ads, no words from the sponsor etc.
Here to second Fabien Sanglard’s blog. Great breakdowns on old game engines and other technical topics.
https://fabiensanglard.net/
Great give it to us in both because some of us don’t like watching someone take an entire and of Conan to get to the point.
Brevity and clarity returns above any other metric
” you don’t need a video for this.”
I agree. Video is overused for a lot of things that can easily be explained in an article or a book or … without silly adverts :) .
Huh, I thought it was a case of the number relating to something in the IP address scheme, so it went from 4 things to 6 things. Guess not.
It was a streaming protocol
https://en.m.wikipedia.org/wiki/Internet_Stream_Protocol
From what I have read, IPV6 was not needed if with we just took away the massive IP blocks allocated to big tech as well as better rooting rules. When I studied IPV6 for my degree I got the distinct impression that IPV6 was, in part, invented to make it hard for new a company to enter the search engine market. IPV6 makes it a lot hard to crawl the web (some may argue that is a good thing).
Plent of things would get better if we got rid of big tech and especially it’s leaders, CEOs and top engineers. One day I really must get myself a 3D printer.
i personally don’t like a lot of the ipv6 choices, but a bigger address space was definitely needed. i have three IP addresses at all times — my phone wireless internet, my fiber internet, and my VPS. and then add in the fourth address i share with my boss at the office. given the billions of people on the planet, we definitely cannot afford to give everyone 3.5 addresses out of a 32-bit address space. routing can make up for some of it but there’s always downsides to being behind NAT. if NAT was perfect, we wouldn’t need public IP addresses at all.
And yet we still have people who reject ipv6 because NAT is like a firewall to them.
i try to talk about myself, instead of talking about other people. it helps me avoid being wrong.
i am among the group that uses nat as one part of my security posture, and i’m dragging my feet about ipv6. there are pluses and minuses to my current configuration. i keep it because i don’t really have any choice. i still use a lot of ipv4-only services. i understand that someday i will have to learn some more about ipv6, and that memorizable and orally-transferrable addresses may be a thing of the past. but in the moment, if i undergo that cost, the pot of gold at the end of that rainbow is an awful hybrid network that combines the worst of both.
i’m definitely not excited about the possibility of exposing every one of my devices to the public internet. keeping them cloistered is not a perfect security measure but it definitely minimizes a certain kind of hassle. so i will be using some sort of vpn and nat setup indefinitely even if i do embrace ipv6 on my local network.
but what decides it at the end of the day…man, i recently convinced one of the nodes on my vpn to switch from vtund to openvpn, and now they’re using an ancient obsolete version of openvpn. abandoning legacy is inevitable on a long enough time frame but a real pain in the butt in every actual instance.
oh boy you’re gonna trip balls when you hear about this thing called “stateful firewall”
no i’m not surprised at all that ipv6 routing is configurable. in fact, that’s my point. the day i let ipv6 onto my local network is the day i’m running two sets of configurations. that’s exactly what i’m objecting to. not that ipv6 can’t do it, but that i’ll have to learn how to do it on ipv6 and then i’ll still have to do it for ipv4 as well at the same time.
NAT is not a firewall, it’s a useful tool and a nice addendum for you local ops for management and improve security, but that’s it. And contrary to what vendors might tell you, iPv6 doesn’t do away with NAT either. Learn to separate marketing and corporate agenda from the things you read.
In fact there are two things NAT is used for on IPv6, the system you are used to with private address space, and 6to4 translation for allowing your network to interoperate with an ipv4 network.
Our company hides behind NAT addressing. Works well. At home, I have two networks. One for home devices (who in their right mind wants your automation projects available on the net???) and one for access to internet. Simple and separate.
No need for IP6 here, but I can see where it would become needed at some point as 128 bits vs 32 bits of address space is quite a difference!
We have already passed the point of it being necessary, and it’s already used for many things. One of the major reasons for poor adaptation has more to do with certain vendors charging a premium for proper support because of shareholders. ISPs also don’t like buying new hardware if they have to pay for it, so routing ipv6 in the US is a patchwork outside of major implementations like a cell network.
Except that NAT says forget about denying or allowing things, just don’t make them possible by default. If something is by definition impossible, even if the permissions are messed up it still doesn’t happen.
In IPv6 land, my toilet should have an outward facing door with a mail slot with its own unique address that by default appears on any mail I send when I’m in there. If I don’t want to identify myself I have to not only accept the unchangeable portion of the address, but constantly randomize the other portion and remember which I’ve used for the duration of any conversations I am using them in. I’m told that I’m supposed to be fine with this as long as I have a good lock, but I’d much rather not have the opening in the first place.
In IPv4 land I get natted, and everything is in care of Nat. Nat takes what I send and brings back the responses, Nat has been instructed that if someone asks about a cup of sugar she can find it in the pantry to give them, but if they ask about a pitcher of lemonade she doesn’t know anything about that. If another resident of the house also wants to lend sugar, they’ll need to tell Nat and their borrower that it’s their sugar they’re lending, not mine, so it’s in a different place. And if one resident does something unsavory, maybe someone will blame Nat and we’ll all suffer. But, even if Nat’s brother comes over and she trusts him but I don’t, then she still can’t lend him my car keys because I only told her how to find my sugar. And that’s a minor blessing.
No, it doesn’t. That’s an implementation you are talking about, not the actual protocol.
Yes, you can translate addresses in other ways. But that’s the one that actually matters.
None of this is correct. Sure, the big tech firms are a problem, but IPV4 is also a problem. I don’t agree with what major vendors want to do with v6, like getting rid of NAT, but we are rapidly transitioning into IPv6 right now whether you realize it or not (many cell providers use it). It just isn’t visible to consumers because it has a reputation for being complicated.
Ipv6 is a perfect example of what you get when you have a committee design something. It’s a mess. No broadcasts, address space to big, and active refusal for an IPv4 gateway.
I’ve been pushing for years for what I call IPv5. Yes I know there was an Ipv5 but no one even remembers it. My approach is about recognizing the strengths of ipv4. BGP already has a 32bit address space and is required to route over the internet. So if there was an ipv5 protocol which used 64 bit addressing, internet addresses could be built by simply concatenating the routers BGP ASN with its existing ipv4 addresses. Routers already have everything they need. You could turn on my IPv5 with a global check-box.
Edge devices firewalls, would be able to track stateful sessions and simply pretend your BGP ASN to you public Ipv4 address space to communicate via ipv5. Internet routers would all have to run IPv5, but enterprises, who don’t need the extra address space wouldn’t need it. They could keep using ipv4.
Once all routers on the internet are upgraded to support IPv5, a new epoch would be declared, afterwhich all the ipv4 address space would become private and all routing would be done using the first 32 bits or the bgp asn.
It would solve all our current addressing problems using addressing and protocols we are all very familiar with.
Do you have an RFC or a white paper for your proposal?
rfc42069 because it’s a pipe dream fantasy
(i want it too though)
Here you go. A RFC just for you:
Network Working Group A. V. C. O. Korhonen
Internet-Draft
Intended status: Informational D. Small
Expires: 11 September 2025 10 March 2025
IPv5: A 64-Bit Addressing Protocol – Leveraging IPv4 Strengths and BGP
ASNs
Abstract
This document proposes IPv5, an addressing protocol that introduces a
64-bit address space derived by concatenating a 32-bit BGP Autonomous
System Number (ASN) with an existing 32-bit IPv4 address. By
leveraging the strengths of IPv4 and the current BGP routing
architecture, IPv5 offers a smooth transition path—allowing for dual-
stack operation during deployment—and ultimately simplifying global
routing. Once widespread deployment is achieved, the IPv4 address
space may be reclassified as private, with routing performed on the
first 32 bits representing the BGP ASN.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as “work in progress.”
This Internet-Draft will expire on 11 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Korhonen & Small Expires 11 September 2025 [Page 1]
Internet-Draft IPv5: A 64-Bit Addressing Protocol – Lev March 2025
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Critique of Existing Protocols . . . . . . . . . . . . . 2
2.2. Leveraging IPv4s Strengths . . . . . . . . . . . . . . . 3
IPv5 Addressing Architecture . . . . . . . . . . . . . . . . 3
3.1. Address Format . . . . . . . . . . . . . . . . . . . . . 3
3.2. Routing Considerations . . . . . . . . . . . . . . . . . 3
Transition and Deployment . . . . . . . . . . . . . . . . . . 3
4.1. Enabling IPv5 . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Edge Device and Firewall Integration . . . . . . . . . . 3
4.3. Transition Epoch . . . . . . . . . . . . . . . . . . . . 4
Operational Considerations . . . . . . . . . . . . . . . . . 4
5.1. Backward Compatibility . . . . . . . . . . . . . . . . . 4
5.2. Network Management Benefits . . . . . . . . . . . . . . . 4
Security Considerations . . . . . . . . . . . . . . . . . . . 4
IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
Introduction
The evolution from IPv4 to IPv6 was intended to resolve addressing
limitations; however, IPv6 has introduced complexities that many in
the networking community view as overengineered. Notable criticisms
include the elimination of broadcast functionality, an address space
far exceeding current operational needs, and a lack of seamless
integration with established IPv4 gateway practices.
Motivation
2.1. Critique of Existing Protocols
IPv6, as designed by extensive committee processes, has resulted in a
protocol that some argue is unnecessarily complex. In particular, it
has eliminated broadcast capabilities, provides an address space that
exceeds practical requirements, and does not natively support
integration with IPv4 gateways.
Korhonen & Small Expires 11 September 2025 [Page 2]
Internet-Draft IPv5: A 64-Bit Addressing Protocol – Lev March 2025
2.2. Leveraging IPv4s Strengths
The proposed IPv5 approach capitalizes on the robustness of IPv4 and
the operational familiarity that network operators have developed
over decades. Given that BGP—the cornerstone of global
routing—already employs a 32-bit addressing system, it is both
logical and efficient to extend this model. By concatenating the BGP
ASN with an IPv4 address, a unique, globally routable 64-bit address
is produced that retains operational practices familiar to
administrators and allows for a dual-stack period where IPv4 and IPv5
can coexist.
IPv5 Addressing Architecture
3.1. Address Format
An IPv5 address is defined as a 64-bit quantity composed of two
32-bit fields: a BGP Autonomous System Number (ASN) and an IPv4
address. The upper 32 bits serve as a routing prefix derived from
the BGP ASN, while the lower 32 bits maintain the familiar IPv4
addressing structure.
3.2. Routing Considerations
Routers supporting IPv5 will recognize and process 64-bit addresses
within the existing BGP framework. They will leverage current
routing mechanisms for address validation and propagation, and
operate in a dual-stack environment to ensure backward compatibility
during the transition phase.
Transition and Deployment
4.1. Enabling IPv5
IPv5 functionality is designed to be activated via a global
configuration toggle on routers. This check-box approach allows
operators to enable IPv5 without a complete overhaul of existing
infrastructure, ensuring a seamless transition.
4.2. Edge Device and Firewall Integration
Edge devices and firewalls, which are equipped to maintain stateful
session tracking, can transparently translate between IPv4 and IPv5.
A device’s public IPv4 address is presented as an IPv5 address by
combining it with the local BGP ASN, facilitating communication over
the new protocol while preserving existing security practices.
Korhonen & Small Expires 11 September 2025 [Page 3]
Internet-Draft IPv5: A 64-Bit Addressing Protocol – Lev March 2025
4.3. Transition Epoch
As adoption of IPv5 increases among core Internet routers, a formal
transition epoch may be declared. At that point, routing will
predominantly utilize the 32-bit BGP ASN portion of the IPv5 address,
and the legacy IPv4 address space can be reclassified as private.
Operational Considerations
5.1. Backward Compatibility
During the transition period, dual-stack operation will allow IPv4
and IPv5 to coexist. Enterprises and network operators not requiring
additional address space can continue to use IPv4 until their
infrastructure is fully updated for IPv5 deployment.
5.2. Network Management Benefits
Consolidating routing decisions around the BGP ASN may simplify
routing table management and enhance predictability of traffic flows.
This consolidation is expected to reduce operational complexity and
improve overall network stability.
Security Considerations
Transitioning to IPv5 introduces several security considerations.
Translation mechanisms between IPv4 and IPv5 must be rigorously
tested to avoid vulnerabilities. Edge devices and firewalls require
updates to maintain effective stateful session tracking, and
operators must ensure that dual-stack operation does not expose new
attack vectors.
IANA Considerations
This document requests no actions from the Internet Assigned Numbers
Authority (IANA). The IPv5 addressing scheme is derived directly
from existing IPv4 and BGP ASN allocations.
Conclusion
The IPv5 proposal offers a pragmatic evolution of Internet addressing
by leveraging the strengths of IPv4 and the current BGP routing
infrastructure. The introduction of a 64-bit address, formed by
concatenating a 32-bit BGP ASN with a 32-bit IPv4 address, provides a
scalable, operationally familiar, and cost-effective path forward,
enabling a gradual transition to a new global routing paradigm.
References
Korhonen & Small Expires 11 September 2025 [Page 4]
Internet-Draft IPv5: A 64-Bit Addressing Protocol – Lev March 2025
9.1. Normative References
[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
https://www.rfc-editor.org/info/rfc791.
[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6
(IPv6) Specification”, RFC 2460, DOI 10.17487/RFC2460,
December 1998, https://www.rfc-editor.org/info/rfc2460.
Acknowledgments
The ideas presented in this document have been shaped by ongoing
debates within the networking community, with special thanks to
colleagues who have critiqued and refined early proposals for
addressing evolution.
Authors’ Addresses
Aki von CGPT Oemihigh Korhonen
Email: spammagnet@eibrak.com
Derek Small
Email: spammagnet@eibrak.com
Korhonen & Small Expires 11 September 2025 [Page 5]
Go read the specification again, you missed quite a bit.
IPv6 isn’t perfect, and in fact it’s quite old at this point (initially published almost 30 years ago), but it’s not nearly as much of a mess as you think. It doesn’t remove NAT, that’s just vendor marketing. You actually use NAT for 6to4 translation. It doesn’t remove private address space, etc.
The real downside to IPv6? Corporate product games where they try to avoid giving you proper support without pumping their shareholders. It didn’t get ratified until 2017 fort exactly this reason, vendors and ISPs don’t want to have to work for your money.
Also your proposal takes me two things. You don’t actually know the major differences between v4 & v6, and seem to lack an understanding about how IP works in general.
I was the product manager for ST2/IP5 at Wellfleet. We implemented it and it was used in a big network at US DOD. The follow on was RSVP Integrated services which did not take off. I was also the product manager for this and after talking to lots of customers about it argued vehemently that the development should be cancelled, ultimately resulting in my leaving the company as they continued this significant development that was never used. RSVP did reappear later in MPLS TE, but wellfleet/bay networks/Nortel didn’t benefit……
86% of internet traffic is videos that don’t need to exist, where people talk entirely too long, don’t know how to get to the point, and somehow have three ad breaks in the middle of it.
If I click on a link to a news article I want to read it damn news article, not watch a video. Next time actually write a thing article don’t just say here watch a damn video!