IPv5 -- The missing transition step

Introduction IPv4 comes with the visual appearance of dotted-quad-numbers, while IPv6 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.

IPv5 Header Format

The IPv5 header is using the same fields as the IPv6 header. The major differences are: the version number is 5 the address fields are 64bit each For information about the other fields, please refer to IPv6.

Address resolution For address resolution an adapted version of neighbor discovery is used. The last 24bit of IPv5 addresses are mapped to the IANA-EUI space 33:33:ff: for generating multicast addresses.

IPv5 Address Mapping 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.

Mapping IPv4 into IPv5 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.

Mapping IPv5 into IPv6 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".

IPv5 Netmasks 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.

Mapping IPv4 into IPv5 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.

Mapping IPv5 into IPv6 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:

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.

Allocating resources

Automatic reuse of existing resources 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.

Extended resources 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 address assignment Host addresses might be assigned - as usual - manually or by DHCP. The DHCP protocol needs to be adapted for this purpose. Automatic assignment technologies like SLAAC 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.

Reserved space The space 1000.0.0.0 - 1000:: is reserved for future extensions. The space 4000:: - ffff:: is reserved for future extensions.

Security considerations There are no related security considerations, besides those, which are already known from IPv4 and IPv6.

IANA considerations IANA should open an new registry for the IPv5 address space. ---- back

Change history version 01 fixed spelling errors (lldp) fixed maximum hex value for hosts (lldp) version 00 initial draft