I think you'll find that the guy deploying the IPv6-only client -or-
server is going to be in the minority for a long time to come. But if
you want to bet against me, more power to you.
I hope you're right, but you put up the scenario of me being unable to get a
v4 address. I suspect I won't be the first there, and I hope that by the
time that is an issue for me, I will be in the majority already
John,
You'll be able to get another v4 address. It'll cost you noticeably
more than it does now, but you'll be able to afford it. Thing is, if
you induce me and others to deploy IPv6 now, you may not have to get
another v4 address then, nor pay for it. So if there's a way you can
induce me to deploy IPv6 now that doesn't cost you any money now or
later, well, that's ultimately money that stays in your pocket.
a) if I don't have to get an IPv4 address then Ill be standing up a v6 only server, by which time, again, I hope to be in the majority
b) ARIN or RIRv6 has costs that are covered by registration fees. How does having a whole bunch of freeloaders save me money? Doesn't it increase my share of the costs? Doesn't giving you free IPv6 now continue my costs into perpetuity whereas just ignoring you may add some operational cost until you're either in an insignificant percentage or you give up and start playing by the same rules as everyone else?
Keeps money in my pocket too since I'll have the same problem, but
what do you care about that? It's your money that matters, not mine.
Inducing behavior that ultimately reduces everybody's cost "serves the
public interest." That's what organizations like ARIN are for: serving
the public interest.
But I don't agree that giving you a free ride reduces everyone's costs. In fact, I think it increases everyone else's costs.
This comes on top of my annual reading of the distribution of the US tax burden.... there are some parallels to be drawn in terms of fairness.
1) Justify why we need a heavy bureaucracy such as ARIN for IPv6
numbering resources,
Because the members of ARIN (and the other four RIRs) want it that way.
And because nobody has yet made a serious proposal to ICANN that
would replace ARIN.
2) Tell me why something like the old pre-depletion pre-ARIN model
of InterNIC and just handing out prefixes with substantially less
paper-pushing wouldn't result in a cheaper-to-run RIR.
Because the ARIN members, who pay most of ARIN's fees, are not
complaining about the level of those fees. This means that they
think the fees are cheap enough, or else they would demand that
the fees be changed. All ARIN fees are set by the ARIN members.
--Michael Dillon
P.S. When you send your proposal to ICANN, please post a notice
here on the NANOG list so that we can all go have a look at it.
b) ARIN or RIRv6 has costs that are covered by registration fees.
How does having a whole bunch of freeloaders save me money?
'Cause if you're clever about it, they're not freeloaders forever...
they only get to be freeloaders until, as you so succinctly put it,
their presence pushes you into the majority that finds it acceptable
to deploy IPv6-only servers.
What I might do, and I'm just talking here, but what I might do in
ARIN's shoes is preemptively allocate /32s or assign /48s to ARIN orgs
whose ASes currently announce only IPv4 prefixes. The deal is:
everybody gets em, no assignment fee or evaluation beyond the fact
that you're announcing IPv4 now, free for two years after which you
either sign the contract and start paying the annual, or you don't and
the address block is reclaimed by ARIN.
Gives me a $1250 incentive to deploy IPv6 now instead of waiting, and
costs you nothing now since I wouldn't have spent the $1250 now
anyway. Probably costs you nothing later too, because after two years
I'll be paying annuals that I might not otherwise have had to pay
-and- since my assignment was done in bulk, ARIN staff will never
spend the time (time=money) individually processing my initial
assignment.
Inducing behavior that ultimately reduces everybody's cost "serves the
public interest." That's what organizations like ARIN are for: serving
the public interest.
But I don't agree that giving you a free ride reduces everyone's
costs. In fact, I think it increases everyone else's costs.
Fair enough. I won't begrudge you the choice. Just remember years from
now when you cough up the cash for that extra v4 address: you had
another option.
> in the IPv4 space, it was common to have a min allocation size of > a /20 ... or 4,096 addresses ... and yet this amnt of space was
> allocated to someone who only needed to address "3 servers"... say
> six total out of a pool of four thousand ninty six.
Granted, that may have been the case many years ago.
However, this was not our experience when we obtained addresses, and the
ARIN rules as I understand them would not allow such an allocation today.
i picked a fairly recent example - the min allocation
size has fluctuated over time. still it is not the case
that most folks will get -exactly- what they need - they will - in nearly every case - get more address space than
they need - due to the min allocation rules
We did, on our first allocation. We were well over 90% utilization and when
we asked our upstream ISP for more addresses, we were informed they would
not provide us a 17th /24. We scrambled to get our documentation together
for ARIN. We had to show efficient use of those 16 /24s, and we had to
document our immediate (12-24 month) need for addresses to get them.
> Thats a huge amnt of wasted space. If our wise and pragmatic leaders
> (drc, jc, et.al.) are correct, then IPv4 will be around for a very
> long time.
>
> What, if any, plan exists to improve the utilization density of the
> existant IPv4 pool?
I believe your question is based on an outdated assumption.
and that outdated assumption is?
The assumption that ARIN allocations are based on anything other than 12-24
month need (with only a few exceptions).
If there are a significant number of sparse allocations of IPv4 blocks in
ARIN, then that's a good indication that allocation rules need to be
updated.
>>>
>>> What, if any, plan exists to improve the utilization density of the
>>> existant IPv4 pool?
>>
>>I believe your question is based on an outdated assumption.
>
> and that outdated assumption is?
The assumption that ARIN allocations are based on anything other than 12-24
month need (with only a few exceptions).
allocations are based on:
) current policy
) demonstrated need
always have (even pre-ARIN, pre-RIR) ... when the policy was "there is
a network and host split" then every qualified applicant got a /8.
and your point about getting "enough" for a 12-24 month need backs
up my assertion that you are allocated more than you need.
there is some "padding" for you to grow into. which you may or may not
do. strict needs based allocation would give you -exactly- what you need
at the time of the request - sort of like a DHCP assignment no?
If there are a significant number of sparse allocations of IPv4 blocks in
ARIN, then that's a good indication that allocation rules need to be
updated.
the tricky parts there are:
) how is utilization defined?
) how to accomodate historical and legacy delegations that had different
assignment rules than are currently in effect.
) is it -worth- the cost to effectively manage a resource pool or are we
willing to unilterally declare a "chernobyl Zone of Alienation" around
the IPv4 pool that we have, by our own unwillingness, agreed to consider
"toxic" and too costly to manage... and proceed to use the exact same
policies/procedures on the IPv6 pool - which despite zelots claims to
the contrary - is finite and we stand a very real chance of screwing it
up too. I'd like to see the community work toward a real 80% utiliztion
of the IPv4 pool (since I know for a fact taht there is lots of sparse
allocation out there...)
Excellent questions... The direction with respect to ARIN is that
the Board has spent significant time considering this issue and
the guidance provided to date is that ARIN is to focus on its core
mission of providing allocation and registration services, and
be supportive of other related organizations (e.g. NANOG, ICANN,
ISOC) which perform related functions in the community. This
approach has reduced the risk of mission creep (at least as far
as I can tell...
From a practical matter, it also means that we need to consider
a future for ARIN which provides a core address registry function,
modest IPv4 updates and modest IPv6 new allocation activity, and
likely a very stable policy framework. This vision of the future
is highly compatible with automation, and ARIN is indeed working
aggressively in this area with ARIN Online. I do think that
automation plus a reduction in activity will result in a modest
reduction in overall costs, but the costs associated with having
an open community-based organization aren't necessarily changing:
- If you have the community to elect AC and Board members, then
you have a membership/election function (which implies specific
costs in the organization).
- If you have the community set policy via an open policy process,
then you have a policy process, policy proposal administration,
and public policy meetings (which again implies more costs to
the organization, roughly proportional to the policy activity).
- If you participate in the global policy process (coordinating
with other RIR's, ICANN, and now the ITU), then there is yet
another set of costs to be covered by the organization.
I'm committed to keeping the costs reasonable and proper for
the mission, but its the community that needs to think about
that mission and what they want ARIN (and the RIR community
as a whole) to be doing 10+ years from now... Input can be
provided in many forms, including on the mailing lists,
in-person and remotely in the Public Policy Meeting, via the
various consultations that ARIN does with respect to services
and fees, and directly via running for the ARIN Board in the
annual election process.
Excellent questions... The direction with respect to ARIN is that the
Board has spent significant time considering this issue and the
guidance provided to date is that ARIN is to focus on its core mission
of providing allocation and registration services, and be supportive
of other related organizations (e.g. NANOG, ICANN, ISOC) which perform
related functions in the community. This approach has reduced the
risk of mission creep (at least as far as I can tell...
From a practical matter, it also means that we need to consider a
future for ARIN which provides a core address registry function,
modest IPv4 updates and modest IPv6 new allocation activity, and
likely a very stable policy framework. This vision of the future is
highly compatible with automation, and ARIN is indeed working
aggressively in this area with ARIN Online. I do think that
automation plus a reduction in activity will result in a modest
reduction in overall costs, but the costs associated with having an
open community-based organization aren't necessarily changing:
i think this is realistic, wise, and admirable. it is damned hard for
an organization to resist mission creep, etc., and focus on mission,
especially when that means long term shrinkage.
Another bright gentleman many years ago suggested that we have an online
website which allows anyone to pay a fee and get an address block. This
is not inconceivable, but does completely set aside hierarchical routing
which is currently an underlying mechanism for making our addressing
framework scalable.
Another way to accomplish this would be a functional global model for the
settlement of costs relating to routing entries, and which would effectively
be against routing entries caused by unique "provider-independent" prefixes.
ISPs today don't get specifically compensated for routing a PI address block,
but they do get to participate in the various RIR processes and have some say
in the impacts of public policies as they are discussed. Historically, this
has proved to be sufficient input that ISPs generally respect the tradeoffs
inherent in the approved policy, and will route the result.
If you have an economic mechanism which handles this function instead, and
an abundance of resources (e.g. IPv6), then it might be possible to operate
under very different assumptions than the present Internet registry system,
and the resulting costs of operating the registry portion could be minimal.
The implementation of this is left as an exercise for the reader...
/John
p.s. These are my personal thoughts only and in no way reflect any position
of ARIN or the ARIN Board of Trustees. I provide them solely to help
outline some of the tradeoffs inherent in the current Registry system.
Doesn't end user PI assignment already do this? Note I'm not arguing against end user PI assignment policy, rather just making the observation that given IPv6 did not address routing scalability, the path we're heading down is obvious, the only question is how fast. The problem is that ARIN is getting in the way of people (some of which are ARIN members) dumping nitrous into the combustion chamber.
This doesn't seem like a stable, long term viable situation to me.
The ISPs participating in ARIN get to disusss the impact of various allocation
thresholds on their routing during the policy development process.
If you have a magic vendor machine issuing prefixes to all comers regardless
of need, then the routing scalability problem becomes much, much poignant,
and the ability of the community to course correct is zero.
The Fee Schedule, is continually reviewed by ARIN's membership,
and its Advisory Council, and Board of Trustees to identify ways in
which ARIN can improve service to the community and to ensure
that ARIN's operational needs are met
Since the AC and Board of Trustees are elected by the Members,
ultimately the members have control of fees.
