On Mon, Aug 16, 2010 at 04:37:50AM -0700, Philip Smith wrote:
I have a few concerns about the proposal, in-line...
I apologize personally for the delay in my response. I have
consulted with the rest of the authors to craft the reply below.
- Introduction
This policy defines the process for the allocation of IPv4
addresses post "Exhaustion Phase" [1].
Why are we trying to prolong the use of IPv4 even past the
end? Just curious as the text doesn't say why we want/need to
do this.
Sorry for not being more clear about this.
If there is IPv4 address space available at the IANA, it should
be distributed to the RIR's to be utilized as the community sees
fit. It is our belief that it would be used to help facilitate
transition and to be a small help in avoiding participating in
costly address markets.
We also believe that our stewardship of IPv4 address space will
be called into question if any region has exhausted their address
space, but then is unable to receive free space that is held at
the IANA. Without a alternate/better global policy proposal
that can be implemented in a timely manner (i.e. prior to IANA
exhaustion), we propose our framework for global consideration.
- Summary of the current problem
With the depletion of the IANA free pool of IPv4 address
space, the current policy regarding the allocation of IPv4
address space to the RIRs will become moot. The RIRs may,
according to their individual policies and procedures,
recover IPv4 address space. This policy provides a mechanism
for the RIRs to retro allocate the recovered IPv4 address
space to the IANA and provides the IANA the policy by which
it can allocate it back to the RIRs on a needs basis.
Why would, and what's the incentive for, the RIRs to return
IPv4 address space to the IANA?
It's expected that the RIR's, through regional policy, will do
their best to cooperate. We have the example that right now, an
RIR can take five /8s from the IANA. Yet, the RIRs have agreed
to take up to only two /8s at a time.
If someone has a way to incent all five regions to return address
space as part of global policy we are open to the suggestion. We
did ask for such suggestions when we posted draft proposals to
all five RIR addressing forums. We didn't receive any questions
or suggestion to include incentives for RIRs to return address
space.
As I have responded to Izumi-san's question, we have already
seen address space returned to IANA for redistribution. We can
imagine that this may happen again.
This policy creates a new global pool of IPv4 address space
that can be allocated where it is needed on a global basis
without a transfer of address space between the RIRs.
The proposal in 5.3 says that the reclamation pool is divided
equally amongst RIRs - which contradicts the above para.
We did not intend to contradict ourselves. :)
To clarify, 5.3 states:
The Reclamation Pool will be divided on CIDR boundaries and
distributed evenly to all eligible RIRs.
The key word here is "eligible". If an RIR is eligible, then
the space will go there "where it is needed".
It's worth noting that an RIR can fall in and out of eligibility
depending on its state of exhaustion.
5.1 Reclamation Pool
Upon adoption of this IPv4 address policy by the
ICANN Board of Directors, the IANA shall establish a
Reclamation Pool to be utilized post RIR IPv4 exhaustion
as defined in Section 4. The reclamation pool will
initially contain any fragments that may be left over in
IANA inventory.
I understood that IANA was exhausting its entire pool. Or is
exhaustion really just complete /8s? It would be helpful if
someone from IANA could clarify as I was under the impression
that remaining fragments would be distributed as well,
certainly before IANA declared that the cupboard was bare. The
remaining fragments are not insignificant.
Since Leo Vegoda has already started to answer this, I'll reply
to that thread....
5.3 Address Allocations from the Reclamation Pool by the IANA
Allocations from the Reclamation Pool may begin once the
pool is declared active. Addresses in the Reclamation
Pool will be allocated on a CIDR boundary equal to or
shorter than the longest minimum allocation unit of all
RIRs in order to complete these allocations.
"Longest minimum allocation" doesn't parse very well, and
indeed the first two words contradict each other. Perhaps it
would be clearer to say "smallest minimum allocation".
Thank you. We will consider your alternate wording for clarity.
Yes, the intention is to use the smallest allocation block
size out of policies from all RIRs. As you may have seen from
my reply to Izumi-san, we might consider exempting addresses
set aside under soft landing policies from consideration when
calculating whether an RIR has exhausted its address space. It's
conceivable that we would also exempt minimum allocation sizes in
the soft landing policies when considering how to divide the new
free IANA space.
All this, of course, is open for discussion.
The Reclamation Pool will be divided on CIDR boundaries
and distributed evenly to all eligible RIRs. Any
So each time when, say ARIN, pushes the button for the policy,
and gets a /19, the other 4 RIRs will each get a /19 as
well? Even if they don't need it? This seems an unusual method
of address space distribution - maybe we should have thought
about this at the start of IPv4 20+ years ago. ;-)
It also means that the RIRs who have actually implemented
runout policies (eg APNIC) for the final /8 will start
stockpiling extra address space. Remind me what the incentive
was for returning unused address space to IANA? This seems like
a contradiction.
Ya know, that's not all that different from dividing the last
five IANA /8s evenly. And that's triggered when only 1 RIR
has demonstrated need while the other 4 have address space. :)
In your example, only when an RIR is considered to have exhausted
its address space will it be considered to be eligible for the
/19. So if an RIR doesn't need the space, they won't get it.
5.4 RIR Eligibility for Receiving Allocations from the
Reclamation Pool
Upon the exhaustion of an RIR's free space pool and
after receiving their final /8 from the IANA [3], an RIR
will become eligible to request address space from the
IANA Reclamation Pool when it publicly announces via
its respective global announcements email list and by
posting a notice on its website that it has exhausted
its supply of IPv4 address space. Exhaustion is defined
as an inventory of less than the equivalent of a single
/8 and the inability to further assign address space
to its customers in units equal to or shorter than the
longest of any RIR's policy defined minimum allocation
unit.
Again "longest minimum" doesn't make a lot of sense (to me
anyway). Also, exhaustion means "nothing left", not "1 month's
supply" in the case of APNIC. Or "2 year's supply" in the case
of AfriNIC. Etc.
Perhaps we need to define "exhaustion" better with some about of
X month's supply. There is a time component in the currently
active global policy for when RIRs request /8s from the IANA.
Any RIR that is formed after the ICANN Board of
Directors has ratified this policy is not eligible to
utilize this policy to obtain IPv4 address space from
the IANA.
This seems grossly unfair and unreasonable. What if, for
example, a new RIR is formed in the Middle East. Do you
seriously think that this new RIR should be denied any IPv4
address space at all, especially when the rest of the world is
still trying to share IPv4 address space amongst the folks who
too lazy to move onwards?
I expect that if a new RIR is forming with global community
support, we as a comunity will have ample time to update the
global policy to include the new RIR.
But if a new RIR just appears out of nowhere....
5.5 Reporting Requirements
The IANA shall publish on at least a weekly basis a
report that is publicly available which at a minimum
details all address space that has been received and
that has been allocated.
Don't they do this already for the existing IANA
allocations? As do the RIRs. (I guess this is making sure that
IANA doesn't stop doing it.)
Yup, just want to be absolutely clear here. The IANA does not
have an obligation right now to publish in the report the details
of where new space was received.
5.6 No Transfer Rights
Address space assigned from the Reclamation Pool may be
transferred if there is either an ICANN Board ratified
global policy or globally coordinated RIR policy
specifically written to deal with transfers whether
inter-RIR or from one entity to another. Transfers must
meet the requirements of such a policy. In the absence
of such a policy, no transfers of any kind related to
address space allocated or assigned from the reclamation
pool is allowed.
The reason for banning transfers is...?
APNIC has a policy allowing transfers between account
holders. I don't think that this policy can simply march in and
take over the existing transfer policy proposal like this. I'd
rather see a separate proposal covering transfers after this
one gains consensus. (Or it could be done in parallel I
suppose.)
We authors do not intend to interfere with intra-RIR transfer
policies that cover all address space prior to the IANA
exhaustion. The transfer restriction is applied only to
IANA-reallocated addresses covered by this policy proposal.
We would like to encourage the RIR's to develop inter-RIR
transfer policy that is fair to all regions. Right now, transfer
policy is disparate between the regions and it was part of the
reason that the previous global policy approach was not able to
move forward. By removing the transfer issue and encouraging the
communities, we hope to remove one of the major roadblocks to
enabling such a global policy to be potentially successful.
This policy gives RIR a fair amount of control through knobs
such as transfer policy and minimum allocation sizes. Overall,
we could not capture every use case to make everyone happy and
instead decided that we would set the expectation that RIR
communities would work together in fine tuning this proposal
after ratification.
- Pros/Cons
5.1 Advantages
- The policy provides a mechanism for the ongoing
distribution of IPv4 address space.
Why do we need ongoing distribution of IPv4 address space? I'd
have hoped that the policy proposal would have explained this
somewhere.
Again, sorry for not being more clear in the introduction.
Please see my response above.
5.2 Disadvantages
- None identified.
See above. There are many.
Perhaps we should have said "None identified as of this posting."
:)
philip
Thank you for your thoughtful questions.
Please feel free to reply on list so that all the authors may
provide further responses. As I'm unable to be onsite today,
Kenny Huang and Owen DeLong is assisting us for the presentation.
However, I will be available to the audience via Skype. Also,
some authors will be participating via remote facilities.
Best Regards,
Louie
--
Louie Lee
One of the authors of prop-086