sig-policy April 2006

sig-policy@lists.apnic.net

5 participants
6 discussions

Policy Proposal for End Site allocation policy for IPv6
by Geoff Huston 05 Sep '06

05 Sep '06

Submitters Names: Randy Bush, IIJ, Geoff Huston, APNIC SIG: Policy Title: End Site Allocation policy for IPv6 Introduction: This policy proposal proposes to amend the APNIC IPv6 address allocation policies regarding the definition of the default size of End Site assignments, and specify the calculation of address utilization efficiency relating to subsequent allocation criteria. Rationale: The current IPv6 Address Allocation and Assignment Policy (APNIC-089) indicates that end sites should be allocated a /48 as a uniform allocation states unit. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency is to be made according to a /56 size. For the purpose of evaluating LIR and End Site IPv6 IP address allocation efficiency using the HD ratio, the starting bit position used in the calculation is to be bit position 56. This measure, if undertaken generally by all RIRs, and assuming that further measures are undertaken by the addressing community regarding the HD ratio to a larger value, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years during which period no further allocation policy changes would be anticipated to encompass a relatively encompassing diversity of future IPv6 deployment scenarios. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-… Situation in other RIRs: A comparable policy proposal as been submitted to RIPE and ARIN Details: End User Allocations: End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). ISPs and LIRs: ISPs and LIRs may chose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. APNIC: APNIC will amend its IPv6 allocation criteria to reflect the use of an HD ratio with the size calculation starting at bit position 56 as the unitary metric in the calculation of the ISP or LIR's end site allocation efficiency. Appendix - References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations-00.… 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00…

4 13

Policy discussion updates amongst RIRs
by Save Vocea 21 Apr '06

21 Apr '06

________________________________________________________________________ Policy discussion updates amongst the RIRs – April 2006 ________________________________________________________________________ This is to share with the APNIC community the policy proposals that were discussed at last week's ARIN XVII meeting. The following three proposals achieved consensus and have now entered into last call: - 2005-9: 4-Byte AS Number This proposal details a set of actions and associated dates for RIR AS number allocation policies to assist in an orderly transition to use of the 4-byte AS number space. This proposal will be discussed in upcoming meetings of RIPE, LACNIC, and AfriNIC. The proposal has also been adopted by consensus at APNIC 21. APNIC’s deadline for comment for this proposal [prop-032-v002] is 12 May 2006. For more information, see: http://www.apnic.net/docs/policy/proposals/prop-032-v002.html - 2005-1 Provider independent IPv6 assignments for end sites Proposal for ARIN to make direct IPv6 portable assignment with minimum size of /48 to organizations for multihoming purposes. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation growth of at least a /44. - 2005-8 Proposal to amend ARIN IPv6 assignment and utilisation size Proposal to amend ARIN IPv6 assignment and utilisation size proposed that many references to ‘/48’ will be replaced by 'End site assignment'. The exact size of the assignment is a local decision for the LIR or ISP to make. i.e. they can decide on a minimum value of /64 and up to a maximum of /48 assignment sizes. APNIC has a similar proposal now under discussion, [prop-033-v001]: http://www.apnic.net/docs/policy/proposals/prop-033-v001.html Three proposals received consensus to be revised and discussed further in ARINs public policy mailing list, ppml. These were: - 2006-1 Residential customer privacy - 2006-2 Micro-allocations for internal infrastructure - 2006-3 Capturing originations in templates Two proposals were abandoned, having failed to reach consensus: - 2006-4: IPv6 Direct PI assignments for end sites - 2006-5: IPv4 Micro-allocations for anycast services More information ---------------- Details of all the above proposals can be found at: http://www.arin.net/policy/proposals/proposal_archive.html All postings to ppml are archived at: http://lists.arin.net/pipermail/ppml/ Regards -- Savenaca Vocea, Policy Development Manager, <save(a)apnic.net> Asia Pacific Network Information Centre http://www.apnic.net ph/fx +61 7 3858 3100/99

1 0

Re: [ppml] PI addressing in IPv6 advances in ARIN
by JORDI PALET MARTINEZ 18 Apr '06

18 Apr '06

Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6(a)lists.apnic.net So, if you aren't subscribed in the global-v6(a)lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> > Responder a: <jordi.palet(a)consulintel.es> > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops(a)ops.ietf.org" <v6ops(a)ops.ietf.org>, "ppml(a)arin.net" > <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> > Conversación: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong <owen(a)delong.com> >> Responder a: <owen(a)delong.com> >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: <jordi.palet(a)consulintel.es>, "v6ops(a)ops.ietf.org" >> <v6ops(a)ops.ietf.org>, >> "ppml(a)arin.net" <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> <jordi.palet(a)consulintel.es> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 1

Comment period for prop-020-v001
by Kenny Huang 18 Apr '06

18 Apr '06

________________________________________________________________________ Abandoned: [prop-020-v001] "Application of the HD ratio to IPv4" ________________________________________________________________________ Dear colleagues Following the four-week discussion period for the proposal, "Application of the HD ratio to IPv4", I am concluding that the community has no interest in moving this proposal forward. Therefore, I formally declare this proposal to be abandoned. Summary of four week discussion ------------------------------- The final comment period for the proposal ended on 14 April 2006. During the comment period, there were three commments made about the proposal: - Two comments in favour of abandoning the proposal. - One analysis of the impact of the HD ratio on projected lifetimes of the unallocated IPv4 address pool. There were no comments in favour of this proposal. For a detailed history of this proposal, see: http://www.apnic.net/docs/policy/proposals/prop-020-v001.html Best regards Kenny Huang, Toshiyuki Hosaka , Eugene Li Chair/co-Chair, Policy SIG

1 0

Global IPv6 PI policy proposal
by JORDI PALET MARTINEZ 14 Apr '06

14 Apr '06

Please, use global-v6(a)lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ³Portable IPv6 Assignments for End-User-Organizations² if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet(a)consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren¹t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that¹s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don¹t opt to PI with this policy is because they don¹t need it, so they aren¹t put in an unfair situation. Those that don¹t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don¹t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ³temporarily² of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ³transition² period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Open call for ASO ICANN Board seat nominations closes April 4
by APNIC Secretariat 03 Apr '06

03 Apr '06

[Sent on behalf of the Address Supporting Organization] -------------------------------------- ASO ICANN Board nominations close soon -------------------------------------- In compliance with the ASO MoU and ICANN bylaws the Address Council hereby calls for nominations to the ICANN Board to fill the ASO seat currently held by Mouhamet Diop, whose term expires in June 2006. This nomination period closes on 4 April 2006. Nominations may be submitted by anyone by sending email to: <nominations(a)aso.icann.org> Nominations must include the following information: - Full name of person being nominated - Contact email address for person being nominated - Contact telephone number (if available) for person being nominated - Full name of the person making the nomination - Contact email address for the person making the nomination - Contact telephone number of the person making the nomination Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures, as documented on the ASO website. ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ______________________________________________________________________

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy April 2006