Re: [sig-policy] prop-051: Global policy for the allocation of the remai
- To: <sig-policy at apnic dot net>
- Subject: Re: [sig-policy] prop-051: Global policy for the allocation of the remaining IPv4 address space
- From: "Hytham EL Nakhal" <hytham at mcit dot gov dot eg>
- Date: Sat, 11 Aug 2007 19:16:25 +0300
- Delivered-to: sig-policy at mailman dot apnic dot net
- List-archive: <http://www.apnic.net/mailing-lists/sig-policy>
- List-help: <mailto:email@example.com?subject=help>
- List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
- List-post: <mailto:firstname.lastname@example.org>
- List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:email@example.com?subject=subscribe>
- List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
- Thread-index: AcfcMvcw//50+n34T8KXU4TrQ0uAtw==
- Thread-topic: [sig-policy] prop-051: Global policy for the allocation of the remaining IPv4 address space
I hope my mail find you in good mood. First, I'd like to thank Mr.Toshiyuki Hosaka for presenting our proposal "Global policy for the allocation of the remaining IPv4 address space" in APNIC region.
Second, I'd like to reply to all comments on this proposal, I know, I'm late but excuse me I was under work pressure that prevent me from following up most of mails...
How are you doing Philip? I hope you be fine. I'm sure you have a great sympathy for this proposal (Thank you), But I've notice some contradictions in your emails, you wrote:
> The problem for our region is that it brings the timeline of run out of
> address space for APNIC forward by a good 12 months, meaning just over2
> years of IPv4 space left.
>In any event, I believe at least RIPE NCC and APNIC are requesting
>smaller IPv4 /8 blocks from the IANA now, which goes a long way to
>ensuring the fairer distribution of what is becoming a limited resource.
First, you refer to the probable disadvantage of the proposal on APNIC which will forward the run-out time by 12 months, keeping in mind that APNIC in that time will receive 5 /8 blocks automatic from IANA, and APNIC could then manage assignment process in suitable manner as they want. Then you mention that APNIC & RIPE now will request smaller /8 blocks from IANA, which will lead to delay the run-out of IP blocks Ö (forward & delay) Thatís one.
Regarding IPv6, All know about AfriNIC and LACNIC activities for promoting IPv6 in their regions. You specifically have participate in many training and workshops for IPv6 in AfriNIC region. And the best evidence on our activities is the last press conference held by AfriNIC and Adiel stated the AfriNIC activities toward that: AfriNIC has started since
>If some of the LIRs in those two regions converted from
>NAT and double NAT to using real IPv4 addressing, both LACNIC and
>AfriNIC would receive more IPv4 /8 blocks sooner, making the chance of
>them running out first less of a likelihood.
Again as Raúl said, It is not LACNIC's objective. We don't want to promote a competition for getting IPv4 addresses from the unallocated pool. Right the opposite.
In addition to what Iíve said in last AfriNIC meeting in
NAT is not the core of the proposal so please we can discuss it latter.
Philip>As I said at the AfriNIC meeting a few months ago, it would be better if
>LACNIC and AfriNIC made it very clear to their members (e.g. like ARIN
>Board did re IPv6)
Roque reply > Two things, first big address consumption ISPs at the bigger RIR
>regions will not base their business plans on the possibility of getting
> addresses at LACNIC or AFRINIC, they will transit to IPv6.
Philip>The former is very possible. The latter still sees a lot of business
>needing persuading to make the investment.
>So let's not given them any reason to be creative - a uniform global
>"run-out" ensures that people can't be creative, and that they then can
>only consider IPv6 as part of their business model moving forwards.
Sorry, I got confused .. Do you encourage deploying IPv6 or not ? And from financial & investment for deploying IPv6, IMHO,
ISPs in developed countries at bigger RIR regions are capable to support this investment more than others ISPs in developing countries..
Roque > You are missing that at the bigger RIR there are huge amount of legacy allocations and unallocated space that will be
> fueling a secondary address market. Companies in less developed part of the world will have zero influence at this market.
Philip >I didn't see this discussed in the policy proposal. Besides, I don't see
>how a legacy allocation market is going to help a newcomer. The Internet
>is growing very quickly in South and
Central Asia, the Middle East etc.
>Or are they all meant to spend e-bay prices to get address space
The implicit mean of the proposal is to prevent monopoly for bigger RIR in selling their legacy allocated space which are not assigned
for LIRs yet, by preserving a suitable amount of /8 blocks for each RIR to make use of it as per their own policies.
And for fast growing Internet market such as in South & Central Asia, and
Middle Eastif the allocated 5 /8 IPv4 blocks at their RIRís
run-out they can deploy IPv6. IMHO, Itíll be fair instead of inequity for the other slow growing market in other regions.
Roque > considering one of the biggest benefits of this policy. It release the
> pressure on the central IANA pool allowing each RIR to focus on their
> own policies.
Philip>I don't see this at all. How would it reduce pressure? And how would it
>allow the RIR (and presumably the RIR membership) focus on their own
>policies? What would be needed to be focused on?
Itíll reduce pressure by preventing battle on the remaining IPv4 blocks,
and will allow RIR to focus on their policies and how to modify it if needed for distributing the allocated blocks from IANA.
>I've even had people ask me if they can "sell" their IPv4 address space when it
>becomes valuable in the next year or two and use NAT instead.
Thatís assuring the need for such proposal to avoid as much as we can monopoly and exploitation.
So itís better to reach an equity distribution of the remaining pool.
Raúl > But I only wanted to point out that it is not
> about LACNIC or Afrinic, so saying LACNIC and/or
> Afrinic shoud do "something" is a wrong approach to the discussion.
Philip>Agreed also. Everyone needs to do something, but I think we need to
>really figure out what this "something" is. I don't think prop-51 is it,
So, whatís this suitable something in your opinion? Is it deploying of IPv6 .. Itís determinism, we all admit that,
and this proposal doesnít discourage thatÖ Itís only seeking for the fair and equal allocation of
the remaining IPv4 pool to all RIR and each RIR is free to assign its allocated blocks according to its existing or modified policies.
For example may RIR reserve part of its blocks for critical operation assignment
or modify the existing assignment policy to enforce the newcomer LIR to have IPv6 deployment before applying for IPv4..
>Yes; there are currently many organisations who have RIR membership in
>more than one region. If they need more IPv4 address space, they will
>apply for it. Not doubting the RIR staff for a second, but we can't
>assume for a second that applicants won't be creative.
What is the percentage of these ISPs with regard to the whole ISPs in all RIR regions ?
>So this proposal basically says to APNIC members "hey, give up one
>year's worth of /8s so that LACNIC & AfriNIC don't have to worry about
>IPv4 space for another 3 or 4 years hence". Where is the advantage for
>the APNIC membership? Why would APNIC members request APNIC to >change allocation policies, and what to?
Well, very good question..
Letís consider the both situations, keeping the presence on demand IANA allocating policy and the proposed policy..
IANA now have about 46 /8 unallocated IPv4 blocks, In case of on-demand policy any RIR probable allocations
will ranged from 46 blocks in best case Ėto- Zero blocks in the worst case (no allocations)
that depends on LIR requests during the coming three years as statistical said IANA pool will exhaust in 2010 .. and In case of the
proposed policy any RIR probable allocations will ranged from 26 blocks in best case Ėto- 5 blocks in worst case..Ö. What do you think ?
Is loosing 20 blocks allocated for other RIRs in the second case is compared with zero blocks in the worst case in the first case?
Keeping in mind that these 20 blocks you could loose in the first case as they could be allocated to other RIRs upon their request..
but in the first case you may have Zero blocks or less than the five blocks the proposal asking for.
Hi, Itís nice to meet you here in the mailing list and hope to see in the coming event ISA.
>Indeed, but it isn't clear to me how this proposal helps that situation. The ISPs
>with the most power are also the ones who probably already have
>offices/subsidiaries/partners/etc. in Latin America and
Africa. Unless AfriNIC
>and LACNIC become _extremely_ stringent on membership and invest heavily
>in verification mechanisms, I don't see the larger ISPs even blinking at this sort
>of thing. Just the cost of doing business...
Also the same question: What is the percentage of these large ISPs that have many offices in different RIR regions with regard to
the whole ISPs in all RIR regions ? and to avoid the probable second market for IP addresses
itís better to insure at least 5 /8 blocks for each RIR. And each RIR is capable for regulate distribution and assignment
of its pool in order to avoid that situation as much as possibleÖ for
there is three Large ISPs has offices in other RIR than AfriNIC Egypt
and they do use their IPs and AS they got from AfriNIC.
Roque >Two things, first big address consumption ISPs at the bigger RIR regions
>will not base their business plans on the possibility of getting
>addresses at LACNIC or AFRINIC, they will transit to IPv6.
David>No they won't. They will do whatever is necessary to obtain the IPv4 >address space they need to continue business.
ISPs in developed countries will do whatever is necessary to obtain the IPv4 to continue their business and not transit to IPv6, whereas ISPs in developing countries which are less in technical capabilities and face financial problems are required to transit to IPv6 faster than ISPs in developed countries .. Is it the fairness from your point of view ?
>Rearranging where the IPv4 free pool sits isn't going to help things all that much >(although it might remove IANA as the target for lawyers, thanks! :-)). Large >scale ISPs have the resources to set up offices in Latin America and
If itíll not help, at least will keep fair & equity allocation of the remaining pool over existing RIRs and then each RIR could manage its allocated pool according to their policies/membership state. And as Roque said you can discuss the number of allocated /8 blocks for each RIR..
David>a) customers don't want IPv6 (nor do they want IPv4 -- they want "the >Web"/their pr0n, they don't care about the details).
>b) migrating to IPv6 has real costs and because of (a), there are no additional >revenues to cover that cost.
>c) they _can't_ migrate because their equipment/software vendors don't yet >support IPv6.
Roque > I agree, even if ISP do migrate to IPv6 there is not content there. So, we will have a double stack scenario for several years/decades.
I agree too and like to add that not yet all software applications & hardware appliances support IPv6 such as many firewalls and IPS. So IPv6 fully deployment will need a time may be long specially in developing countries.
>Unless AfriNIC and LACNIC become _extremely_
>stringent on membership and invest heavily in verification mechanisms,
Raúl >Why not ? good point. But not only that. Other measures will be
>necessaries in the future too for avoiding or limiting the RIR shopping. And this
>is something that should be done by all the RIRs due to the fact that nobody
>know which one will be the first in running out of IPv4 addresses (if one). And it
>not depends only in the distribution of the unallocated pool, but also on the
>regional policies for dealing with the last part of the regional stocks in each region.
I agree and as mention before each RIR can modify its policies in a manner to face this situation, with stressing on deploying IPv6.
>P.S. It might also be argued that the paradox you note could be a
>blessing in disguise as it means those in developing countries will
>make the shift to IPv6 that much sooner.
>This is something similar to say that developing countries will be the first ones in >shifting to ethanol based cars because they will not have oil. But so, we will >have to produce our own cars, and it will be of course more expensive than >buying the cars produced for the big mass. Shifting to IPv6 is an objective and >of course, it is probably more important for developing countries since they have >less margin for speculating, and of course we are working very much on that >and spending large amount of resources as we have been doing for the last 4-5 >years, but the main objective for all of us should be, IMHO, a non traumatic >transition to IPv6 worldwide.
Totally agree .. Transition to IPv6 will not happen an a day and night, It needs time not a short time but we have to start in same time
we have to ,IMHO, be fair in allocating the remaining IP blocks in equal manner between RIRs.
Iíve an example for IPv6 deployment in Egypt, we have 4 IPv6 /32 blocks (3 for ISPs and one for Ministry of Comm.)
since 2004 and till now for ISPs no customers request for IPv6 (except the Universities/Research centers MPLS network),
as some claim that not all their software support IPv6 and also hardware and others waiting till the Internet community shift to IPv6 then
they will shift as they donít want to live in isolated islands.
>If RIRs were to encourage the use of NAT in such cases, the demand on the >remaining IPv4 free pool would be lessened, thereby extending the runway for >IPv6 deployment and (assuming NAT is the evil many say it is), encouraging >that deployment.
Please No NAT encourage, Philip can reply better than me for NAT advantages and disadvantages..
but Also NAT cost a lot of money as it requires special hardware cards (expensive one) in some routers to be able to do NATing
Randy Bush, How are you doing ? I hope you be in a very good health. I do benefit from IXP discussion in last AfriNIC meeting and
hope you could attend the next MENOG meeting, Itíll be a session for peering & IXP in the middle east.
>and we, the users, want to limit rir shopping, why? it may be the only bit if >market competition there is in the rir monopoly game.
>some may see one good thing about the iana ipv4 free pool run out as the
>creation of an actually visibly competitive market in address space.
I think, IMHO, we have to avoid RIR shopping to avoid RIR monopoly which will allow for exploitation of the situation,
by applying this proposal to equal & fair allocation of the remaining pool in conjunction with promoting IPv6 deployment.
>Most of the "transition" plans we have seen so far for this transition to an IPv6 >network pass through this intermediate stage of dual stack deployment. The >basic idea is that what is required for a V4 host initiate, maintain and close a >"conversation" with a V6 host and vice-versa goes well beyond the conventional >mode of packet protocol header substitution, and efforts to perform various >permutations of protocol header translators, DNS manipulations and application >level gateways all appear to have their dark and ugly side in terms of cost, >deployment complexity, service fragility and fractured application transparency.
>So, with help from various forms of tunneling support to bridge over any >protocol-specific transport continuity gaps, the basic idea of this transition is that >we enter an extended period where hosts need to use V4 to talk to V4 hosts >and V6 to talk to V6 hosts. As long as hosts first try the V6 handshake, then, so >goes the line of reasoning, we should see the traffic mix in this dual stack tend >to move to v6 as the legacy V4 infrastructure migrates to V6, and the dual stack >nature of the deployment means that dual stack hosts can fall back to V4 to >speak to V4 legacy infrastructure.