[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLOBAL-V6] Detailed summary of RIPE and APNIC discussions
Why are the three registry operations, ARIN, RIPE and APNIC
based on manual operations ?
Why haven't address allocation opertions become a 100% automated
web/database operation ?
Would that not allow blocks to be more efficiently managed ?
Users might be encouraged to return space if it was easy to click
on their allocation, enter authentication information, and return the
block to the pool.
Why are so many staff members required at ICANN, ARIN, RIPE, and APNIC ?
Will this lack of automation continue with IPv6 ?
It all boils down to fairness.
Which list do you think is more fair ?
The "toy" IPv4 Internet Early Experimentation Allocations ?
http://www.iana.org/assignments/ipv4-address-space
The Proof-of-Concept IPv8 Allocations ?
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
Why would people pay for Address Space, when it is FREE ?
Jim Fleming
http://www.DOT-BIZ.com
http://www.in-addr.info
3:219 INFO
----- Original Message -----
From: "Anne Lord" <anne@apnic.net>
To: <global-v6@lists.apnic.net>
Sent: Thursday, October 25, 2001 12:14 AM
Subject: [GLOBAL-V6] Detailed summary of RIPE and APNIC discussions
>
> In addition to the recent postings to this list, summarised
> below is a more detailed comparison of consensus reached at
> both the recent APNIC and RIPE Meetings. This may be useful
> input to those attending the upcoming ARIN meeting.
>
> Thanks to Takashi Arano and Kosuke Ito for their assistance in
> preparing this.
>
> Comments welcome.
>
> Anne
> --
>
> Summary of recent discussions regarding a new IPv6 address policy
> -----------------------------------------------------------------
>
> 1. Objective
> This document is prepared as a proposal for discussion to assist
> in developing the interim IPv6 policy. It summarizes the previous
> proposals conducted in AP and EU regions.
>
> 2. References for the previous proposal activities
> The consensus of AP region comes from merging both the proposal
> by Japanese community and the proposal by RIR.
> In the following URL, the original proposals are listed:
> http://www.apnic.net/meetings/12/sigs/joint_ipv6.html
>
> 3. Summary of Proposal for New IPv6 Address Allocation and Assignment
> Policy
>
> a. Basic Principle
> Among the five goals in the address policy, such as 1) uniqueness, 2)
> registration, 3) aggregation, 4) conservation, and 5) fairness, which
> should all be kept in balance in IPv4, in IPv6 the priority in
> IPv6 policy should be different. The main difference in IPv6 is:
>
> Higher the priority in aggregation, hence lower in conservation.
>
> b. Initial Allocation Criteria
> Organization needs to fulfill the subsequent allocation criteria
applied
> to /36 level.
>
> c. Initial Allocation Size
> Option 1 (APNIC consensus):
> Shorter prefix of either; (slow start)
> the fixed /32 as default
> or
> evaluation of existing IPv4 infrastructure by RIR if larger space
> necessary (ie. more can be allocated if a need can be demonstrated).
>
> Option 2 (Dave Pratt proposal):
> /28
>
> Note:
> /35 is not acceptable since it is not practical by operational point of
view.
> Keeping 4-bit boundary is highly preferable by RIPE community, but it
is
> just preferable and not critical by APNIC community.
>
> d. Subsequent Allocation Criteria
> Option 1 (APNIC consensus):
> Subsequent allocation is allowed when a certain HD-Ratio utilization
level
> is reached. The value of HD-Ratio to apply may be between 0.8-0.85,
which
> requires the further detailed study to fix it.
>
> Option 2 (Dave Pratt proposal):
> Simple 10% utilization (HD-Ratio is complicated, and 10% is about a
mean
> value when taking HD-Ratio of 0.8.)
>
> Note:
> APNIC community and RIPE community agree to relax the criteria from the
> current criteria of 80% utilization.
>
> e. Subsequent Allocation Size
> Option 1 (APNIC consensus):
> Shorter prefix of either;
> the previous (n-1)th allocation size minus 1 as default
> (any organization can obtain, at least, one bit shorter prefix if it
> satisfies with the HD-Ratio criteria)
> or
> evaluation of two-year demands submitted to RIR if larger space
necessary
>
> Option 2 (Dave Pratt proposal):
> between 2 and 5 bits so as to raise the request to the next 4-bit
boundary
>
> Note:
> Keeping 4-bit boundary is highly preferable by RIPE community, but it
is
> just preferable and not critical by APNIC community.
>
> f. Sub-Allocation: LIR to ISP
> LIRs can decide the allocation criteria and size for their customer
ISPs,
> but they must report sum of all /48s to RIR when they make a
subsequent
> allocation application for evaluation based on the subsequent
allocation
> criteria.
>
> e. Assignment
> e-1. to site/end-users
> Depending on situations, LIRs assign /48, /64, or /128 to end-users.
> RIR/NIR must not concern what size is assigned, because it is within
> the IETF's technical boundary.
> In case, an end-user assigned /48 used up the /48 space and needs an
> additional /48, this end-user is able to request so. However, the
> request will be proceeded in the RIR/NIR level, not by LIR.
>
> e-2. Definition of "site"
> A "site" is identified as ISP-connection basis, i.e., every end-user
> is eligible to get a /48 when they make an IPv6 connection with ISP
> regardless of organization, location, etc..
> * HD-Ratio is measured by the number of "sites" with /48 address.
>
> e-3. Assignment to infrastructure
> ISPs can assign up to /48 per PoP, which is regarded as just one
> assignment.
>
> f. Database registration
> Every site (/48 address prefix) should be registered in database.
> Privacy concern should be taken care, e.g., Admin-c and Tech-c are
> substituted by ISP contacts.
>
> -----------------------------------------------end of
document--------------
>
>
>
> -
> - This list (global-v6) is handled by majordomo@lists.apnic.net
-
- This list (global-v6) is handled by majordomo@lists.apnic.net
