| Internet-Draft | IPv5 -- The missing transition step | April 2025 |
| Donnerhacke | Expires 3 October 2025 | [Page] |
Despite IPv6 was developed to replace IPv4, the transition process did not and will not ramp up as expected. Major reason for stalled deployment is non-technical, but historical knowledge as well as established processes. The missing part between IPv4 and IPv6 is designed to help the migration efforts by addressing the non-technical needs for a smooth transition.¶
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 3 October 2025.¶
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.¶
IPv4 [RFC791] comes with the visual appearance of dotted-quad-numbers, while IPv6 [RFC8220] looks like a memory dump during a kernel panic. Senior administrators as well as teachers, documentation writers, or film makers are familiar with the IPv4 style of addresses, so they can and will not change their habits, slides or books. IPv6 will not get traction until this generation of people left the companies and schools.¶
In order to introduce a new protocol, the visual and operation experience must not change. Coming from IPv4, there should be no difference in using IPv5. Evolving to IPv6, there should be only a minimal difference to IPv5. IPv5 is designed in a way to keep the older generation of people on board while introducing a protocol, which might be used like the newer IPv6.¶
Furthermore, the organizational impact should be minimized. People already using IPv4 or IPv6 should be able to switch to IPv5 without additional bureaucratic obstacles.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The IPv5 header is using the same fields as the IPv6 header. The major differences are:¶
For information about the other fields, please refer to IPv6 [RFC8220].¶
For address resolution an adapted version of neighbor discovery [RFC4861] is used.¶
The last 24bit of IPv5 addresses are mapped to the IANA-EUI [RFC9542] space 33:33:ff: for generating multicast addresses.¶
IPv5 addresses consist of four hextets a 16bit each. For the visual representation, those grouping are used. The hextets might be written in decimal, separated by dot '.' characters, or as hexadecimal numbers, separated by colon ':'. Intermixing both methods is not allowed. Multiple hextets of 0 might be concatenated to "::", so "::1" is the same as "0:0:0:1". For decimal-dotted notation, all four decimals must be retrained, shortening is not allowed.¶
Decimal-dotted notation is used for all addresses which has lower than 4096 in the first hextet, otherwise hexdecimal-colon notation is used. So 987.543.210.1 is correct, but 987:543:210:1 is not. OTOH 1234:5678:9:0 is correct, but 12345.6789.0.1 is not.¶
Each octet of an IPv4 address is mapped into the corresponding hextet of the IPv5 address. In order to fill the double space, each component of the address is separately doubled in size.¶
The address IPv4 "198.51.100.24" will become a IPv5 address consisting
of those eight bytes: 0 198 0 51 0 100 0 24.
This IPv5 address is written "198.51.100.24" in decimal-dotted form.¶
IPv6 addresses are twice as large as IPv5 addresses. The first two hextets of the IPv5 address maps directly into the first hextets of the IPv6 address. The third hextet of the IPv5 address maps into the fourth hextet in IPv6, and the last hextet maps into the last hextet respectively.¶
So the IPv5 address "2001:db8:1234:5678" map to the IPv6 address "2001:db8:0:1234::5678".¶
In order to keep the operational differences minimal, IPv4 as well as IPv6 addresses with their typical netmasks should be representable by IPv5 without change.¶
For routing purposes the prefix length is used, which is different from the netmask. Routing and networking people should ignore the netmask, and stick only to the prefix length for all practical purposes. If necessary, the prefix length should be written with a double slash "//", instead of a single slash "/" used by the netmask.¶
| IPv4 | netmask | prefix length | IPv4 | netmask | prefix length |
|---|---|---|---|---|---|
| /0 | /0 | //0 | /16 | /16 | //32 |
| /1 | /1 | //9 | /17 | /17 | //41 |
| /2 | /2 | //10 | /18 | /18 | //42 |
| /3 | /3 | //11 | /19 | /19 | //43 |
| /4 | /4 | //12 | /20 | /20 | //44 |
| /5 | /5 | //13 | /21 | /21 | //45 |
| /6 | /6 | //14 | /22 | /22 | //46 |
| /7 | /7 | //15 | /23 | /23 | //47 |
| IPv4 | netmask | prefix length | IPv4 | netmask | prefix length |
|---|---|---|---|---|---|
| /8 | /8 | //16 | /24 | /24 | //48 |
| /9 | /9 | //25 | /25 | /25 | //57 |
| /10 | /10 | //26 | /26 | /26 | //58 |
| /11 | /11 | //27 | /27 | /27 | //59 |
| /12 | /12 | //28 | /28 | /28 | //60 |
| /13 | /13 | //29 | /29 | /29 | //61 |
| /14 | /14 | //30 | /30 | /30 | //62 |
| /15 | /15 | //31 | /31 | /31 | //63 |
| /32 | /32 | //64 |
This mapping ensures, that the existing netmask in IPv4 can be reused in IPv5 without change. Furthermore the typical network classes can be retrained: A class C is still a /24, and suitable for typical LAN setups.¶
The first 32 bit prefix lengths are mapped 1:1 to IPv6 prefix lengths, and are identical to the netmasks.¶
Prefix length between //32 and //48 are mapped uniformly to the range 32 up to 64, so each step is doubled.¶
Prefix length between //48 and //64 are mapped uniformly to the range 64 up to 128, so each step is quadrupled.¶
If "n" denotes the netmask and "p" the prefix length, then the following formula holds:¶
| p , if 0 <= p <= 32
n = | 32 + 2*(p-32) , if 32 < p <= 48
| 64 + 4*(p-48) , if 48 < p <= 64
¶
This mapping ensures, that the existing netmask in IPv6 can be reused in IPv5 without change. Furthermore the typical network classes can be retrained: A class C is still a /64, and suitable for typical LAN setups.¶
Any existing network, which is using registered IPv4 or IPv6 space, can automatically use the corresponding IPv5 space. So if a network uses 2001:db8::/32 in IPv6, it can use 2001:db8::/32 in IPv5, too. If a network uses 192.0.2.0/24 in IPv4, it can use 192.0.2.0/24 in IPv5, too.¶
This simplified resource allocation process is possible for any IPv6 resource up to prefix length of /32, and for any IPv4 resource up to prefix length of /24.¶
By applying the previous allocation scheme, not all addresses are exhausted.¶
The obvious extension is to go "full decimal", as proposed by various film makers: Simply allow up to 999 in each hextet. So you can - without asking for extra permission - extend your networks in your prefix 128.66.0.0/16 by assigning class C networks up to 128.66.999.0/24. RIRs might apply for additional allocations from IANA up to 999.0.0.0/8.¶
Using more than three digits may be used, as long as the first hextet is excluded. More than 65535 per hextet must not be used.¶
Please check your applications, if they are able to handle more than three digits per hextet.¶
Host addresses might be assigned - as usual - manually or by DHCP. The DHCP [RFC8415] protocol needs to be adapted for this purpose. Automatic assignment technologies like SLAAC [RFC4862] are not applicable.¶
For hosts in the class C network /24, you can assign any host value up to 999, and - with caution - up to 65534, in the last hextet.¶
For hosts in the class C network /64, host assignments can use the full space from 1 up to fffe in the last hextet.¶
The space 1000.0.0.0 - 1000:: is reserved for future extensions.¶
The space 4000:: - ffff:: is reserved for future extensions.¶
There are no related security considerations, besides those, which are already known from IPv4 and IPv6.¶
IANA should open an new registry for the IPv5 address space.¶
version 02¶
fixed incorrect backmatter mark¶
version 01¶
version 00¶
initial draft¶