Re: [sig-policy] prop-086: Global policy for IPv4 allocations by the IAN
> 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.
> > 1. 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.
> > 3. 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.
> > 5. 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