sig-policy February 2010

sig-policy@lists.apnic.net

23 participants
34 discussions

Monthly List Reminder
by noreply＠apnic.net 28 Feb '10

28 Feb '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

Re: [sig-policy] prop-081: Eligibility for assignments from the final /8
by Terence Zhang YH(CNNIC) 26 Feb '10

26 Feb '10

Disclaimer: the comments below reflect the views of the proposal authors and have NO link to co-chair's opinion about this proposal ----------------------------------------------------------------------------------------- Hi, Terry, >>> Like it or not, the current APNIC assignment policy and the transfer policy allow /24 delegations. >> In terms of the final /8, I do not believe this aspect of APNIC policies for transfers and >> assignments should be replicated. >> The facts are, unless some one propose to change, the /24 minimum transfer size >> will remain in effect in the final /8 phase. >I'm not seeing that as an issue.. Are you worried that those unscrupulous users of IP address > space would take a /22 from the last /8 policy and the transfer it in chunks of /24 to people? > Please clarify why the /24 transfer size in the final /8 is a problem? I support /24 transfer size very much, Sir. Since you expressed strong objection to /24 allocation size and don't want this 'be replicated' in the final /8, so I was just wondering if you will propose to change /24 the minimum transfer size. >>Sounds like you are more cautious about the costs than me, do you think matching a block >> of IPv6 addresses to every IPv4 account holder for free will also cost $$ and number resources? >I'm realistic about costs, efforts, benefits, and desired outcome. Me too. > But do remember that the motivation for that policy was about IPv6 deployment. Transition is also a important part of deployment. >What I am suggesting is that the industry will get far better use of those /22 allocations in the > last /8 as for use in v6 transition without being chopped up and micromanaged into /24 slices. It makes no sense to keep the last /8 immune from /24 delegations, while the dozens of /8 allocated before the last /8 allowing /24 assignments. Regards Terence

5 7

prop-079-v003: Abuse contact information
by Randy Bush 24 Feb '10

24 Feb '10

Dear SIG members Version 3 of the proposal 'Abuse contact information' 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. Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals This new version of the proposal reflects feedback from the community received on the Policy SIG mailing list: - The wording of section 1 has been simplified. - The "Summary of the current problem" in section 2 has been rewritten. - Section 4.1 has been reworded slightly. - The last bullet point in section 5.1 has been rewritten. - Section 5.2 refers to the discussion on whois data accuracy that has taken place on the Policy SIG list. We encourage you to express your views on the proposal: - Do you support or oppose 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? Randy, Ching-Heng, and Terence ________________________________________________________________________ prop-079-v003: Abuse contact information ________________________________________________________________________ Author: Tobias Knecht <tk(a)abusix.org> Version: 3 Date: 24 February 2010 1. Introduction ---------------- This is a proposal to introduce a mandatory reference to IRT objects in the inetnum, inet6num and aut-num objects in the APNIC Whois Database. The proposal aims provide a more accurate and efficient way for abuse reports to reach the correct network contact. 2. Summary of current problem ------------------------------ Network owners increasingly operate dedicated abuse handling departments, distinct from the basic operations department. More and more network owners and other institutions are also starting to exchange data about abusive behavior with each other, to more quickly allow networks to identify internal abuse, external abuse, and other security problems. 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] These addresses are used because the APNIC Whois Database currently has no mandatory, specialised contact object for abuse departments. Instead, all abuse reports are sent to contact that has broader responsibilities or different responsibilities. 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 aut-num, inetnum and inet6num objects.[3] RIPE: An optional IRT (Incident Response Team) object can be linked to inetnum and inet6num objects.[4] If the current proposal is successful in the APNIC region, the author plans to submit a similar proposal for the RIPE region. 4. Details of the proposal --------------------------- It is proposed that APNIC: 4.1 Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects. In terms of implementing a mandatory IRT reference, it is suggested that this be part of two established actions: - The next time an organization attempts to update an existing inetnum, inet6num or aut-num object - When new inetnum, inet6num or aut-num objects are added to the database 4.2 Have a mandatory abuse-mailbox field in the IRT object. 4.3 Delete abuse-mailbox fields in all objects that do not refer to an IRT, and delete the trouble field everywhere starting 2011. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Networks will be able to supply their own, direct contact information for abuse departments. - Abuse complaints will not be sent to the "wrong" contact any more. - This permits greater administrative and operational flexibility, and faster abuse handling will be possible. 5.2 Disadvantages - Introducing a mandatory reference to the IRT Object will establish a new object. This object, like all other existing objects, will face the data accuracy problem. This proposal aims to address the issue of a missing place for abuse contact information and will not improve data accuracy in the whois database. Data accuracy will be part of another proposal that is already being discussed on the policy mailing list. 6. Effect on APNIC members --------------------------- There will be no immediate affect for APNIC members with existing resource registrations already in the APNIC Whois Database. However, members will need to add a reference to the mandatory IRT object in the following situations: - The first time members attempt to update an existing inetnum, inet6num or aut-num object - When members add new inetnum, inet6num or aut-num objects 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] There is no formal documentation on abuse-c in inetnum and inet6num objects, but for documentation on the abuse-c in ASN records, see 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

2 1

Re: [sig-policy] prop-081: Eligibility for assignments fromthe final /8
by Terence Zhang YH(CNNIC) 24 Feb '10

24 Feb '10

Disclaimer: the comments below reflect the views of the proposal authors and have NO link to co-chair's opinion about this proposal ----------------------------------------------------------------------------------------- The final /8 provides 16384 allocations with /22 size, we currently have only about 2200 members, consider each account holder only get one allocation from the final /8, there is no reason to beleive we should exclude Critical infrastructure/IXP/Multihoming applicants from the final /8 because of lacking IPv4 space. They only take up one share from the 16384 delegations as all LIRs do. Regards Terence CNNIC ----- Original Message ----- From: "Seiichi Kawamura" <kawamucho(a)mesh.ad.jp> To: "Terence Zhang YH(CNNIC)" <zhangyinghao(a)cnnic.cn> Cc: "Randy Bush" <randy(a)psg.com>; "Izumi Okutani" <izumi(a)nic.ad.jp>; <sig-policy(a)lists.apnic.net> Sent: Wednesday, February 24, 2010 10:45 AM Subject: Re: [sig-policy] prop-081: Eligibility for assignments fromthe final /8 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Terence Zhang YH(CNNIC) wrote: >> Disclaimer: the comments below reflect the views of the proposal authors and >> have NO link to co-chair's opinion about this proposal >> ----------------------------------------------------------------------------------------- >> >> Critical infrastructure/IXP/Multihoming applicants may not be able to justify a /22 requirement, >> currently half of the assignments made in AP region is /24, besides that, the criterias for >> allocations and assignments are some how different. >> >> We currently allow allocations and assignments, but prop-062 only allow allocations. >> >> We are not trying to fulfil every needs, just try to be fair and consistent. > > Fairness is a good idea, but > you are looking at specific needs. > The current final /8 policy to me seems > the most fair. > > IMHO consistency ends when that last /8 is > handed to RIRs. No more IPv4. nada. > > Regards, > Seiichi > >> >> >> Regards >> >> Terence >> CNNIC >> >> >> >> ----- Original Message ----- >> From: "Randy Bush" <randy(a)psg.com> >> To: "Izumi Okutani" <izumi(a)nic.ad.jp> >> Cc: <sig-policy(a)lists.apnic.net> >> Sent: Tuesday, February 23, 2010 9:52 PM >> Subject: Re: [sig-policy] prop-081: Eligibility for assignments fromthe final /8 >> >> >>> < chair hat = off > >>> >>>> I think it could be possible that there will be needs for these >>>> assignments if there is a new gTLD/ccTLD set up as critical >>>> infrastructure, and we could also have new IXPs or multi-homed >>>> networks. We constantly make 3-4 assignments/year for these use >>>> within JP. >>> ixps, multi-homed networks, etc. are precisely the users expected for >>> prop-062. so why is the final /8 olicy not satisfactory for them all >>> of a sudden? >>> >>> let us remember, we will be out of ipv4 space. we will simply not be >>> able to fulfil every need. >>> >>> 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 >> * 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) > > iEYEARECAAYFAkuEkq4ACgkQcrhTYfxyMkIWrQCfc1t8jqBKLbMzTuwKGfhXf4S3 > g0wAni2wMCuamrkifCfmXQjDddAx7rWw > =mKwl > -----END PGP SIGNATURE-----

2 1

Re: [sig-policy] prop-081: Eligibility for assignments fromthe final /8
by Terence Zhang YH(CNNIC) 24 Feb '10

24 Feb '10

Disclaimer: the comments below reflect the views of the proposal authors and have NO link to co-chair's opinion about this proposal ----------------------------------------------------------------------------------------- Critical infrastructure/IXP/Multihoming applicants may not be able to justify a /22 requirement, currently half of the assignments made in AP region is /24, besides that, the criterias for allocations and assignments are some how different. We currently allow allocations and assignments, but prop-062 only allow allocations. We are not trying to fulfil every needs, just try to be fair and consistent. Regards Terence CNNIC ----- Original Message ----- From: "Randy Bush" <randy(a)psg.com> To: "Izumi Okutani" <izumi(a)nic.ad.jp> Cc: <sig-policy(a)lists.apnic.net> Sent: Tuesday, February 23, 2010 9:52 PM Subject: Re: [sig-policy] prop-081: Eligibility for assignments fromthe final /8 >< chair hat = off > > >> I think it could be possible that there will be needs for these >> assignments if there is a new gTLD/ccTLD set up as critical >> infrastructure, and we could also have new IXPs or multi-homed >> networks. We constantly make 3-4 assignments/year for these use >> within JP. > > ixps, multi-homed networks, etc. are precisely the users expected for > prop-062. so why is the final /8 olicy not satisfactory for them all > of a sudden? > > let us remember, we will be out of ipv4 space. we will simply not be > able to fulfil every need. > > 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

2 1

Policy-related events in KL
by Randy Bush 23 Feb '10

23 Feb '10

Dear SIG members At the upcoming APNIC 29/APRICOT 2010 conference in Kuala Lumpur, there are a few events which may be of interest to Policy SIG members: - APNIC Policy Development Process BoF: How do we facilitiate wider and better discussion? 17:30 - 19:00, Tuesday 2 March 2010 - IPv6 Address Management and ITU: Is an "additional parallel structure" required? 14:00 - 15:30, Wednesday 3 March 2010 - APNIC Policy SIG 16:00 - 17:30, Wednesday 3 March 2010 11:00 - 12:30 & 14:00 - 15:30, Thursday 4 March 2010 For detailed information on these events, see the APNIC 29 website at: http://meetings.apnic.net/29

1 0

Re: [sig-policy] prop-081: Eligibility for assignments from the final /8
by Terence Zhang YH(CNNIC) 23 Feb '10

23 Feb '10

Disclaimer: the comments below reflect the views of the proposal authors and have NO link to co-chair's opinion about this proposal ----------------------------------------------------------------------------------------- Hi, Izumi, Thanks for your comments on this proposal. We have 5-10 assignment cases every year in the past 5 years within CN, and currently there are about 1620 assignments in total in the AP region, averagely about 100 assignment cases each year in the AP region. With IDN ccTLD and ongoing discussion of more open gTLD policy, we can expect dozens of gTLD will be created in the next few years. I am not trying to argue the needs for new gTLD/ccTLD, IXPs or multi-homed will be increasing, but it's certain that the needs will not diminish. Regards Terence Zhang CNNIC ----- Original Message ----- From: "Izumi Okutani" <izumi(a)nic.ad.jp> To: "Terry Manderson" <terry(a)terrym.net> Cc: "Terence Zhang YH(CNNIC)" <zhangyinghao(a)cnnic.cn>; <sig-policy(a)lists.apnic.net> Sent: Tuesday, February 23, 2010 10:07 AM Subject: Re: [sig-policy] prop-081: Eligibility for assignments from the final /8 > Hi all, > > > I think it could be possible that there will be needs for these > assignments if there is a new gTLD/ccTLD set up as critical > infrastructure, and we could also have new IXPs or multi-homed networks. > We constantly make 3-4 assignments/year for these use within JP. > > Then again, if the numbers are not very big, may be it can accomodated > within the /16 reserved for unexpected future use. > > Terrence, do you have an idea on how many of these assignments we > should expect? > > > izumi/JPNIC > > Terry Manderson wrote: >>>> I'm not seeing that as an issue.. Are you worried that those unscrupulous users of IP address >>>> space would take a /22 from the last /8 policy and the transfer it in chunks of /24 to people? >>>> Please clarify why the /24 transfer size in the final /8 is a problem? >>> I support /24 transfer size very much, Sir. Since you expressed strong objection to /24 allocation >>> size and don't want this 'be replicated' in the final /8, so I was just wondering if you will >>> propose to change /24 the minimum transfer size. >> >> Transfers are a different beast to the final /8 allocation. Don't you see that? >> >>>> What I am suggesting is that the industry will get far better use of those /22 allocations in the >>>> last /8 as for use in v6 transition without being chopped up and micromanaged into /24 slices. >>> It makes no sense to keep the last /8 immune from /24 delegations, while the dozens of >>> /8 allocated before the last /8 allowing /24 assignments. >> >> >> What I now think is keeping this thread going makes little sense. There appears to be no support for this proposal. >> >> Terry >> >> >> * 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 > >

1 0

prop-082-v002: Removing aggregation criteria for IPv6 initial allocations
by Randy Bush 23 Feb '10

23 Feb '10

Dear SIG members Version 2 of the proposal 'Removing aggregation criteria for IPv6 initial allocations' 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. Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals This new version of the proposal reflects feedback from the community received on the Policy SIG mailing list: - The wording of section 4.1 has been changed to more closely reflect the current policy. - The first advantage listed in section 5.1 has been amended following community feedback. - Effects on APNIC members and NIRs have been added to sections 6 and 7. We encourage you to express your views on the proposal: - Do you support or oppose 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? Randy, Ching-Heng, and Terence ________________________________________________________________________ prop-082-v002: Removing aggregation criteria for IPv6 initial allocations ________________________________________________________________________ Author: Tomohiro Fujisaki <fujisaki(a)syce.net> Co-authors: Akira Nakagawa Fuminori Tanizaki Masaru Akai Toshio Tachibana Version: 2 Date: 24 February 2010 1. Introduction ---------------- This is a proposal to remove the aggregation requirement from the IPv6 initial allocation policy. 2. Summary of the current problem ---------------------------------- The initial IPv6 address allocation criteria requires that LIRs: "Plan to provide IPv6 connectivity to organizations to which it will make assignments, by advertising that connectivity through its single aggregated address allocation."[1] However, there is no similar aggregation requirement in either the criteria for subsequent allocations, or in the new IPv6 allocation criteria for APNIC members. Including the aggregation requirement is problematic for two reasons: 1. It is inconsistent the criteria for IPv6 allocations under two other APNIC policies, which do not require aggregation. These policies are: - Subsequent IPv6 allocations - The new kick start IPv6 allocation criteria to be implemented 10 February 2010 [2] 2. Registry policy should not concern itself strongly with routing issues. 3. Situation in other RIRs --------------------------- LACNIC: The LACNIC community is currently discussing the following proposal to remove the requirement to announce an initial allocation as a single prefix in favour of announcing the prefix with the minimum possible level of disaggregation: 2007-01: Modifications to the IPv6 Prefix Initial Allocation Policy <http://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-en.pdf> RIPE: The RIPE community has recently removed routing requirements from IPv6 policy: 2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy <http://www.ripe.net/ripe/policies/proposals/2009-06.html> AfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent allocation criteria. Neither RIR is has any proposal to modify these criteria. 4. Details ----------- This is a proposal to: 4.1 Remove the requirement under the initial IPv6 allocation criteria to advertise an initial allocation as a single (aggregate) prefix. 4.2 Include a stronger recommendation about the importance of aggregation to the IPv6 policy document. The APNIC IPv6 policy document currently does include information about the importance of aggregation[3]. However, it is the opinion of this proposal's authors that the recommendation should be more strongly expressed. 5. Pros/Cons ------------- 5.1 Advantages - This policy reduces the number of requirements to obtain IPv6 address. - Other RIR communities are discussing removing aggregation requirements from their policies, so it would be appropriate for APNIC policy to maintain similar criteria to other regions. 5.2 Disadvantages - By removing the aggregation requirement in the policy, deaggregated routes may begin to be announced more frequently. 6. Effect on APNIC members --------------------------- APNIC members can apply for IPv6 addresses without ensuring aggregation. 7. Effect on NIRs ------------------ NIRs should remove the aggregation requirement from IPv6 initial allocation criteria. 8. References -------------- [1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" <http://www.apnic.net/policy/ipv6-address-policy#5.2.1> [2] prop-073: Simplifying allocation/assignment of IPv6 to APNIC members with existing IPv4 addresses" <http://www.apnic.net/policy/proposals/prop-073> [3] See section 3.4, "IPv6 Address Allocation and Assignment Policy" <http://www.apnic.net/policy/ipv6-address-policy#3.4>

1 0

prop-083: Alternative criteria for subsequentIPv6 allocations
by Terence Zhang YH(CNNIC) 23 Feb '10

23 Feb '10

Dear SIG members, The proposal, 'Alternative criteria for subsequent IPv6 allocations', 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-083-v001: Alternative criteria for subsequent IPv6 allocations ___________________________________________________________________ Author: Skeeve Stevens <skeeve(a)eintellego.net> Version: 1 Date: 3 February 2010 1. Introduction ---------------- This is a proposal to enable current APNIC account holders with existing IPv6 allocations to receive subsequent IPv6 allocations from APNIC for use in networks that are not connected to the initial IPv6 allocation. 2. Summary of current problem ------------------------------ An APNIC account holder with an existing /32 IPv6 allocation (or larger) is unable to deaggregate that allocation into routes smaller than a /32 due to the community practice of 'filter blocking' or 'bogon lists' associated with RIR blocks which are known to have a minimum allocation size of /32 [1]. An LIR may want to build a network in a separate location and provide IPv6 connectivity; however, because the LIR risks routability problems if they deaggregate, they cannot use a subset of their initial allocation in the new location. For example: An ISP has a /32 allocation which they announce via an upstream in New Zealand. The ISP wants to build a new network in Singapore. The ISP's new network in Singapore is not connected to the existing New Zealand network and the ISP is using a local transit provider to obtain dual stacked connectivity. If the network was using IPv4 addresses, the ISP would usually be able to deaggregate their allocation and announce one part of the deaggregated range to the local transit provider. In IPv6, however, this is not possible due to 'community filtering' on ranges smaller than a /32. Such a filter may look like the following: ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32 This above statement in the IPv6 BGP filter recommendations would cause any announcements by an ISP which had an allocation, such as 2400:0000::/32, to announce smaller routes from that block, such as multiple /35s for example, to be filtered. In a default free situation, connectivity to the ISP would be problematic. Instead, the ISP needs to obtain a new /32 allocation to be able to have IPv6 connectivity in the new location with an independent (from their primary network) transit provider. 3. Situation in other RIRs --------------------------- AfriNIC, ARIN, LACNIC and RIPE currently have no similar policies or proposals. However, ARIN mailing lists are presently discussing this situation and there seems to be significant support. 4. Details of the proposal --------------------------- 4.1 It is proposed that alternative criteria be added to the subsequent IPv6 allocation policy [2] to allow current APNIC account holders with networks in multiple locations but without a connecting infrastructure to obtain IPv6 resources for each location. 4.2 To qualify for subsequent IPv6 allocations under the proposed alternative criteria, account holders must: - Be a current APNIC account holder with an existing IPv6 allocation - Be announcing its existing IPv6 allocation - Demonstrate that the LIR has additional networks that are not connected to the network announcing its existing IPv6 allocation 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - This proposal enables current APNIC account holders to avoid problematic network design issues and policy issues related to deaggregation. - Current APNIC account holders will be able to acquire resources and announce them separately to transit providers in disparate locations. 5.2 Disadvantages - This proposal could cause faster consumption of IPv6 address space. However, given the size of the total IPv6 pool, the author of this proposal does not see this as a significant issue. 6. Effect on APNIC members --------------------------- APNIC members would be able to build networks in separate locations and obtain local IPv6 connectivity and announce their own resources. 7. Effect on NIRs ------------------ The proposal allows for NIRs to have the choice as to when to adopt this policy for their members. 8. References --------------- [1] For example, see "IPv6 BGP filter recommendations" http://www.space.net/~gert/RIPE/ipv6-filters.html [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/policy/ipv6-address-policy#5.2 _______________________________________________

4 4

Withdrawn - prop-076: Requiring aggregation for IPv6 subsequent allocations
by Randy Bush 19 Feb '10

19 Feb '10

_____________________________________________________________________ prop-076: Requiring aggregation for IPv6 subsequent allocations _____________________________________________________________________ Dear Colleagues, The proposal, 'Requiring aggregation for IPv6 subsequent allocations' has been withdrawn by the proposal's authors. Following feedback received at APNIC 28, the authors drafted a new proposal that removes the aggregation criteria for IPv6 initial allocations. The new proposal will be presented at APNIC 29 as prop-082, 'Removing aggregation criteria for IPv6 initial allocations'. prop-076 details ---------------- This was a proposal to make it a condition that LIRs aggregate subsequent IPv6 allocations that they receive from APNIC. Proposal details including the full text of the proposal, presentation, links to relevant meeting archives, and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-076 Regards 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 February 2010