]>

Jena Germany lutz@donnerhacke.de

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.

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.

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain. This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

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