Had a great discussion via Twitter and my blog’s comments about some stuff about IPv6 and other ways of handling the IPv4 address space shortage. Over the course of discussing things and arguing stuff and going back and forth, I think I’ve sharpened my idea.
IPv4+
IPv4+ is an extension of IPv4 address-space via backwards-compatible use of the IPv4 ‘Options’ fields. Two such options shall be used, one for an ‘extended-address-space’ destination, one for ‘extended-address-space’ source. If these fields are used, they MUST be the first two options in the packet. If both extended-source and extended-destination options are used, the destination MUST be first. This enabled (eventual) hardware-assisted routing at a fixed offset within the IPv4 header. Extended addresses grant an additional 16 bits of address space. If any routing decisions are to be made based upon extended address space, those SHOULD only be done at an intra-networking layer, within one autonomous system. The extended source and extended destination options are exactly 32-bits long, each. The format is as follows:
| Bits | 0 | 1-2 | 3-7 | 8-15 | 16-31 |
|---|---|---|---|---|---|
| Field | Copied | Class | Number | Length | Data |
| Values | 1 | 0 | 5/6 | 3 | Address Data |
Option 5 will be used for Extended Destination, and Option 6 will be used for Extended Source. Perhaps additional options could be reserved and specified for future use as “Super-Extended Destination” and “Super-extended Source”.
IPv4+ addresses will be specified in text as having two additional octets – e.g. 72.14.204.99.56.43. The extra octets on the right-hand side correspond to the extra 16 bits of addressing data. An address with both additional octets of zero is understood to mean a legacy IPv4 node at that address. E.g. 72.14.204.99.0.0 means the IPv4 node at 72.14.204.99.
Operation of the protocol will be designed to be as backwards-compatible with Unextended IPv4 as possible.
IPv4+ nodes have both an IPv4 address – which may be an RFC1918 non-routable address, or a link-local address – as well as an extended IPv4+ address, which SHOULD be a routable IPv4 address plus 16 additional bits of identifying data. The legacy IPv4 address MUST be locally unique within its network segment. A backwards-compatible IPv4+ that uses an RFC1918 address for its legacy IPv4 address SHOULD (MUST?) be connected to a Router or Gateway that is capable of Network Address Translation.
As the protocol gains acceptance, core BGP routes MAY be extended to full /32 networks.
An IPv4+ node learns it is on an IPv4+ compatible network through an extra DHCP option, or it may be statically configured as such.
IPv4+ ARP protocol is not currently defined.
An IPv4+-aware gateway OR node MUST be aware of the mapping from IPv4+ addresses to legacy IPv4 addresses. The mapping SHOULD be programmatic – e.g. 192.168.1.2 corresponds to 72.14.204.99.1.2.
MOST implementations will likely be RFC1918 addresses for legacy IPv4, and routable IPv4 addresses as the first four octets of the IPv4+ address. So-called “Public Hosts” MAY exist at some point in which they have both a routable IPv4 address AND an IPv4+ address. The only purpose of such a host would be future-proofing – no real benefit is conferred, other than ensuring that software stacks can utilize extended addressing.
An IPv4+ gateway MAY define a ‘default host’ which should receive all unidentified legacy IPv4 traffic, or it may drop any such packets, or it may use a simple heuristic such as ‘lowest address wins’.
“IPv4+ ONLY” hosts cannot exist. Non-legacy-routable IPv4+ hosts could exist by the local gateway refusing to NAT addresses by responding with ICMP Destination Unreachable or a new ICMP message.
Software implementations SHOULD embed 48-bit IPv4+ addresses in their existing IPv6 software stacks – which have already been implemented and rolled out. A special segment of IPv6 space SHOULD be allocated and reserved for this embedding to ensure no collisions occur if IPv6 were to become more widespread.
Interoperability Scenarios
two IPv4+ nodes on the same network
MUST use their legacy IPv4 addresses to communicate. An IPv4+ node can identify the IPv4-legacy address that corresponds to the other node because of the nodes required knowledge of mapping between IPv4+ and IPv4-legacy addresses.
two IPv4+ nodes on different networks with through IPv4+ transit
IPv4+ packets are sent and received through extended IPv4+ addresses.
IPv4 node and IPv4+ node on same network
An IPv4+ node will use its IPv4 address and the IPv4 protocols to contact the ‘legacy’ node. The IPv4+ node can identify the IPv4 node via its legacy 32-bit address.
IPv4 node and IPv4+ node on different networks, IPv4+ aware router on IPv4+ network
The IPv4+ node uses its legacy IPv4 address to talk to the IPv4 node. The IPv4+-aware router NAT’s the traffic to the IPv4 node.
IPv4 node and IPv4+ node on different networks, IPv4-only router on IPv4+ node’s network
Interesting – at some point the IPv4+ node MUST become aware that it does not have through connectivity to the other IPv4+ node, and must fall back to using its legacy address. The IPv4 gateway or router will not be able to communicate to the IPv4+ node because the IPv4+ node will ‘appear’ to be transmitting packets from an incorrect address. The IPv4+ node SHOULD eventually disable IPv4+ connectivity as it will be unable to communicate to any other devices. An ICMP ‘Ping’ exchange may be employed to determine that the gateway is not IPv4+ aware by examining the return packet’s IPv4 options (if any).
Migration Scheme
“Access” routers (small office, home office) need new firmware to handle iPv4+. IP stacks in major operating systems need extensions for IPv4+. ISP’s who do not firewall their customers do not need to do anything. IPv4+ compatible applications now have restored end-to-end connectivity.
Eventually, DNS extensions SHOULD be created to permit returning extended IP4+ addresses for services.
An ARP extension MAY be at some point required for nodes that do not require legacy connectivity.
BGP routing will eventually need to be broadened to support /32 extended networks (a /32 network could correspond to a full 65,000 host internetwork).
Interior routing protocols MAY need to be extended to make routing decisions based on extended IPv4+ addresses. The header order and length has been optimized to make this as painless as possible, but it may still be painful.
An additional 8-bits of address space can be reclaimed once all routers are compatible with IPv4+ – the length byte can be counted as an address space indicator, which is 3 for all initial IPv4+ networks, but could be allowed to vary once the entire Internet is switched over to IPv4+.
Concerns
This is a stopgap.
Will routers in the ‘wild’ strip options they do not understand? Will they ever reorder or muck with options? Do we really have to steal that one byte in the option to say ‘3’?
Will IPv4 live on forever? Will routers always have to handle all the crazy NAT and other stuff that will be a legacy of ‘legacy’ IPv4?
Will the only additional ‘feature’ of this IPv4 thing be better BitTorrent nodes?
BIG CONCERN will network devices get confused about seeing IP packets with “apparently” identical IPv4 addresses (really extended IPv4+ addresses) and freak out?
10.0.0.0/8 network is too large to map all of its hosts as IPv4+ addresses to use one legacy IPv4 address. It might require a full Class-C allocation of legacy IPv4 addresses to map every possible host. Yuck.
Should this protocol actually attempt to map full IPv6 addresses into appropriate extension headers?
I have one slight variation. The name already seems to be in use for other protocols. So I would change the name. However, the main problem I see is that you need to supernet the entire IPv4 rather than subnetting the IPv4 address. This will give you multiple address spaces the size of IPv4. The idea I had is to add a 2 or 4 digit hex number before a standard IPv4 address for example, a1f0.192.168.0.1. This will not only give us additional addresses. It will simplify the learning curve for the billions of technicians and idiots out there.
I was on the fence about that too; but my concern was that I wanted to leverage and respect the existing global routing tables – rather than subsuming them into some other routing table space. I've also considered adding an additional 'options' header with further "left-hand-side" address space. Not sure.