sig-policy October 2007

sig-policy@lists.apnic.net

9 participants
9 discussions

Re: [sig-policy] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
by Vincent Ngundi 31 Oct '07

31 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remarkable foresight! If I read the policy right, do you suggest that we retain the current IANA allocation policy and instead concentrate on life after the depletion of IPv4 in the IANA pool? Regards, - -Vincent On Oct 30, 2007, at 10:40 PM, Tony Hain wrote: > Policy Proposal Name: Cooperative distribution of the end of the > IPv4 > free pool. > > Author name: Tony Hain > email: alh-ietf(a)tndh.net > telephone: +1-425-468-1061 > organization: Cisco Systems > Proposal Version: 1.0 > Submission Date: Oct-30-2007 > Proposal type: new > Policy term: permanent > > Policy summary: > This policy will establish a process for RIR-to-RIR redistribution > of the > tail-end of the IPv4 pool, taking effect after the IANA Reserve is > exhausted. Each redistribution Allocation will be triggered by the > recipient > RIR depleting its reserve to a 30 day supply, and will result in up > to a 3 > month supply being transferred from the RIR with the longest > remaining time > before it exhausts its own pool. > > Policy statement: > At the point when any given RIR is within 30 days of depleting its > remaining > IPv4 pool, a survey will be taken of the other 4 to determine the > remaining > time before each of them exhausts their pool (including both member > use and > recent redistribution allocations to other RIRs). The one with the > longest > window before exhausting its pool will be designated as the source > RIR. The > recipient RIR will follow procedures for an LIR in the source RIR > region to > request a block that is expected to be sufficient for up to 3 > months, but is > no larger than 1/8th of the source RIR's remaining pool. At the > point where > no RIR can supply a block that is less than 1/8th of their > remaining pool > that will sustain the recipient RIR for 30 days, the recipient RIR > will > collect its requests each week, and forward those individual > requests to the > source RIR designated that week. > > Rationale: > This policy will establish a mechanism for the Allocation of IPv4 > address > blocks between RIR's, but will not go into effect until the IANA > pool has > been depleted. > > It is really bizarre to watch the maneuvering as the global RIR > community > grapples with 'fairness' of distributing the last few IANA Reserve /8 > blocks. On one level this just appears to be petty sibling rivalry, as > people are bickering over who gets the last cookie and whimpering > about > 'fairness'. At the same time, each RIR is chartered to look after the > interests of its membership so it is to be expected that they will > each want > to get as much as possible to meet the needs of their respective > membership. > Existing practice requires RIR's to acquire blocks from IANA, which > leads to > the current round of nonsense about optimal distribution of the > remaining > pool based on elaborate mathematical models. > > This globally submitted policy proposal attempts to resolve the > issue by > shifting to an RIR-to-RIR Allocation model after the IANA pool is > depleted. > This policy would effectively result in each RIR becoming a virtual > LIR > member of all of the other RIR's for the sole purpose of managing the > tail-end of the IPv4 pool. > > Timetable for implementation: Before 1/1/2009 > > > - -- KeNIC - The Kenya Network Information Center http://www.kenic.or.ke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHKPAChPC3Z8cZxdsRAsbpAJ9QCtMgO6fbPhg5pHtjJzWVt8kf+QCgqu70 77KKjoP4KqBpGKQ59JE0NV8= =k/EN -----END PGP SIGNATURE-----

1 0

Re: [sig-policy] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
by Leo Vegoda 31 Oct '07

31 Oct '07

Hi, We'd be grateful if people could stop cc'ing iana(a)iana.org when posting messages to this discussion as it generates unnecessary tickets in our ticketing system. Many thanks, Leo Vegoda

1 0

Monthly List Reminder
by noreply＠apnic.net 31 Oct '07

31 Oct '07

Dear Subscriber, This is the monthly reminder of subscription information for the sig-policy list, hosted at APNIC. For subscription information including how to un-subscribe go to http://mailman.apnic.net/mailman/listinfo/sig-policy Thank you for participating in this discussion. Kind Regards, List administrator

1 0

APNIC document review: APNIC member fee schedule
by Sunny 30 Oct '07

30 Oct '07

APNIC seeks final editorial comments on the following draft document: ------------------------------------------------------------------------ * APNIC member fee schedule: tiers, fees, and descriptions ------------------------------------------------------------------------ The document has been updated to reflect the decision made by the APNIC EC (Executive Council) on 11 October 2007 to implement the following fee change: - From 1 January 2008, APNIC fees will be set in Australian dollars, converting the US dollar fees into Australian dollars using the rate used in setting the 2007 APNIC budget of 1 AUD = 0.7889 USD. The draft document is available at: http://www.apnic.net/docs/drafts/draft-member-fee-schedule-v007.txt For more information on the fee changes, see: http://www.apnic.net/news/1026.html Nature of the document review ----------------------------- This is an editorial review only. Therefore, during the comment period, interested parties may: - object to the draft document on the grounds that it does not properly reflect the consensus decision reached in the Policy Review Process; - suggest improvements of any aspect of the document; - request that an additional call for comment be made to allow more consideration of substantial revisions. Deadline for comments ------------------- Your comments are requested by 23 November 2007. Please send your comments to the Policy SIG mailing list. Details at: http://www.apnic.net/community/lists-- -------------------------------------------------------------------- Srinivas Chendi email: sunny(a)apnic.net Policy Development Manager, APNIC sip: sunny(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3189 ____________________________________________________________________

3 4

APNIC document review: APNIC non-member fee schedule
by Sunny 30 Oct '07

30 Oct '07

APNIC seeks final editorial comments on the following draft document: ------------------------------------------------------------------------ * APNIC non-member fee schedule ------------------------------------------------------------------------ The document has been updated to reflect the decision made by the APNIC EC (Executive Council) on 11 October 2007 to implement the following fee change: - From 1 January 2008, APNIC fees will be set in Australian dollars, converting the US dollar fees into Australian dollars using the rate used in setting the 2007 APNIC budget of 1 AUD = 0.7889 USD. The document is available at: http://www.apnic.net/docs/drafts/draft-non-member-fees-v002.txt For more information on the fee changes, see: http://www.apnic.net/news/1026.html Nature of the document review ----------------------------- This is an editorial review only. Therefore, during the comment period, interested parties may: - object to the draft document on the grounds that it does not properly reflect the consensus decision reached in the Policy Review Process; - suggest improvements of any aspect of the document; - request that an additional call for comment be made to allow more consideration of substantial revisions. Deadline for comments ------------------- Your comments are requested by 23 November 2007. Please send your comments to the Policy SIG mailing list. Details at: http://www.apnic.net/community/lists -------------------------------------------------------------------- Srinivas Chendi email: sunny(a)apnic.net Policy Development Manager, APNIC sip: sunny(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3189 ____________________________________________________________________

1 1

arin on countdown
by Randy Bush 17 Oct '07

17 Oct '07

i am at the arin meeting. a few minutes ago, there was a vote similar to one we took in new delhi, on whether the approach of a count-down policy was supported for one or two /8s for each region at the end. the vote here at arin was overwhelmingly supportive of the proposals, 69:10. randy

1 0

Soliciting comments - IPv4 shared use address space
by Toshiyuki Hosaka 16 Oct '07

16 Oct '07

[chair hat off] Dear colleagues, I have translated the policy proposal idea (this is NOT a formal policy proposal to APNIC at this stage) as below, in order to seek your comments and feedback on this. This proposal was submitted to JPNIC open policy meeting this year, and I planned to introduce this idea at the last APNIC meeting but I couldn't because we have no time for informational presentations. This proposal is to designate two (2) /8s global address as "shared use" among APNIC LIRs for their internal use. If you are interested in, please read through and send your comments which the authors would highly appreciate. Thanks and best regards, toshi --- Toshiyuki Hosaka JPNIC --------------------------------------------------------------------- Title of proposal : Proposal to create IPv4 shared use address space among LIRs Author : Shirou Niinobe <nin(a)syce.net> Co-authors : Takeshi TOMOCHIKA Jiro YAMAGUCHI Dai NISHINO Hiroyuki ASHIDA Akira NAKAGAWA Toshiyuki HOSAKA Version : 1 Date : 7 August 2007 1. Introduction ---------------- This proposal is to create IPv4 shared use address space among LIRs in AP region, for the effective use of the IPv4 address space. 2. Summary of current problem ------------------------------ There is a case that a LIR gave up providing firewall or IP connectivity service behind NAT using RFC1918 address space for the security and the effecitive use of IPv4 addresses, because of the potential (possible) address space collision with the same RFC1918 addresses in an end-user's networks. Some LIRs apply (and receive) global IPv4 address allocation for the purpose of providing such a service. If we have this proposed shared address they do not have to apply global IPv4 addresses in such a case, and we can achieve effecitive use of IPv4 address. 3. Situation in other RIRs ---------------------------- There is no address space for this purpose (other than RFC1918 space). However the Internet Draft (Redesignation of 240/4 from "Future Use" to "Limited Use for Large Private Internets" draft-wilson-class-e-00.txt has been submitted on August 3, 2007. 4. Details of the proposal ---------------------------- 1) Create IPv4 shared use address space among LIRs in AP region. 2) The amount of the address space for this purpose is two (2) /8s. 3) LIRs in AP region can use its address space without any registration or application procedure to APNIC/NIRs, therefore global/regional address uniqueness is not guaranteed. 4) End-users cannot use this proposed address space, and should use existing RFC1918 address. Though LIRs can assign this proposed address to its customers. 5. Advantages and disadvantages of the proposal ------------------------------------------------- [Advantages]: - Effective use of global IPv4 address space will be promoted, as the largest LIRs will use this proposed address space rather than global addresses. - "Unnecessary (replaceable addresses to this proposed space)" IPv4 global address allocation/second opinion request can be diminished, therefore APNIC/NIR's wordload will be reduced. - IP connectivity service behind firewall or NAT can be provided easily by using this proposed address. - No need to apply global IPv4 addresses to APNIC/NIR. - LIRs can save APNIC/NIR membership fee (calculated based on the amount of address space allocated). - End-users can connect to the internet without any apllication of the global IPv4 addresses. - End-users can buy a service with different level of security provided using the global IPv4 address network. - LIRs still can provide IPv4 connectivity by using this proposed address space, even after the IPv4 address exhaustion. - Currently we do not have high-throughput IPv6-IPv4 translater for commercial use, and even if it is not available until the IPv4 address exhaustion LIRs still can provide IPv4 connectivity by dual- stucking with this proposed address space. - For those who cannot replace their equipment to IPv6-ready, especially in the LDC in Asia region, can provide IP connectivity by using this proposed address space. [Disadvantages]: - Global IPv4 addresses to be allocated to LIRs diminishes by Two (2) /8s. - LIRs needs to configure firewalls or NATs to use this proposed address space. Therefore global IPv4 addresses for these equipments are still needed for their external connectivity. 6. Effect on APNIC members ---------------------------- APNIC members will be able to use this proposed address space in accordance with their necessity. 7. Effect on NIRs ------------------- NIRs are expected to adopt the same policy at their discretion. -----------------------------------------------------------------------

3 5

prop-046: IPv4 countdown policy proposal - returning to mailing list for development
by Randy Bush 08 Oct '07

08 Oct '07

----------------------------------------------------------------------- prop-046: IPv4 countdown policy proposal ----------------------------------------------------------------------- This proposal was presented at the APNIC 24 Policy SIG but failed to reach formal consensus. Instead, it was decided to return the proposal to the mailing list for further development by the community. Proposal details ---------------- The proposal contains four main principles: 1. IANA to distribute a single /8 to each RIR when the IANA free pool hits 5 /8s. This date is defined as 'IANA Exhaustion Date'. 2. Each RIR community can define its own regional policy on how to distribute the remaining RIR free pool to LIRs after the IANA Exhaustion Date. 3. RIRs should provide an official projection on the IANA Exhaustion Date to the community. 4. RIRs should maintain the current address distribution criteria until the IANA Exhaustion Date. Discussion at APNIC 24 ---------------------- Because this proposal is similar to "prop-051: Global policy for the allocation of the remaining IPv4 address space", both proposals were discussed at the same time. Following the discussion, there was consensus on the following principles: - If there is to be a policy on the distribution of the last remaining IPv4 blocks to RIRs, then each RIR should be allocated one, not two, /8 blocks. - Discussion is needed on the policy under which the last /8 would be allocated in the APNIC region. Next steps ---------- We would like to hear your opinions on this proposal. Here are some questions that may help start discussion: - Is this proposal addressing a real need or problem? - What advantages are there to distributing the last remaining /8 blocks equally to the RIRs? - Are distribution policy changes needed for the final /8 delegated to APNIC by IANA? If yes, what changes do you think are needed? For more information on the policy proposal, see: http://www.apnic.net/policy/proposals/prop-046-v002.html Toshi, Jian, and randy

15 31

Re: [sig-policy] prop-046: IPv4 countdown policy proposal - returning to mailing list for development
by Raul Echeberria 02 Oct '07

02 Oct '07

Ray: a couple of comments: 1) A global policy can change what is stated in a former one. 2) I assume that no RIR will request more than 2 /8s. If somebody think/feel that our agreement on this point is not firm, so it will be necessary to propose a modification in the current global policy to limit the number of /8s requested to 2. Raúl At 09:45 a.m. 27/09/2007, Ray Plzak wrote: >Comment on drc comment 1 - There is nothing to >preclude an RIR from requesting to get what it >can justify, albeit that the RIRs have >informally said that they will only accept a max >of 2 /8s. Thus the following scenario is highly possible: > >IANA has 6 /8s remaining; RIR qualifies for 4 >/8s and decides to accept what it qualifies for; >what does IANA do with the remaining 2 /8s. > >Ray > > > -----Original Message----- > > From: sig-policy-bounces(a)lists.apnic.net [mailto:sig-policy- > > bounces(a)lists.apnic.net] On Behalf Of Izumi Okutani > > Sent: Thursday, September 27, 2007 8:30 AM > > To: David Conrad > > Cc: Randy Bush; sig-policy(a)lists.apnic.net > > Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal - > > returning to mailing list for development > > > > Hi, I've commented inline. > > > > David Conrad wrote: > > [...] > > > > >> 1. IANA to distribute a single /8 to each RIR when the IANA free > > >> pool hits 5 /8s. This date is defined as 'IANA Exhaustion Date'. > > > > > > Seems fine, although just to be explicit: > > > > > > Suppose there are 6 /8s remaining in the free pool. An RIR comes to > > > IANA and indicates they want another allocation. Current practice is > > > to allocate 2 /8s (if justified). IANA allocates the 2 /8s, leaving > > > 4 /8s. The obvious approach would be to allocate the remaining 4 /8s > > > to the other 4 RIRs. Is that the intent? > > right, thanks for clarifying. > > > > ... and a single /8 will be distributed to *5* RIRs if the RIR > > requested > > for 1 /8 instead of 2 /8s. > > > > (i.e.the requesting RIR gets 2 /8s in total, remaining four RIRs get 1) > > > > [...] > > > > >> 3. RIRs should provide an official projection on the IANA Exhaustion > > >> Date to the community. > > > > > > I'm not sure I see the point of having 5 different 'official' > > > projections. > > Not for job security for researchers though I did like the idea :-). > > > > We weren't actually expecting each RIR to come with their own > > projections, but for them to provide latest information based on > > projections already available. > > > > (which RIRs consider as reliable) > > > > >> 4. RIRs should maintain the current address distribution criteria > > >> until > > >> the IANA Exhaustion Date. > > > > > > Perhaps not too surprisingly, I disagree with this particular > > > clause. By analogy, we're driving down a road at 100 KPH and we see > > > a brick wall ahead of us. This clause requires us to put the car on > > > cruise control and close our eyes until we're about a meter from the > > > wall. > > > > > > What is the rationale for this clause? > > The idea is to ensure LIRs can receive IPv4 address space they need > > (based on justifications) until the last minute with minimum confusion. > > > > Going by road analogy, you increase confusion for drivers if you > > add extra rules changing from time to time, which may lead to > > accidents/traffic jam. Our intention is to avoid confusion by > > maintaining a consistent rule. > > > > > I would think a more rational approach would be for each RIR to > > > encourage IPv4 conservation using whatever policies make sense in > > > their region. > > That could be one approach, and this is the part we intend to discuss > > as > > regional policies after IED (presented as informational in APNIC24). > > > > >> - Is this proposal addressing a real need or problem? > > > > > > It isn't clear to me what problem this policy is attempting to > > address. > > When the remaining IANA pool is 5 /8s (or less), there are not enough > > blocks for all RIRs on consumption basis. > > > > You can't tell if your turn to request will come before the IANA pool > > runs out as it all depends on timing of your + other RIRs' request. > > > > This makes it more difficult for RIRs to plan distribution of the > > available pool in their regions. > > > > >> - What advantages are there to distributing the last remaining > > >> /8 blocks equally to the RIRs? > > > > > > Encouraging investment in developing countries by large ISPs in > > > developed countries? > > :-) I understand your point, but I imagine a single /8 won't attract > > too > > many investors. It probably won't last for more than few months to meet > > their needs. > > > > I know quite a number of people are concerned about this point, so I'd > > be interested to hear more details on what people see as an issue. > > > > > > izumi > > * sig-policy: APNIC SIG on resource management policy > > * > > _______________________________________________ > > sig-policy mailing list > > sig-policy(a)lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/sig-policy > >* sig-policy: APNIC SIG on >resource management policy * >_______________________________________________ >sig-policy mailing list >sig-policy(a)lists.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy October 2007