ARIN IP6 policy for those with legacy IP4 Space

David Conrad drc at virtualized.org
Sun Apr 11 19:20:48 UTC 2010


On Apr 11, 2010, at 9:03 AM, Owen DeLong wrote:
> Well, if they want to operate under the previous regime, then, they should simply return any excess resources now rather than attempting to monetize them under newer policies as that was the policy in place at the time.

Why?  There were no policies to restrict how address space was transferred (or anything else) when they got their space.

> Certainly they should operate under one of those two regimes rather than some alternate reality not related to either.

When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary.  Much later, a policy regime was established that explicitly limits rights and you seem surprised when the legacy holders aren't all that interested.

> Interestingly, APNIC seems to have had little trouble asserting such in their region,

Hah. I suspect you misunderstand.

> Can you point to a single working deployment of multi-layer NAT?

I suppose it depends on your definition of "working".  

I've been told there are entire countries that operate behind multi-later NAT (primarily because the regulatory regime required ISPs obtain addresses from the PTT and the PTT would only hand out a couple of IP addresses).

I have put wireless gateways on NAT'd hotel networks and it works for client services, for some value of the variable "works".

> I can recall experiences with several attempts which had varying levels of dysfunction. Some actually done at NANOG meetings, for example. As such, I'm willing to say that there is at least anecdotal evidence that multi-layer NAT either is not workable or has not yet been made workable.

The problem is, anecdotal evidence isn't particularly convincing to folks who are trying to decide whether to fire folks so they'll have money to spend on upgrading their systems to support IPv6.

Regards,
-drc
 



More information about the NANOG mailing list