Re: [sig-policy] APNIC 18 Proposal
Comments inline...
At 14:11 04/08/2004 +0900, Tomohiro -INSTALLER- wrote:
Summary of the current problem:
In the past, many of the organizations had requested for the minimum
allocation size(/32) as an initial allocation due to the following
reasons:
+ Based on the idea of the "slow start" in IPv4 policy, many
organizations believed it would be difficult to justify all of their
address requirements at an initial allocation.
If you want to increase the minimum allocation size, this above point
completely contradicts the solution to your problem statement, doesn't it?
+ It was difficult to estimate their needs as IPv6 network was not
commercially developed. Many organizations requested for address
space for a test service in order to kick off the commercial
service, not for the commercial service itself.
Ok, how is it hard to work out address space needs? *All* organisations I
have worked with have simply mapped IPv6 needs onto IPv4 customers to
estimate their requirements. If the true aim of IPv6 is to replace IPv4,
then this is the only logical step anyone can take. So if you have 8000
IPv4 customers, each will get a /48 should they take on an IPv6 service;
and you apply for a /35 to cover existing expectations. If you have 60000
customers you apply for a /32. If you have 250000 customers you apply for a
/30. Etc. So what's the problem? Where is the difficulty? Do ISPs not know
how many customers they have?
+ `PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT'
specified the initial allocation size as /35. LIRs which received
allocations under this policy were only allowed an upgrade of
their allocations to a /32.
I believe they received an upgrade to a /32 if they asked for it. If you
look in the various RIR databases, you'll see that not every ISP has asked
for this upgrade.
In recent days, most of the ISPs learned that /32 space is too small
for the real scale service deployment if they cover their existing
IPv4 users.
So, apply for more. What's the problem?
Organizations currently requesting for initial allocations can simply
request for a larger space as the RIRs actively emphasize to their
communities that they are able to request for allocations greater than
/32, which is already a common practice.
However, ISPs with the default address space need to design the IPv6
service network within the small space untill they clear the
subsequent allocation requirement (HD-Ratio) for more address
space. This makes the real IPv6 service deployment difficult,
especially for large ISPs.
What does "default address space" mean? Is this a /32? /32 allows for 256k
/48 assignments - this is a *huge* network for an initial rollout. If the
initial roll-out is going to be bigger, then isn't there a well established
APNIC process which allows this?
Details of your proposal:
Existing IPv6 initial allocation address holders should be able to
expand their address space without satisfying subsequent allocation
criteria if they are able to demonstrate their concrete plan. The same
criteria should apply as organizations requesting for an initial
allocation larger than /32.
This proposal does not intend to change the current policy but to
apply the current allocation practice to existing IPv6 address
holders.
If it is possible to expand the address space under the current
policy, it is desirable to be documented clearly (e.g. in the
guidelines document).
This sounds more like a misreading or misunderstanding of existing APNIC
policy, rather than anything approximately relevant to how IPv6 addresses
are requested from and allocated by APNIC. IMHO.
I still don't understand what the problem is from reading the proposal. It
seems to me that you are saying simply that /32 isn't enough to deploy an
IPv6 network today, and that there are some mysterious barriers preventing
you from applying for more address space from APNIC. It would be really
useful to see a very clear statement as to what these mysterious barriers
are, as then I think it might be easier for the community to understand
what the problem is.
Looking forward to some clarification... :-)
philip
--