Re: [sig-policy] prop-050: IPv4 address transfers
Apologies for delay in replying; it was very hard to find your comments
in the reply you sent, and I missed them earlier.
Ren-Hung Hwang said the following on 16/8/09 13:45 :
>
> Sorry, my concerns might have been expressed by someone else.
> (1) 12 months is already a very short period of time for a company
> to make its vision or prediction of future direction/market. So, it is
> kind of hard to believe that we need a rule for "exceptional circumstances"
> to make up the case that a company made a wrong decision of
> transfering its address.
I have felt all along that if an organisation isn't sure whether they
need a resource or not, the last thing they'd do is get rid of it. 12
months seemed an appropriate compromise amongst the variety of opinions
expressed over the last year or so about how long a time limit should be
(see below).
> (2) It is hard to define what is a "exceptional circumstance", it is time
> and labor consuming to process a "exceptional circumstance."
> How long does it take to process a "exceptional circumstance?"
I don't know how long the existing Secretariat appeals process takes. At
a guess, a similar length of time?
> (3) I think we may consider "exceptional circumstances" if the
> time constraint is 24 months.
See my answer to (1).
> (4) Excuse my curiosity, we have been discussed the transfer policy
> for a very long time. It is not far away from the "final /8." How many
> account holders need the transfer policy before the "final /8" given
> they can apply for address from the current remaining address pool,
> apply for existing transfer policy (e.g., through merger or acquisition)?
I haven't seen any account holder stepping up and say that they require
a transfer as being proposed in prop-50. But the proposal isn't so much
about solving a current need but about pre-empting a much larger issue
when APNIC has no more IPv4 address space to distribute to the industry.
I've attached a potted summary (up to APNIC 27 meeting) from the last 2
or so years of the discussions and reasoning (on list and at APNIC
meetings) around the transfer issue. It might be useful FAQ for anyone
who wants to get an "instant appraisal" of the situation. :-) I can pop
it on to APNIC ICONS if anyone would find it useful?
Best wishes!
philip
--
History of transfer policy discussions
--------------------------------------
Problem statement:
- The IPv4 unallocated pool is running out.
- IPv6 is not being adopted fast enough, so IPv4 will still be
needed after the unallocated pool is exhausted.
- Transfers happen now, and are likely to increase as unallocated
IPv4 addresses becomes scarcer.
- If transfers are not accurately documented in whois, network
operators won’t have an accurate source of data to make routing
decisions on.
- Recognizing transfers also provided an incentive for organizations
to release unused IPv4 addresses to organizations that do need them.
Potential solutions:
- Don’t recognize transfers (retain the status quo)
o Arguments for:
• Recognizing transfers could encourage more transfers.
• The current policy model is based on “demonstrated need”,
and recognizing transfers contradicts that model.
o Arguments against:
• Transfers are happening now and will continue to happen whether
or not APNIC recognizes them.
• Not recording transfer means whois will cease in its purpose as
a valid source for networks verifying routing requests.
- Work to reclaim unused addresses
o Arguments for:
• It retains the current policy model based on “demonstrated need”.
• Reclaimed addresses can be redistributed to those who need them.
o Arguments against:
• APNIC has been working to reclaim addresses for many years using
a variety of different incentives, but with very little address
space returned.
• The limited amount of addresses reclaimed is insufficient to meet
the needs for IPv4 addresses.
- Move to IPv6
o Arguments for:
• IPv6 is the only real long-term solution for limited IPv4 numbers
available.
o Arguments against this:
• It’s over ten years since IPv6 was developed as a solution and
the industry still hasn’t made significant progress in adopting
it.
• It is very, very unlikely that we will be able to achieve in two
years what we couldn’t achieve in the last 12 or so years.
• Even if many networks make the move to IPv6, for many years,
there will be a need to connect to legacy IPv4 networks, which
will require some IPv4 addresses for each IPv6-based network.
- Recognize transfers and record them in whois
o See more detailed description of the arguments for and against
below.
Arguments against transfers:
- Recognizing transfers will encourage more transfers, leading to a
market in addresses
o Responses:
• Transfers will increase anyway as less IPv4 addresses are
available through the RIRs using the traditional allocation
method.
• IP addresses already have an implicit monetary value attached.
- It is contrary to the current model of address distribution
o Responses:
• Yes, but the situation has changed, so policy also needs to
change. (Remember, IP addresses weren’t always distributed
according to need. Then RIR system developed a policy of
needs-based addressing.)
- It will lead to an unmanageable routing table size
o Responses:
• The routing table does not reflect the allocation sizes made by
the RIRs. See http://www.cidr-report.org. Transfers of small
blocks are unlikely to have a great impact compared to natural
fragmentation of blocks already practiced by networks.
• As IPv4 exhaustion nears, it is likely that networks will
announce smaller and smaller sized blocks anyway.
- We don’t know enough about the consequences of doing this (legal,
etc)
o Reponses:
• There are also legal consequences of not doing anything.
• We know there is a problem that will occur when IPv4 is no longer
available using the current needs-based distribution model.
There are legal and business consequences of knowing there’s a
problem and not doing anything about it.
• The community needs to have faith that the EC and Secretariat
will address any legal concerns when entering the implementation
phase. Each policy passed has potential legal, financial, and
business ramifications, and the Secretariat has successfully
managed these in the past. (Stop playing armchair lawyers.)
• If we take enough time to plot out each and every eventuality
(and even then, there’s a chance we’ll miss some), v4 exhaustion
will have been and gone by the time we’ve finished the analysis.
• Let’s do the transfer policy something now, and we can make
modifications, if needed, over time. This is how the APNIC
community has developed (and then modified) policy in the past.
- It will lead to unfair distribution between those who can afford to
buy addresses and those who cannot
o Response:
• Without transfers at all, when IPv4 runs out, nobody has the
chance at all to get IPv4. If we recognize transfers, everyone in
the community at least has the possibility of being able to get
some IPv4 addresses instead of no possibility at all.
- Organizations can still get IP addresses the traditional way. We
shouldn’t recognize transfers until the RIR pool is exhausted.
o Response:
• Having the transfer option available at the same time as the
traditional needs-based allocation method gives the community
time to assess how transfers are working and to refine the
transfer policy if needed.
• It takes time between when a policy is passed and when it’s
implemented. Leave the discussion too close to the exhaustion of
IPv4, and there’s no time to implement the policy effectively.
• The earlier the community can decide on a transfer policy
(whether or not the policy takes effect before or at the time of
IPv4 exhaustion), the earlier businesses can plan how they will
respond to IPv4 exhaustion.
Summary of discussion of key elements of transfer proposal
- When to adopt: now or when v4 unallocated pool exhausted?
- If wait until free pool exhausted:
o Compounds the disruption that will already be felt by the community
at this time.
- If implement earlier:
o Gives the community a chance to try out the transfer concept and
make further policy adjustments if needed.
o Gives the community a chance to plan in the knowledge of a defined
IP addressing framework. No way to know exactly when v4 will run
out, so hard to plan for a date after which transfers will be
allowed and therefore will affect business model.
- Should current justification criteria apply to address space gained
via transfers?
- If apply justification:
o In line with the current policy framework of needs-based
addressing.
o Could lead to continued undocumented transfers (due to inability to
meet justification criteria) and therefore not solve the problem of
undocumented transfers that the proposal seeks to solve.
o People may just lie to meet the criteria.
o Places APNIC in the role of “regulator”
- If don’t apply justification:
o In line with what is needed after exhaustion occurs
o Lets the market decide how transfers are decided (APNIC not cast as
the “regulator”)
- Should there be a wait time applied to orgs who transfer space or
receive a transfer?
- If a wait time:
o Prevents organizations from getting an allocation, transferring it
immediately, then returning to APNIC multiple times to do the same
thing.
o Could disadvantage businesses that transfer their addresses, then a
little while later, their business changes and they need to acquire
more addresses.
- If no wait time:
o Organizations can justify an allocation from APNIC, transfer it to
another organization, then come back to APNIC and justify another
allocation immediately.
- Minimum accepted size for transfers: /24, /22 or no minimum size?
- If current minimum allocation size:
o Theoretically prevents too much fragmentation of address blocks
o In reality, though, entries in the routing table are not related to
sizes of allocations made by the RIRs.
- If /24:
o Acknowledges the reality of the many deaggregated /24s already
being announced to the global routing table.
o Is a compromise between a larger minimum transfer size that is
likely to be ignored and no minimum allocation size with practical
side effects related to reverse DNS, etc.
- If no minimum size:
o Acknowledges that after IPv4 exhaustion, address blocks will
probably be split into smaller and smaller pieces.
o Has side effects such as complicating reverse DNS delegations.
Outcomes from APNIC 27 (before afternoon final call for consensus):
- The minimum transfer size accepted will be a /24.
- Use of address space:
o Until such a time when the prevailing APNIC IPv4 allocation
practice uses the "final /8" policy [1], the recipient of a
transfer is to justify use of transferred space using the
allocation and assignment policies in force at the time of the
transfer.
o After that time, no justification is needed.
- Organizations disposing of their space using this transfer policy
are not eligible for APNIC IPv4 assignments and/or allocations for
two years.
- APNIC is to maintain a public log of all transfers.
- Address transfers should be permitted between APNIC account holders
and NIR members, if and when individual NIRs implement the transfer
policy.
- Address transfers are permitted between APNIC account holders and
other RIR account holders, following the policies of the respective
RIRs.
- This proposal is to take effect as soon as the APNIC Secretariat can
implement the mechanisms of the policy.
Elements that were dropped in the final draft that reached consensus:
- Use of address space:
o Until such a time when the prevailing APNIC IPv4 allocation
practice uses the "final /8" policy, the recipient of a
transfer is to justify use of transferred space using the
allocation and assignment policies in force at the time of the
transfer.
o After that time, no justification is needed.
- Organizations disposing of their space using this transfer policy
are not eligible for APNIC IPv4 assignments and/or allocations for
two years.
Two proposals to reinsert these elements were submitted since APNIC 27
for discussion at APNIC 28, but were subsequently withdrawn prior to the
release of prop050-005.
--end--