Re: [sig-policy] prop-078: Reserving /10 IPv4 address space to facilitat
Hi Terence,
On 04/08/2009, at 7:15 PM, Terence Zhang YH wrote:
[..]
As we mentioned in the appendix 'reason for /24', we can expect
routing
practices will change when we are running out of IPv4, but we don't
know when and how this is going to happen, so we don't want
to create longer prefixes just because of this policy.
I don't see this as 'creating' longer prefixes - instead providing the
consideration that people shouldn't have /32s (v4) to route.
We believe /24 is the most generally accepted longest prefix
currently,
that's why we choose /24, it's also consistent with the minimum size
of the transfer proposal.
And that is perfectly fine.
Perhaps I wasn't clear in my critique. I didn't mean that APNIC should
issue /27s from the start - I mean that over time, and the foreseeable
future, longer prefixes will be requested as v4 becomes a tight
commodity. The policy should, I think, acknowledge that and limit the
prefix length.
As we mentioned in the 'reason for /24', in the future, if longer
route
prefixes are more generally accepted, or a smaller minimum
allocation size takes effect, we can certainly reduce the size of
allocation under this policy to suit future needs, and ensure more
allocations from this block are possible.
Finally, a relatively larger allocation size will minimize the
possibility of an organization getting multiple non-contiguous small
blocks in multiple allocations.
I agree with both of the above two paragraphs.
2) Specifying that this block is taken from the final /8 is perhaps
restrictive. I suggest leaving it to the secretariat to decide which
block this /10 is taken from.
First of all, whether the reserved block come from the final /8 or not
doesn't impact the spirit of this proposal, I also believe it's more
flexible to leave it to the secretariat to decide which block this /10
is taken from.
excellent.
Secondly, This is a balance between setting aside too much space and
not having enough for IPv6 deployment. Although it's not necessary,
we recommend to reserve this /10 from the final /8 because of
the following:
1. If we reserve the /10 from outside the final /8, then, together
with
the final /8 policy, totally /8+/10 will be exluded from normal
IPv4 allocation, which means less addresses available for IPv4
services.
It might just be my interpretation, but having a /8 in reserve or
reserving the final /8 are approximately the same.
I don't see that it exacerbates the v4 availability issue.
2. Current /8 policy will provide 16384 allocations. Setting aside
a /10
from that /8 will reduce the allocations to 12288. Since currently
APNIC has about 2000 members and is projected to have 4000 members
in 2013.
So we believe setting aside a /10 from the final /8 will have little
impact to the final /8 allocations under current policy.
So, we believe reserving the /10 from the final /8 has less impact
to the
current policy and allocation status.
To be honest, I would much rather see smaller allocations where, as
you say further down, organisations are less likely to come back for
additional allocations taken from already fragmented blocks, and not
split up a nice contiguous /10 from a pristine /8.
3) If a transfers policy is adopted, I would suggest that if a member
(or nir member) transfers v4 address space to another organisation
and
holds a 'ipv6 deployment' allocation from this policy, that the 'ipv6
deployment' allocation is automatically recovered by APNIC.
(eg the member has just proven their ability to renumber)
If I understand you correctly, your goal is to prevent people from
address trading, I appreciate that idea.
to clarify, trading *this* allocation assigned by *this* policy.
And if they have enough space to trade, do they _need_ this allocation?
But the purpose of the IPv4 allocations under this policy and
other IPv4 allocations are different,
IPv4 allocations under this policy are
for 'IPv6 to IPv4 interconnect', while
other IPv4 allocations are for IPv4 services,
That may be, however in the proposal conditions you stipulate a
requirement that the member must meet a utilisation point and be
unable to renumber v4 to allow themselves room for such transition
services. That seems orthogonal to the purpose. Or have I
misinterpreted the reasons for the conditions?
There for, I don't think we need to question the eligibility for
an organization to receive IPv4 for IPv6 deployment just because
they give up some IPv4 addresses for normal IPv4 services.
In which case wouldn't that make the conditions for allocation moot?
Although this allows the possibilities of trading, since the
allocation
size under this policy is only /24, the incentives to make profit
from this block is not high.
Finally, even current proposed transfer policy will remove
justification and re-application limit when APNIC start using the
final /8 allocation, so I don't think we need restriction
for transfer in this proposal.
I'm just trying to work out why you have the conditions then at all,
regarding the utilisation et al.
[..]
6) I question your assurance that no organisation will lack ipv4 for
ipv6 deployment given an organisation may have several of these
allocations. But that might just be a cynical view.
As we mentioned in the appendix, In most cases we can foresee, a /24,
can perfectly satisfy the deployment needs for one organization.
There for we don't expect an organization getting multiple /24s
under this policy, but we have to allow that possibility, since
there might be some special situation we cannot foresee from now.
So this proposal allow subsequent allocations, but restrict that
with 12 months interval and 75% utilization rate, and this 75%
utilization rate is restricted to facilitate IPv6, NOT IPv4 services.
Of course, theoretically, this proposal DOES NOT guarantee
'no organisation will lack ipv4 for hundred years', but practically
speaking, with 16384 allocations, together with 12 months
reapplication interval and 75% untilization rate, also
consider current APNIC members projection, we can
expect this pool can support the needs for IPv6 to IPv4
internetworking for at least 10-20 years.
:-) If this proposal is adopted, I'll add that to a calendar.
I also want to point out that the demand for IPv6 to IPv4
internetworking will be stable at a certain point. Since V4's
growth will be limited by address resources, and as V6 grows
to a certain scale, the needs for communicate with V4
will be kept in a certain level .
7) I am hedging to say that an allocation of this sort should be time
based. How much time? hard to say given that v6 deployment should
have
been done by now. But holding a 'transition' allocation indefinitely
dilutes an incentive to actually transition.
I would say, even if the world move to IPv6 tomorrow, the demand for
IPv6 to IPv4 internetworking will be sustained for many years.
Investment protection is a very important rule in the IT industry,
Investment v legacy, but I concede to the point.
I believe there are still legacy IBM server running SNA over
TCP/IP at present time.
8) why do you have the restriction on eligibility if the member has
received an allocation in the last 12 months? wouldn't your following
rule about 80% utilisation cover it?
As what I said in responding your comment 6), In most cases we can
foresee,
a /24 can perfectly satisfy the V6/V4 interconnect needs for one
organization. There for we don't expect many subsequent allocations
going on, but we have to allow that possibility.
Though given that this is about "reserve relatively adequate space for
IPv6 to IPv4 internetworking" which means to me that the past or
previous allocations in this policy to the member shouldn't need to be
considered. Just so long as they show need right?
12 months interval and 75% untilization rate is to prevent one
organization consuming too many blocks from this /10.
If that organisation is consuming multiple blocks to further support
deployment of IPv6, I think that is acceptable. Why hinder their
efforts?
9) I don't think I read anywhere in this proposal that sparse
allocation methods must be used. Regardless of the prefix length I
think we would want to give members every opportunity to aggregate if
multiple allocations are issued to a member.
I agree with you sparse allocation is a good method to allow
aggregation,
We didn't mention sparse allocation method because of the following:
1. We believe the secretariat will make allocation with best practise
2. we don't expect too many subsequent allocation
If most people believe we have to explicitly point out sparse
allocation
in this proposal, we are happy to do that.
Clearly my feelings are on record ;-)
10) What are your feelings on a member sub-allocating this range to
their customers? allow? disallow? conditional?
At this point, although we think sub-allocating a /24 is not
practical,
I would consider sub-allocating is welcome as long as they follow
the rule of 'facilitate IPv6 deployment' and their route to the
global routing table is a single /24.
Maybe you might like to cover that in the policy.
Cheers
Terry