[arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement)

Izaac izaac at setec.org
Sat May 12 21:58:47 EDT 2012


On Sat, May 12, 2012 at 02:58:45AM -0500, Jimmy Hess wrote:
> > - Outright REQUIRE IPv6 requests to correspond with and accompany all
> >   IPv4 requests.  And then actually assign and issue that IPv6 space --
> 
> 1. Problem...  it encourages  providers and end users to apply for
> IPv6 resources that they won't use.

It compels requesters to consider deployment at least as far as
completing the paperwork.  They may go ahead and "just do it" once they
realize the most basic requirements are met and they have the resource
already literally in their hands.  Or they won't.  It really doesn't
matter.

What does matter is that they'll have it for the day when it becomes in
their interest to do so on short order.  How many more participants in
IPv6 day do you think there would have been if address blocks were just
laying around waiting to be deployed by excited network engineers?

> 2.  The concept requires that IPv6 resources come from ARIN,  but
> there may be other sources of v6 addresses such as an upstream,  or a
> global organization has an IPv6 allocation from a different RIR;
> they should not be required to obtain their IPv6 space from ARIN.

Please substitute the term IPv4 for IPv6 in the above and re-read.
Done?  Good.  An organization who can justify an IPv4 allocation from
ARIN is surely in the same position to justify an IPv6 allocation from
ARIN for the same network.

> Maybe instead you want to add a requirement that IPv4 allocations for
> new networks  be in compliance with RFC 6540,   and the applicant to
> receive v4 by new allocation or by transfer show this,  if they are
> not also applying for v6 address space..

If this did not work for the homogeneous and hierarchical US Department
of Defense, it surely will not work for the heterogeneous rest of us.

> 6to4 gateways are not necessarily an advisable migration strategy.

Why not?  It's widely deployed and proven effective.  Further, it fits
perfectly with the concepts of end-to-end connectivity, the role of
routing infrastructure, and is easily understood: "Ohh, so the entire
IPv4 internet fits into this nice little 2002:: chunk and I get all
these addresses mapped for free?  Got it.  And my hardware and software
already do this?  Cool.  How do I turn it on?"

> 4to4 / CGN has significant advantages.

Are you're seriously advocating NAT444?  Allow me to condense the long
investigation into why this is bonkers by generalizing the wrongness
into one very simple statement:

Nothing -- and I mean nothing -- along the path should be molesting my
packet in any way whatsoever.

As corollaries: You do not steal bits from a field of a deeper layer in
order to pretend that you have a larger network address space.  You do
not handle routing by introducing stateful information from outside the
network layer.

And as a frank aside, how is it that I can hear a carrier whine about
how the BGP table is getting unmanageably large while at the same time
hearing him advocating for what amounts to introducing and consistently
tracking a thousand little state entries per /32?  Yeah, I know the
difference between core and border.  But there's obviously a serious
mental disconnect here.

> > - Actually bother to pronounce an IPv4 deprecation date.  Only some weak
> 
> It would be inappropriate at this time for ARIN to announce a
> deprecation date for

Well, then don't phrase it as deprecation.  ARIN seems to have no
problem regularly proclaiming IPv4 address exhaustion.  How about
sunsetting the handling of requests for any actions related to IPv4
allocations?  "What's out there is what's out there.  We're washing our
hands of it."

> IPv4 or IPv4 addressing.   It's not a RIR's place to do that;
> it's  IETF's.

Is it?  The IETF is an standards body.  ARIN is an operating body.  You
probably meant IANA.  And speaking of saying, "What's out there is
what's out there.  We're washing our hands of it."  The only way they'll
probably get involved in IPv4 again is if through some seemingly
impossible turn of events one of the RIRs relinquishes a /8 for one of
the others to fight over.

> If ARIN were to decide they wanted to get out of IPv4 addressing prematurely,
> it would be time at that point for them to be replaced as RIR for IPv4.

If ARIN is still primarily screwing around with IPv4 in 2019, perhaps
this is indeed the most appropriate course of events.

> It's amazing that despite the enormous amount of evidence to the contrary,
> people keep regurgitating the totally unfounded myth that markets
> provide the good
> solution to all   problems.

Sigh.

> If this were true,   TCP/IP  would    not be deployed very much,
> because it would
> never have caught on;  the market would have recognized this problem,
> and prevented
> TCP/IP from succeeding.    Instead most networks would be using the
> best closed proprietary (and therefore most lucrative) replacement for
>  TCP/IP that the market  had  brought us,  which would have no  IP
> address resource exhaustion problem from the beginning.

Actually, no, the market is what caused the success of TCP/IP.  Dig up
someone (sadly, this may require a literal interpretation) from Novell,
DEC, or Apple and ask about how that all happened.

Yes, I understand that it's easier to generate and disappear into the
smoke and miasma settled over the field of economics.  But you'll notice
that I have not yet made even one suggestion economically rooted.  So,
what do you say that we just leave economics as the aside it was
intended to be.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__



More information about the ARIN-PPML mailing list