Re: [sig-policy] prop-078: Reserving /10 IPv4 address space to facilitat
Thanks for your comments again, here are our explanations:
>
> 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.
>
I think we have the same view on this matter, we all aware that routing
practise will change when we are running out of IPv4 . But we don't know
when and how this changes may happen, so we design our policy base on
current best practise and allow the change in the future, when we are
more certain about the changes.
I think
" /24, or APNIC's minimum allocation size, which ever is smaller"
is already take this into account.
I don't want APNIC's policy take the lead to create lots of /27 route entries
in the global routing table, but if other RIRs take the lead, or if
it's already de facto, APNIC may surely follow.
> 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.
>
The difference is slight, but when we design policy,
we try to make impact to the current consensus & adopted policies
as less as possible.
>
> 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.
>
The pristine /8 as well as the /10 will be fragmented into /24s or /22s
anyway. Of course, other already fragmented blocks can also serve
as the same purpose of this proposal, this policy proposal does NOT
imply other blocks cannot or should not be used as IPV6 to IPV4
internetworking purpose.
> to clarify, trading *this* allocation assigned by *this* policy.
> And if they have enough space to trade, do they _need_ this allocation?
>
When we design this policy, we consider this block of IPv4 is for
supporting IPv6 deployment, so, to make it simple,
a first allocation don't link to any other IPv4 ultilizations,
but subsequent allocation will certainly take this into account.
It's just one /24, as long as they are used for IPv6 to IPv4 internetworking,
I believe we have adequate reserve.
As for the tranfer issue you raise, I will put some thoughts on it.
>> 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?
>
>
This proposal seeks to slove the above problem, you understand it perfectly,
but people don't have the above problem can also take advantage of
this policy to get their first allocation from this block, as long as
their true intent is to deploy IPv6. But the subsequent allocations
will have much more restriction and take everything into account.
>
> 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?
>
The first allocation doesn't link to any other IPv4 resources
the member have, since we think the purpose of those resources
are different and we want to give people a little incentive
to deploy IPv6. But the subsequent allocations
will have much more restriction and take everything into account.
> If that organisation is consuming multiple blocks to further support
> deployment of IPv6, I think that is acceptable. Why hinder their
> efforts?
>
As I said, with /24 size, we don't expect too many sebsequent allocations,
/24 is enough for an organization to satisfy the growth of demand for
IPv6 to IPv4 internetworking for at least one year.
>> 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.
>
Current allocation and assignment policies has covered
sub-allocating rules, we don't intend to change that,
as for the 'facilitate IPv6 deployment' requirement,
it's justified in each allocation as the proposal specify.