[ppml] those pesky users...

Stephen Sprunk stephen at sprunk.org
Thu Mar 29 20:39:59 EDT 2007


[ Responses to a half-dozen similar messages consolidated. ]

Thus spake "Ted Mittelstaedt" <tedm at ipinc.net>
> Why does it cost double for ARIN to keep track of 2 data elements
> for my AS, my IPv4 allocation and my IPv6 allocation, instead of
> keeping track of only one data element - my IPv4 allocation?

ARIN charges fees based on the estimated cost of handling the registration 
of the resource, and the reality is that different resources cost ARIN 
different amounts to handle.  The reason is that ARIN doesn't just "track" 
resources as you've claimed; ARIN also determines whether there is a need 
that justifies the resource per existing policy, and the cost of doing that 
varies widely depending on the request, the requestor, etc.

> The whole thing was a mistake on separate fee structures for IPv4
> and IPv6 IMHO.  It really looks like an intent to set an artifically
> high fee for IPv4 and artifically low fee for IPv6 with the expectation 
> that
> it would cause people to switch over.  It appears that people
> haven't switched over.  So, give them both and then ARIN and the
> RIR's can simply concentrate on tracking ALL numbering that is out
> there.

IPv4 costs ARIN more than IPv6 will, just like bigger blocks cost ARIN more 
than smaller blocks; the fees reflect those variable costs.  The members/BoT 
have decided to waive the IPv6 fees because either (a) they feel encouraging 
IPv6 is worth more to the community than the money they'd collect, and/or 
(b) the current total cost of IPv6 registration is so minimal it's not 
currently worth the effort to collect fees.  That will undoubtedly change.

> Suppose I go to customer X that has 35 people on a [random
> product] which is not IPv6 compliant [ and ] will not be IPv6
> compliant for several more years.  And it requires a 64 bit server.
>
> The upshot is that I have to tell these guys if they want to update
> to IPv6 right now they have to ...

... do absolutely nothing other than turn it on.  Enabling IPv6 does not 
make IPv4 stop working, though that mistaken idea does pop up from time to 
time.  You turn on v6 where it's supported, and you start using it.  When 
you no longer need v4, you turn it off.  Note that there will likely be at 
least a decade between these steps for most networks unless there's some 
serious changes made in the transition plan.

> These customers get sold a big bill of goods by [vendor]

We all love to bash [vendor] as much as the next guy, but it really isn't 
relevant to the discussion at hand.

> All those people are trying to find the killer app to get end users
> to start buying television and movies on-demand, and to start
> buying software on-demand.
> They are not interested in writing a killer app for us to help IPv6.

When exhaustion starts forcing users through v4-v6 NAT devices, the killer 
apps for v6 will emerge because v4 will no longer offer end-to-end 
connectivity.  For instance, tell people they can't use BitTorrent to pirate 
movies on v4 anymore and they'll figure out how to get v6 running.  That 
alone will get a few tens of millions of people (and half the Internet's 
usage) switched over...

> Figure out a way to generate customer demand and interest.  I
> have already - use of a T-date.  I know how successful that is with
> people, the global warming people are using it very successful
> right now.

Um, no, they're not.  The public reaction to global warming has mostly been 
"that's nice, but I'm not giving up my SUV."  However, I suppose that's a 
good analogy, because IPv6 advocacy has been about as successful so far.

> We have had a strategy of encouraging customers to use NAT
> ever since 1999, as a result our total IP address need has not
> changed, since we have been able to answer our own growth
> needs for more numbers for more customers by taking away
> larger blocks (/24s and the like) from customers that we originally
> had assigned to them.

Congratulations; you've managed to paint yourself into a corner.  When 
exhaustion occurs, your competitors will start recycling their existing, 
plentiful addresses to keep growing, but you'll have to go to IPv6 to keep 
growing, paying that transition cost long before they have to.  Doing what's 
best for the community at your own expense is generally not good for 
business.  That's why we have community policies that limit how greedy 
people can be: to enforce our desired level of altruism with a level playing 
field.  If you choose to tilt the field toward your competitors, I'm sure 
they'll be thankful for that.

> And I am sure now the booing and hissing from the peanut gallery will
> start at the mention of the N-word.  Fine, go F*() yourselves.

Please be professional.  There are plenty of places you can go if you want 
to swear at people; this isn't one of them.

> It makes no difference to a customer that is using, for example, a
> /22 internally if the ISP comes along and assigns him a /22 of IPv4
> or a /29 of IPv4.  He is STILL GOING TO PUT a NAT in there.

And?  IPv6 will give you the opportunity to sell him a new NAT box that is 
capable of translating between v4 and v6 -- assuming vendors get around to 
making such boxes.  If not, everything will just keep working as it does 
today except he won't be able to reach new IPv6-only hosts until he 
dual-stacks.  Big deal.

> No, I am saying essentially go through all documents that have the
> word "IPv4 address" and "IPv6 address" and replace it with "IP
> address"
>
> You are enormously hung up on the idea that IPv4 and IPv6 are
> technically different and this matters from a tracking standpoint.
>
> What ARIN and the RIR's do is track IP addresses.  IPv4 and
> IPv6 are IP addresses.  They do not matter one bit from a
> tracking standpoint, there are merely "stuff to track"

Again, you misunderstand what RIRs do; see above.  There _are_ critical 
differences between IPv4 and IPv6 that necessitate different policies. 
Pretending they're the same doesn't make it so.

> Why is it even necessary to have the problem of IPv6 adoption
> related in any way to the RIR's?  If the migration for IPv4 to IPv6
> is to dual-stack everything, then just assign both IPv4 and IPv6
> when the RIR's hand out IPv4 addresses.  So what if the
> requestor doesen't have any need for IPv6 right now.  Eventually
> he will and then he will have the stuff assigned already.

There is a _cost_ in allocating/assigning IPv6 blocks to people, and it is 
fiscally irresponsible to incur costs serving people who don't want to be 
served.  And, when IPv6 use becomes non-trivial, ARIN will need to recover 
the costs of people who _do_ want/need IPv6 registry services, and we'll 
need to start billing for that service, especially since IPv4 revenue will 
start to wind down unless (or, depending on your views, because) the 
members/BoT decide to follow one of the various rate-hike proposals to get 
people off IPv4.

> Boiled down, you have no solution to propose for getting people
> migrated so your going to argue that we all do nothing.  It's
> someone elses problem.  It's not my problem, it's the other guy
> who is supposed to be out there creating demand.  No, I don't
> know how he's going to create demand, that's his problem.

I'm working on solutions, but none of them are relevant to ARIN or RIR 
policies in general.  Don't mistake "ARIN isn't the right place to solve 
this" for "let someone else solve it."  Many of the folks here wear many 
hats and _are_ working on solving the problems in other fora that are more 
appropriate.  You'll see the same names pop up in many community groups like 
ARIN, NANOG, IETF, etc. but each of those groups has a specific charter. 
Just because you've stumbled apon the ARIN list doesn't mean that it's a 
catch-all for every problem or even every aspect of one particular problem.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov 





More information about the ARIN-PPML mailing list