sig-policy January 2010

sig-policy@lists.apnic.net

16 participants
12 discussions

prop-080: Removal of IPv4 prefix exchange policy
by Randy Bush 09 Feb '10

09 Feb '10

Dear SIG members, The proposal, 'Removal of IPv4 prefix exchange policy', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals Randy, Ching-Heng, and Terence ________________________________________________________________________ prop-080-v001: Removal of IPv4 prefix exchange policy ________________________________________________________________________ Authors: Guangliang Pan <gpan(a)apnic.net> Version: 1 Date: 29 January 2010 1. Introduction ---------------- This is a proposal to remove the policy that currently permits resource holders to return three or more noncontiguous IPv4 address blocks and have the prefixes replaced with a single, larger, contiguous block. 2. Summary of current problem ------------------------------ Current APNIC policy[1] permits organizations to exchange three or more IPv4 prefixes and receive a single portable CIDR range of equal length or one bit shorter. Such exchanges may be requested without the requirement to document the efficiency of existing assignments and the usage rates. At the time this policy was introduced, it served a good purpose: it aimed to encourage return of noncontiguous small historical blocks to help reduce the size of the global routing table. However, as the remaining unallocated IPv4 addresses continue to be depleted, it will become increasingly difficult for APNIC to fulfil requests made under this prefix exchange policy. 3. Situation in other RIRs --------------------------- ARIN has two policies related to exchanging noncontiguous prefixes. For more information, see section 4.6, "Amnesty and Aggregation Requests" and section 4.7, "Aggregation Requests" in the ARIN Number Resource Policy Manual at: https://www.arin.net/policy/nrpm.html AfriNIC, LACNIC and RIPE have no similar prefix exchange policies. 4. Details of the proposal --------------------------- It is proposed that APNIC remove the policy that enables networks to exchange noncontiguous address blocks in exchange for a single, aggregated range. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - It removes a policy responsibility that APNIC will not able to fulfil during the IPv4 exhaustion period. - It prevents organizations taking advantage of the exchange policy to obtain more IPv4 addresses from APNIC by rounding up to the next bit without justification of the need. This is of particular concern as the remaining unallocated IPv4 pool becomes smaller. 5.2 Disadvantages - It prevents organizations willing to renumber and aggregate address blocks from being able to do so. However, given the fragmentation of the global routing table for other reasons during the IPv4 address exhaustion period, this is a minor disadvantage, that will have very little adverse impact on the size of the global routing table. 6. Effect on APNIC members --------------------------- This proposal will prevent APNIC members from exchanging noncontiguous prefixes for a single prefix. However, as noted in the "Disadvantages" section above, this inability to aggregate routes is not likely to have a significant impact on the size of the global routing table during the IPv4 address exhaustion period. 7. Effect on NIRs ------------------ NIR members will also be prevented from exchanging noncontiguous prefixes for a single prefix. 8. References --------------- [1] See: Section 11.4, "Renumbering to promote aggregation" in "Policies for IPv4 address space management in the Asia Pacific region", http://www.apnic.net/policy/add-manage-policy Section 7, "Historical prefix exchange policy" in "Policies for historical Internet resources in the APNIC Whois Database", http://www.apnic.net/policy/historical-resource-policies

5 5

prop-079: Abuse contact information (abuse-c)
by Randy Bush 04 Feb '10

04 Feb '10

Dear SIG members, The proposal, 'Abuse contact information (abuse-c)', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals Randy, Ching-Heng, and Terence ________________________________________________________________________ prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________ Author: Tobias Knecht <tk(a)abusix.org> Version: 1 Date: 29 January 2010 1. Introduction ---------------- This is a proposal to introduce a mandatory abuse contact field for objects in the APNIC Whois Database to provide a more efficient way for abuse reports to reach the correct network contact. 2. Summary of current problem ------------------------------ More and more network owners are starting to establish dedicated abuse handling departments. More and more network owners are also starting to exchange abusive behavior data with each other to help source networks identify internal abuse problems faster. Currently within the APNIC region, the growing amount of abuse reports are sent to tech-c or admin-c contacts as encouraged on the APNIC website.[1] This is because APNIC Whois Database currently has no specialised contact object for abuse departments. Instead, all abuse reports are sent to the "wrong" contact first. 3. Situation in other RIRs --------------------------- AfriNIC: There are currently no specific abuse-related fields implemented in the AfriNIC Whois Database. However, if the current proposal is successful in the APNIC region, the author plans to submit a similar proposal for the AfriNIC region. ARIN: An abuse-POC exists for Organizational ID identifiers.[2] LACNIC: An abuse-c exists for Autonomous System objects.[3] RIPE: An IRT (Incident Response Team) object can be linked to inetnum and inet6num objects.[4] 4. Details of the proposal --------------------------- It is proposed that APNIC create a mandatory abuse-c. The mandatory abuse-c field should: - Refer to the nic-handle of a person or role object that contains contact information for the appropriate dedicated abuse handling department - Be mandatory in the following objects: - inetnum - inet6num - aut-num - Appear only once in an object On implementation of this proposal, all existing objects in the database would have their "abuse-c" fields automatically populated with the nic-handle(s) referred to in the tech-c field. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Networks will be able to supply their own contact information for abuse departments. - Abuse complaints will not be sent to the "wrong" contact any more. - There will be more flexibility. Faster abuse handling will be possible leading to less abusive behavior. 5.2 Disadvantages - No disadvantages are foreseen. 6. Effect on APNIC members --------------------------- All APNIC members would need to add the mandatory abuse-c information upon this policy proposal's implementation. There are no negative effects, however, as the abuse-c fields would be populated with existing nic-handles on implementation of this proposal. 7. Effect on NIRs ------------------ It would be of benefit to the whole Internet community if NIRs were to implement a similar abuse contact scheme in their whois databases. But this would be another proposal. 8. References -------------- [1] Reporting abuse and spam http://www.apnic.net/reporting-abuse [2] Introduction to ARIN's Database https://www.arin.net/knowledge/database.html#abusepoc [3] LACNIC Policy Manual (v1.3 - 07/11/2009) http://lacnic.net/en/politicas/manual4.html [4] IRT Object FAQ http://www.ripe.net/db/support/security/irt/faq.html

12 24

Monthly List Reminder
by noreply＠apnic.net 31 Jan '10

31 Jan '10

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

Timeline for policy proposals at APNIC 29
by Sam Dickinson 27 Jan '10

27 Jan '10

Dear SIG members The deadline for submitting policy proposals to the APNIC Secretariat for discussion at APNIC 29 was yesterday, 27 January 2010. As first used in the policy proposal timeline for APNIC 26, there is a one-week buffer between the deadline for submitting policy proposals to the Secretariat and the deadline for Chairs to send policy proposals to the SIG mailing list. This one-week buffer gives the Secretariat time to help proposal authors conform to the policy proposal template and to help with any language issues that may arise. All policy proposals will be sent to the appropriate SIG mailing list by the end of 3 February 2010. This is the date that the minimum four-week discussion period before APNIC 29 begins. Regards -- _____________________________________________________________________ Samantha Dickinson email: sam(a)apnic.net Senior Policy Specialist, APNIC sip: sam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

1 0

Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space tofacilitate IPv6 deployment' Comments
by Terence Zhang YH(CNNIC) 25 Jan '10

25 Jan '10

Andy, > If we adopt this new proposal which extends the IPv6 transition requirements from the originally proposed /10 to >the whole of the final /8 and we don't consider the allocation size we could end up with a policy that's radically >different from the ARIN and RIPE policies. > I don't think that's a problem if we make a conscious choice in that way but I don't think it's good that we end up > there by accident or omission. We have considered allocation size very carefully in this policy proposal, in prop-078 version 1, our proposed allocation size is /24, we didn't propose smaller size because we do not want to create longer prefixes in the Internet routing table just because of this policy. Based on knowledge of current Internet's route filtering culture, we believe /24 is the most generally accepted longest prefix currently. But people raised concern that /24 is too small for large organization's real use, that's why we removed that proposed allocation size in version 2, and keep it consistent with the final /8 (Which is APNIC's minimum allocation size) We do believe it is possible routing practices will change when we are running out of IPv4, we may have to accept small routes in the future. > My preference is to adopt something like the ARIN policy with a /10 set aside for IPv6 transition work with >the remaining 3 /10s used for business as usual or other policy initiatives we might agree to in future. > That's exactly what prop-078 version 1 proposed. Here is the summary of the key points of prop-078 version1 and version 2 , you can see the different: Version 1: Reserve a /10 from the final /8, in order to receive a allocation or assignment from that /10: 1. The applicant must demonstrate immediate IPv6 deployment needs 2. The applicant must either have existing IPv6 addresses or valid application for IPv6 addresses. 3. The applicant can apply for subsequent allocation if their utilization rate is high enough Version 2: In order to receive an allocation or assignment under the final /8 policy: 1. The applicant must demonstrate IPv6 transition plan or IPv6 deployment needs 2. The applicant must either have existing IPv6 addresses or valid application for IPv6 addresses. 3. This requierment is not applied to the reserved /16 In short, version 1 has /24 (or minimum) allocation size and allow subsequent allocation, which is similar to ARIN & RIPE's policy(proposal), version 2 is simple, just add IPv6 requirement to the final /8 policy, there for has /22 (or minimum) allocation size and no subsequent allocation. We will see which direction the community wants to go, at least I feel that most people wish to use part (or all ) of the final /8 for IPv6 transition. Best Regards Terence Zhang CNNIC

1 0

Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments
by Terence Zhang YH(CNNIC) 24 Jan '10

24 Jan '10

Dear all, Thanks for your comments. I think if we are doing /27 allocation, a LIR needs a /24 may have multiple non-contiguous /27, even if ARIN specify sparse allocation and require re-numbering, it may still hard to make sure those small blocks are contiguous and can be a summarized route. Also re-numbering maybe too complicated. That's what I mean 'create too many routes'. I don't imply that's the main cause of the increase of the global routing table size. I understand it is possible routing practices will change when we are running out of IPv4, We may have to accept small routes in the future. if longer route prefixes are more generally accepted, or a smaller minimum allocation size takes effect, we can certainly reduce the size of allocation under this policy to suit future needs. But right now we are doing these based on current best pratice. Best Regards Terence ----- Original Message ----- From: "Seiichi Kawamura" <kawamucho(a)mesh.ad.jp> To: "Randy Bush" <randy(a)psg.com> Cc: "Terence Zhang YH" <zhangyinghao(a)cnnic.cn>; <sig-policy(a)apnic.net> Sent: Thursday, January 21, 2010 4:17 PM Subject: Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I didn't understand this. > We may have to accept small routes, > but why would this "create" more routes? > > Regards, > Seiichi > > > Randy Bush wrote: >>> I think an allocation size </24 may creat too many routes in the >>> global routing table >> >> why do you think this? could you explain? >> >> i suspect that the routing table size is driven mostly by multi-homing >> with some traffic engineering. >> >> randy >> * 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 >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAktYDa0ACgkQcrhTYfxyMkKmawCeOPKfaVvVw6mbB87x//QVc4xk > 5IkAniua6zVnEs5b1t0KahsVzYuql/Ey > =Rthc > -----END PGP SIGNATURE-----

4 3

Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments
by Terence Zhang YH 21 Jan '10

21 Jan '10

Andy, Thanks for your comments. I understand ARIN & RIPE has /28-/24 or /27 (propose) allocation size and they allow subsequent allocation. I think an allocation size </24 may creat too many routes in the global routing table, we do not want to create longer prefixes in the Internet routing table just because of this policy; and based on the knowledge of current Internet's route filtering culture, we believe /24 is the most generally accepted longest prefix currently. That's why we proposed /24 allocation size in version1, now taken into account people's worries about /24 is too small and subsequent allocations are not necessary and it is too complicated... we think it's better to make it simple, just propose adding IPv6 requirements in the final /8 allocations. Regards Terence ----- Original Message ----- From: "Andy Linton" <asjl(a)lpnz.org> To: <sig-policy(a)apnic.net> Sent: Thursday, January 21, 2010 4:41 AM Subject: Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments > Terence, > > I'd also like to ask about minimum and maximum allocation sizes. The > ARIN policy has a /28 minimum and a /24 maximum for the /10 they plan to > set aside. The RIPE policy proposes that the final /8 should use a /27 > minimum which they note is 'downscaling the current minimum allocation > size /21'. > > Do you envisage such changes to APNIC policy in conjunction with your > proposal? > > andy > * 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

3 2

Re: [sig-policy] Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments
by Andy Linton 20 Jan '10

20 Jan '10

Terence, I'd also like to ask about minimum and maximum allocation sizes. The ARIN policy has a /28 minimum and a /24 maximum for the /10 they plan to set aside. The RIPE policy proposes that the final /8 should use a /27 minimum which they note is 'downscaling the current minimum allocation size /21'. Do you envisage such changes to APNIC policy in conjunction with your proposal? andy

1 0

Prop-78 'Reserving /10 IPv4 address space to facilitate IPv6 deployment' Comments
by Terence Zhang YH 20 Jan '10

20 Jan '10

Dear all, After we reviewed the major concerns raised during the discussion in APNIC 28 about prop-078 'Reserving /10 IPv4 address space to facilitate IPv6 deployment'. We have made some changes and come up with a revised proposal. We are seeking your help for further feedback regarding our draft proposal, so we can revise it further before we submit the new version. We summarize the major concerns raised in APNIC 28 as follow: - Doubt that a /24 is adequate for large LIR' IPv6/IPv4 internetworking - Subsequent allocations are not neccessary - Prop-078 serves similiar purpose with the final /8 policy, and seems dupicated After carefull review of those comments, we admit that prop-078 has similiar purpose with the final /8, but we don't think it's duplicated. The major difference is prop-078 specifically require the applicant to demonstrate IPv6 deployment needs. We understand most people gave feedback in APNIC 28 assumed that the final /8 should be used for IPv6 transition. But the policy doesn't explicitly require that. After taken all the above into account, we come up with a draft revision. The main point of the new version is : In order to make the message more clear, the proposal specifically requires IPv6 deployment needs or transition plan in final /8 allocations or assignments. It is proposed that in order to receive an allocation or assignment under the final /8 policy: 1. The applicant must demonstrate IPv6 transition plan or IPv6 deployment needs, especially the needs for IPv6 to IPv4 internetworking. 2. The applicant must either have existing IPv6 addresses or valid application for IPv6 addresses. 3. The applicant must meet the requirements specified in the current final /8 policy The major changes to prop-078 version 1 is: -Extent the reserved /10 block to the whole /8 -The allocation size conform to the final /8 allocation size -Eliminate subsequent allocation The major changes to the final /8 policy is: Requiring IPv6 deployment needs or transition plan in final /8 allocations or assignments The draft is attached at the bottom of this email, we appreciate your comments and advices. Thanks & Regards Terence,Jane & Wendy CNNIC _______Prop-078 Version 2 Draft_______________________ Requiring IPv6 deployment needs or transition plan in final /8 allocations or assignments 1. Introduction ---------------- This policy proposal seeks to supplement the final /8 policy, by requiring the applicant to demonstrate immediate IPv6 deployment needs, which ensures LIRs use the final /8 for IPv6 transition. The intention is to stimulate native IPv6 deployment as much as possible, while supporting the need for future networks to communicate with the IPv4 world. 2. Summary of the current problem ---------------------------------- The Internet will use IPv4 for many years during the adoption of IPv6, during this period, LIRs will need to connect to the IPv4 Internet while they deploy services using the IPv6 Internet. The final /8 policy has the objective to assist the LIR to participate in the IPv4 Internet while they deploy services using the IPv6 Internet,but the final /8 policy does not specifically require LIRs to demonstrate IPv6 deployment needs or transition plan. A /22 allocation is still possible for some small LIRs to grow IPv4 services. To make the message clear and ensure IPv4 space will remain available for LIRs' IPv6 deployment. This policy proposal seeks to ensure the final /8 is used in IPv6 transition 3. Situation in other RIRs --------------------------- ARIN has adopted a similar policy: 2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment https://www.arin.net/policy/proposals/2008_5.html RIPE has similar policy proposal under discussion: 2009-04: IPv4 Allocation and Assignments to Facilitate IPv6 Deployment http://www.ripe.net/ripe/policies/proposals/2009-04.html AfriNIC and LACNIC currently have no similar policies or proposals. 4. Details ----------- It is proposed that in order to receive an allocation or assignment under the final /8 policy: 1. The applicant must demonstrate IPv6 transition plan or IPv6 deployment needs, especially the needs for IPv6 to IPv4 internetworking. 2. The applicant must either have existing IPv6 addresses or valid application for IPv6 addresses. 3. The applicant must meet the requirements specified in the current final /8 policy 5. Pros/Cons ------------- 5.1 Advantages: - This proposal ensures LIR use the final /8 in IPv6 transition, which supporting the need for future networks to communicate with the IPv4 world. 5.2 Disadvantages: - Some LIRs cannot receive allocations or assignment from the final /8 just for growing IPv4 services. 6. Effect on APNIC members --------------------------- This proposal requires APNIC LIRs (existing and new) to demonstrate IPv6 deployment needs or transition plan to receive IPv4 allocation or assignment from the final /8. 7. Effect on NIRs ------------------ Same as effect on APNIC members 8. References ------------- [1] See section 9.10, "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/policy/add-manage-policy.html#9.10

1 0

Reminder: Policy proposal deadline for APNIC 29
by Randy Bush 14 Jan '10

14 Jan '10

Dear colleagues If you have an idea for a policy proposal that you'd like the community to discuss at APNIC 29, please submit it before the proposal deadline: 27 January 2010 You can submit your proposal in either of two ways: 1. Use the online form at: http://www.apnic.net/policy/proposals/submit-proposal 2. Send your proposal in ASCII TEXT format to <policy(a)apnic.net>. If you need help, please feel free to contact <sig-policy-chair(a)apnic.net>. More information ---------------- APNIC's policy development process is explained at: http://www.apnic.net/community/policy/process You can view current and past policy proposals at: http://www.apnic.net/policy/proposals You can learn more about APNIC 29 at: http://meetings.apnic.net We look forward to seeing you in Kuala Lumpur! APNIC Policy SIG Chairs Randy, Ching-Heng, and Terence

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy January 2010