[arin-ppml] Set aside policy?

[William Herrin]

Personally, I like the idea of having a respectable-sized IPv4 block
set aside for the end -- not for "transition" but for "technically
reasonable requests for which no reasonable alternate solution other
than globally routable IPv4 addresses is possible."

There's a theory that says address markets will keep IPv4 addresses
available. People will follow the money. Given a dollar value for
addresses, use that offers insufficient earnings could compress by
CGNs, by IPv6 migrations or even by more careful review of existing
deployment.

If that theory pans out, it will still take some time after depletion
for the economic process to sort itself out and begin to work
smoothly. It would be nice, during that sort-out period, if
requirements that were technically impossible to meet with RFC1918,
IPv6 or other v4 conservation measures still had a pool from which
they could be met.

If that theory doesn't pan out, it would be nice if that pool was
available while we figure out how, in a regulatory fashion, to recover
addresses from existing trivial (NATable) use. As a community, we're
unlikely to seriously consider how to reclaim addresses until and
unless doing so becomes critical to the continued operation of the
Internet.

So, I favor a set-aside.



On Fri, Jul 2, 2010 at 10:49 AM, Jason Schiller <schiller at uu.net> wrote:
> In the very near future people will [in my opinion] be
> forced into building IPv6-only networks.

Jason,

I fixed your post.

Your opinion has merit and is shared by a number of folks on this and
network ops lists. However, at least one alternate view - that NAT
will extend the life of IPv4 indefinitely (or at least until IPv4's
use is no longer desirable) - holds similar merit.

In my opinion, people will follow the money. They usually do. Money
remains to be made in expanding your IPv4 network, by hook or by crook
even if that means employing more and different NAT. There's still
little money to be made in building an IPv6 network. Start talking to
the customer about future-proofing and they'll ask you to keep an eye
on it and let them know when the future actually arrives.

No price is too high if you can sell it for more. No cost is low
enough if you can't.


> Personally I don't think the IPv4/IPv6 Carrier Grade NAT solution is going
> to work well.  I suspect it will have problems with scaling, problems with
> being easily supported, problems with providing good CALEA support,
> interfere with geo-location, and be a big target (with lots of collateral
> damage) for DoS attacks.

>From a holistic perspective, NAT doesn't seem to have a whole lot of
trouble with these issues in comparable deployments today. Think:
serving enterprises at a few hundred to a few thousand users at a
time. Or serving carefree users at hot spots and hotels.

I'm curious: what challenge do you envision for CGNs that isn't
already overcome in one of those scenarios?


> The next less bad solution is to offer exactly one IPv4 address to each
> IPv6-only network.  This will allow them to stand-up their own (read at
> the customer premise) IPv4/IPv6 NAT.

Last I heard, and please point me to the appropriate RFC if I'm
mistaken, there was was an IPv6 address range set aside to mean "IPv4
connection using IPv4 packets via IPv6 API" but no IPv6 address range
set aside to mean "IPv4 connectino in IPv6 packets to be NATed at the
IPv6/IPv4 border."

That makes IPv4/IPv6 NAT so much more complex than vanilla IPv4 NAT --
it has to implement a full DNS proxy resolver and pray that the DNS
packets take the same trip through the NAT as the data packets so that
the response to the AAAA query returns addresses the NAT will
consistently map to the right IPv4 addresses. Gonna wreak havoc with
DNSSEC too.

IPv4 CGNs are at least conceivable. I don't see first-generation v6 to
v4 NATs being viable in production deployments. It will take some
deployment of NAT-friendly client PC code that deals with A records in
a v6-only environment which will take some standards work despite the
portions of the IETF crowd that are bitterly opposed to any NAT in
IPv6. That puts us far past free pool depletion.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004