[arin-ppml] The non-deployment of IPv6



>> Michel Py wrote:
>> I would entertain that IPv4+ (which would be a backwards-compatible
>> IPv4 with the only difference being an extended address space) would
>> be much more popular as a solution if it was on the table.

> Fred Baker wrote:
> The obvious solution would be to put a source and destination AS
> number in options in the IPv4 packet, and in the presence of such
> a thing route to the remote AS before attempting to interpret the
> address.

I think the routing part of it does not matter. Remember: the goal here
is to simplify adapting host software to the larger address space.

> Recall that the problem there isn't a failure in the design of IPv6;
> it's that IPv4 was not designed to have an extensible address.

Ack that.

> It would make a lot of sense. How, precisely, would you achieve that?

With NAT, we already have a (crippled) 64-bit address space. Inside IP +
Outside IP.

Here are the design goals of IPlg:

- Make the transition as simple and as cheap as possible for everyone.
The only thing to achieve is a larger address space. Protocol
enhancements shall be implemented only if they make the transition

- Some rewriting will be required to use the full address space. As much
as possible, that rewriting should be limited to using a 128-bit address
instead of a 32-bit address.

- Single stack (that is what I call backwards compatible); the IPlg
stack must be able to handle both IPv4 and IPlg addresses. The IPlg
stack replaces the IPv4 stack.

- The critical part of IPlg is the IPv4 <-> IPlg NAT. The IPng address
structure must be designed with this in mind, not as the most efficient
or the most elegant.

More specifically the IPlg address space will embed NAT hints, such as
including both the public/outside and private/inside IPv4 addresses of a
host behind a public/RFC1918 NAT device. There is a one-to-one mapping
between an IPv4 and an IPlg address. The IPlg address space is a 128-bit
address; for the transition phases, the IPv4 <-> IPlg NAT mechanism is
based on a 64 bit unique identifier computed from 32bit-outside-address
+ 32bit-inside-address.

In other words: the IPlg address space is to be designed primarily as a
migration mechanism. The core of this migration is a workable and simple
NAT between the two address spaces. We are designing workable NAT, not a
new protocol.

IPv4 -> IPlg:
The edge/source IPlg router builds a source IPlg address with both the
inside (possibly RFC1918) and the outside (public) addresses. The
destination address is computed with the inside bits set to 0 (*), as
they are not know. Both are valid IPlg address. When the returns traffic
comes, the router remembers the mapping, strip the extra bits, and sends
back to the IPv4 host.
The egde/destination IPlg router understands that the destination
address is from an IPv4-only host because the "inside bits" are all 0
and forwards to the right host based on manual rules (*).

IPlg -> IPv4:
The IPlg of the IPv4 host is to be used as the destination address by
the originating host.

(*) Some fancy NAT hints may come in here.

3 phases:

- Compatible/test: production traffic is IPv4 to IPv4 only. Essentially
the extra bits are padded with zeroes. The goal of this phase is to
allow the deployment of the stack on routers/on the backbone. During
this phase, a packet can cross both IPv4 and IPlg routers; when
receiving a packet from an IPv4 router/host, the IPlg router pads the
extra bits with zeroes. When sending an IPlg packet to an IPv4
router/host, the IPlg router strips the extra bits.
This phase ends when the community is confident that the IPlg stack has
been deployed.

Obviously this will take many years during which RIRs will allocate IPlg
addresses for tests. The IPlg block derived from the IPv4 address is
automatically assigned to the IPv4 recepient.

- Transition: IPv4 to IPlg translation shall occur only at the edge
router, for those still using that W95 PC in 2020. The core shall handle
only IPng traffic.

- Decommission: we're all old and retired, we declare IPv4 is gone.