[arin-ppml] Set aside policy?

Marshall Eubanks tme at multicasttech.com
Thu Jul 8 09:32:00 EDT 2010


On Jul 8, 2010, at 9:20 AM, William Herrin wrote:

> 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.

I agree with this reasoning, and this conclusion.

Regards
Marshall


>
>
> 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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>




More information about the ARIN-PPML mailing list