[arin-ppml] Draft Policy 2009-1: TransferPolicy (UsingtheEmergencyPDP)

[Matthew Kaufman]

michael.dillon at bt.com wrote:
>
> Then you are not looking very far, or more likely, you are not a network
> technical person and therefore feel no need to keep up to date on the
> details of the technology. For at least ten years now we have had
> interworking mechanisms that allow IPv6 networks to access the IPv4
> Internet and vice versa. New ones are coming along all the time such as
> 6VPE. There are no magic bullets, but there are many ways of making
> interworking function well enough to keep a network operator growing and
> profitable.
>
>   
I am very much a "network technical person", but that is hardly relevant 
to the discussion.

There are interworking mechanisms under development, a few deployed, 
which allow IPv6-only hosts to access services that are exclusively on 
the IPv4 Internet. Because dual-stack was originally the primary 
solution to this problem, the early approaches are few and far between, 
though development has sped up significantly across several (probably 
too many) IETF WGs. But as previous posters have pointed out, IPv6 was 
very clearly not designed for interoperation with IPv4... instead it was 
designed as an all new Internet protocol, and sold on many features 
(automatic configuration, IPSEC, etc.) that were interesting enough that 
IPv4 got them anyway (and a few that still aren't going to happen, like 
ubiquitous worldwide IPv6 multicast), thus reducing the perceived value 
of IPv6. Now, of course, we have an emergency... IPv4 addresses will run 
out, and dual-stack doesn't solve that problem at all.

All methods that allow an IPv6 host to access the IPv4 address require 
somewhere between one IPv4 address at the gateway (e.g., NAT64) and one 
IPv4 address per host (dual stack). None work in the case of zero IPv4 
addresses available for the deployer of the gateway or host.

I do agree that an existing network operator with IPv4 space at their 
disposal will be able to use various techniques to continuing growing. 
Some operators (providers to consumer end-users) will have it easier 
than others (hosting of services that require unique IP addresses).

New entrants will be at a significant disadvantage in that there will be 
no PI space available from any RIR, so they will be limited to either 
getting IPv4 space (possibly overloaded via things like port-range 
sharing a la SHARA) from their ISP or acquiring IPv4 space either via 
the proposed transfer policy or via existing transfer mechanisms (buying 
existing holder entities).
>> Where does a hosted service that needs to deploy more servers 
>> to serve increased demand from existing IPv4 clients get IPv4 
>> addresses from after the runout?
>>     
>
> From a 6to4 gateway or from some type of NAT box such as NAT-PT.
>   
I don't think that's a viable solution. A service that needs to deploy a 
new unique IPv4 address to a host that is expected to be reachable from 
the legacy IPv4 Internet isn't going to be able to use a NAT device to 
synthesize that new address. Perhaps a NAT device would make it possible 
for that host to share an address with an existing host, but only if the 
port usage is compatible. (For example, deploying two entirely separate 
servers that respond on a well-known port isn't going to work)

> If you don't even know the fundamentals, then why are you in this
> discussion?
>   
I know the fundamentals, but even if I did not my opinion for or against 
a transfer policy is relevant as a holder of both legacy and ARIN RSA 
IPv4 space. Personal attacks are irrelevant, though if you knew my 
background regarding network protocol design and deployment and/or my 
background in ISP operations you might have just skipped them altogether.

Matthew Kaufman