Re: [sig-policy] prop-073-v002: Automatic allocation/assignment of IPv6
Thanks for taking the time to consider our proposal and making these
useful comments. I have a number of points that I'll insert below at the
relevant sections.
andy
Izumi Okutani wrote:
>
>
> Thanks for sharing your idea about possible advantages.
>
> 2) and 3) are may be something worth considerations but pre-defining
> reservation methods might add complications or restrict flexibility to
> adjust to changes in membership (decrease/expansion). I think it's
> better to leave it to the secretariat.
>
>> However this is straying into implementation and we have no desire to
>> try to tell the staff how to implement this. By having the option
>> available to the Secretariat (and the NIRs if they adopt this) then I
>> have no problem with them interpreting 'reservation' as 'having the
>> addresses readily available'.
>
> Great. I think this will make it easier to support the proposal.
I'd like to remind readers that the comments about possible advantages
are *not* part of the proposal - we are keen to avoid any idea that we
want to say how the implementation might work.
>>
>> If we were to modify the use of 'reservation' in section 4 to 'pre-
>> approved' would that help?
>
> May be it's just a wording issue, but JPNIC (and probably a number of
> ISPs in Japan) is not comfortable with the phrase "pre-approved".
>
> Our bottom line is that IPv6 address block should be approved after
> requested - "pre-approved" seems to suggest the idea of automatic
> allocation without needs from members. (even if it's not physically
> allocated)
Our proposal is entitled 'Automatic allocation/assignment ofIPv6' so it
should be no surprise that we are suggesting something "Automatic"!
We are not saying that there should be 'automatic allocation without
needs', In Section 2 we say:
--
The authors believe that the current APNIC processes recognize that an
entity which has satisfied IPv4 criteria has done enough work to be
assessed for IPv6 resources.
--
Members who would apply under this proposal have already demonstrated
their 'need' - they've justified the allocation of the IPv4 space and
they now see that they *need* to number their networks with IPv6 addresses.
So we're asking that the Secretariat look at what a member already has,
decide that the member would get *if* they asked for IPv6 resources and
*when* the member asks the systems says "yes".
>
> We think making allocations process simple for those who need is a good
> spirit, but we don't support the proposal if IPv6 allocations are linked
> to promotion.
>
> There is also a new point raised from our hostmaster that this proposal
> will allow /32s allocations to endsites since quite a number of them
> currently receive IPv4 allocations as long as they justify required no.
> of hosts.
There's something strange about our policy if it says a member who
qualifies for an allocation of a very limited resource, IPv4, gets the
minimum allocation size of a /22 but the same member shouldn't get an
allocation of the IPv6 minimum size of a /32!
Note that the APNIC EC put the cost of having an IPv4 /22 as $1994 and
the cost of an IPv6 /32 as $1994 so they see the two things as having
the same monetary value
> This will mean some endsites receive /48s and others receive /32s, while
> most of them can live with /48s.
In the IPv4 world most people could live with a /28 from their upstream
provider and heavy use of NAT. We don't use that as a reason to limit
IPv4 addresses.
>
> If we want to avoid this problem and keep the spirit of the current
> proposal, I'd like to suggest to at least make people state if they plan
> to make assignments to other organizations if when requesting for /32
> allocation. (can be mutliple choice to minimize steps)
I don't think that we envisage a simple web page on MyAPNIC that simply
said "click here to get IPv6 addresses" - there'd obviously be a set of
Terms and Conditions that a member would agree to. I think that the
design of the interface in MyAPNIC is an implementation issue we should
leave to the Secretariat.