sig-policy July 2008

sig-policy@lists.apnic.net

19 participants
18 discussions

[Sig-policy] prop-062-v001: Use of final /8
by zhangjian 22 Aug '08

22 Aug '08

Dear SIG members The policy proposal 'Use of final /8' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-062-v001.html 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? randy and jian ______________________________________________________________________ __ prop-062-v001: Use of final /8 ______________________________________________________________________ __ Authors: Philip Smith pfs(a)cisco.com Jonny Martin jonny(a)jonnynet.net Randy Bush randy(a)psg.com Version: 1 Date: 15 July 2008 1. Introduction ---------------- This proposal describes how APNIC should handle the final /8 which would be allocated to it by the IANA under a successful implementation of prop-055, "Global policy for the allocation of the remaining IPv4 address space" [1]. The proposal seeks to ensure that new and existing LIRs can receive a minimum amount of IPv4 address space to assist with their participation in the Internet industry as the industry transitions to using the IPv6 protocol over the next few years. 2. Summary of current problem ------------------------------ The IANA IPv4 address pool is diminishing rapidly. If prop-055 is implemented globally, each RIR will receive a /8 to be used once the remaining IANA IPv4 pool has been depleted. One of the goals of prop-055 was that each RIR could then use its allocated /8 in a way that suits the individual needs of its community. In APNIC's case, the intention of the proposal's authors is to use the final /8 to reduce the surprise incurred by new LIRs during the transition from the IPv4 to IPv6 protocol. The Internet will still use IPv4 for several years during the adoption of IPv6. During this period new LIRs will need to participate in the IPv4 Internet while they deploy services using the IPv6 Internet. Inability to participate directly in the IPv4 Internet inhibits new LIRs' ability to provide service. If this were to happen, new LIRs would have to resort to address translation devices to map the private IPv4 address space they use into the public address space received from their upstream providers. Existing APNIC policy regarding the distribution of IPv4 address space makes no allowance for IPv4 allocations to new LIRs after the IANA pool is exhausted. Without any particular policy for this address block, APNIC's normal IPv4 allocation rules would apply. It is quite feasible, for example, that one organisation could consume the entire final /8 address block delegated to APNIC by IANA, negating the purpose and considerable effort that has gone into gaining global consensus for prop-055 in the first place. This policy proposal seeks to address that problem. 3. Situation in other RIRs --------------------------- As far as is known, there is no similar policy either being proposed or implemented at any of the other RIRs but we would like to recommend that they consider analogous proposals. This policy proposal applies to the APNIC service region only. It is highly likely that similar policy proposals will be made in other RIR regions also. It should be noted that at the recent LACNIC XI meeting, consensus was reached on the following policy proposal: LAC-2008-04: Special IPv4 Allocations/Assignments Reserved for New Members www.lacnic.net/documentos/politicas/LAC-2008-04-propuesta-en.pdf Under the LACNIC proposal, when there is no more IPv4 address space in the IANA free pool, LACNIC will reserve a /12 out of their remaining pool. From this /12, LACNIC will allocate /22s to new LIRs and assign /24s to critical infrastructure. 4. Details of the proposal --------------------------- This proposal describing the distribution of the final /8 has three parts: 4.1 New LIRs It is proposed that each new LIR receive IPv4 addresses which they can use for supporting legacy IPv4 services to ensure their full presence on the IPv4 Internet during the transition phase to IPv6: - Each new LIR may receive exactly one /22 (1024 routable IPv4 addresses), APNIC's current minimum allocation size. If APNIC's current minimum allocation were to reduce in size in future, the allocation made under this policy should also be reduced to match. - Each new LIR may receive the specified allocation size regardless of LIR size or intended membership tier. - New LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to APNIC's allocation policy in force at the time (currently documented in [APNIC-86]). A new LIR in this proposal is defined as being an organisation which has recently become a full member of APNIC or a full member of one of APNIC's NIRs but has yet to be assigned or allocated any IPv4 address space. Membership of APNIC as an LIR is determined by APNIC's membership criteria at the time of application. Membership of an APNIC NIR is determined by each individual NIR's membership criteria at the time of application. 4.2 Existing LIRs It is proposed that each existing LIR may request and receive only a single allocation from the remaining /8: - Each existing LIR may receive exactly one /22, APNIC's current minimum allocation. If APNIC's current minimum allocation were to reduce in size in future, the allocation made under this policy should also be reduced to match. - Each existing LIR may receive the specified allocation size regardless of size or intended membership tier - Each existing LIR may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to APNIC's current allocation policy in force at the time (currently documented in [APNIC-86]). This ensures that each existing LIR receives 1024 routable IPv4 addresses which they can use for supporting legacy IPv4 services during the transition phase to IPv6. An existing LIR in this proposal is defined as being an organisation which is a full member of APNIC or a full member of one of APNIC's NIRs and has already been assigned or allocated IPv4 address space. Membership of APNIC as an LIR is determined by APNIC's membership criteria at the time of application. Membership of an APNIC NIR is determined by each individual NIR's membership criteria at the time of application. 4.3 Unforeseen circumstances It is proposed that: - A /16 is held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. - In the event that this /16 remains unused in the time the remaining /8 covered by this policy proposal has been allocated to LIRs, it returns to the pool to be distributed as per clauses 4.1 and 4.2. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - APNIC's final /8 will have a special policy applicable to it. This avoids the risk of one or a few organisations consuming the entire block with a well crafted and fully justified resource application. - The proposal ultimately allows for 16384 LIRs (both new and existing) to receive exactly one /22 each. This is substantially larger than the existing APNIC membership, and attempts to ensure that no organisation lacks real routable IPv4 address space during the coming transition to IPv6. 5.2 Disadvantages - Some organisations may believe and can demonstrate that their IPv4 requirements are larger than a /22. But this final /8 is not intended as a solution to the growth needs of a few organisations, but for assisting with the transition from IPv4 to IPv6. - Some organisations may set up multiple LIR registrations in an effort to get more address space than proposed. APNIC must be vigilant regarding these, but the authors accept that it is hard to ensure complete compliance. With 16384 possible allocations being proposed, this is not envisaged to be a major problem. 6. Effect on APNIC members --------------------------- This proposal allows APNIC LIRs (existing and new) to receive address space from the final /8 allocated to APNIC under prop-055. 7. Effect on NIRs ------------------ This proposal has no direct impact on the operation of the NIRs, but as noted in the text above, has direct impact on the ability of NIR members (existing and new) to receive address space from the final /8 allocated to APNIC under prop-055. 8. References -------------- [1] prop-055: Global policy for the allocation of the remaining IPv4 address space http://www.apnic.net/policy/proposals/prop-055-v001.html _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair(a)apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair

12 34

prop-050-v002: IPv4 address transfers
by Toshiyuki Hosaka 19 Aug '08

19 Aug '08

Dear SIG members Version two of the proposal 'IPv4 address transfers' has been sent to the Policy SIG for review. It will be presented during the Policy SIG sessions at APNIC 25 in Taipei, Taiwan, 25-29 February 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-050-v002.html 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: - Ask the proposer questions if anything in the proposal is unclear - Point out advantages and disadvantages you see in the proposal - State whether you support or oppose the proposal Mailing list discussions will be taken into account when the proposal is discussed at the upcoming APNIC meeting. So please make sure you have your say. APNIC Policy SIG Chairs Toshiyuki Hosaka Randy Bush Jian Zhang ________________________________________________________________________ prop-050-v002: IPv4 address transfers ________________________________________________________________________ Author: Geoff Huston gih(a)apnic.net Version: 2 Date: 22 January 2008 1. Introduction ---------------- This is a proposal to remove APNIC policy restrictions on the transfer of registration of IPv4 address allocations and IPv4 portable address assignments between current APNIC account holders. This proposal is a refinement of the historical resource transfer policy and applies to IPv4 resources held by current APNIC account holders. 2. Summary of current problem ------------------------------ Current APNIC policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network. It is currently anticipated that the IPv4 unallocated address pool will be exhausted in a timeframe of between 2009 and 2011. There is a very considerable level of investment in IPv4-based services in the Asia Pacific region, and a transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. It is the objective of the APNIC IPv4 address registry to accurately record current address distribution information. This proposal allows APNIC to recognise the transfer of IPv4 addresses between current APNIC account holders, and places some constraints on the parties to the transfer as a precondition for the registration of the IPv4 address transfer to be undertaken by APNIC. 3. Situation in other RIRs ---------------------------- It is the understanding of the proposer that no comparable IPv4 resource transfer policy between account holders has been adopted in any other RIR. A proposal for address transfers similar to this proposal has been submitted to the RIPE community as a Policy Proposal: 2007-08: Enabling Methods for Reallocation of IPv4 Resources http://www.ripe.net/ripe/policies/proposals/2007-08.html 4. Details of the proposal ---------------------------- APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions: Conditions on the IPv4 address block: - Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical". Conditions on source of the transfer: - The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation. Conditions on recipient of the transfer: - The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held. The address transfer process: After APNIC is notified of the transfer by both the source and the recipient of the transfer: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the source's address holdings as of the date of transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date. 3. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date. In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient. 4. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Recipient - Address resources - Date of transfer Transfer fees: APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges. 5. Advantages and disadvantages of the proposal ------------------------------------------------- Advantages: This proposal would: - Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders. - Mitigate the risks to the integrity of the network and its routing and addressing infrastructure associated with the unregistered transfers of IPv4 addresses. This proposal, by acknowledging the existence of address transfers and registering the outcomes would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith. - Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition. Disadvantages: - Concerns have been raised about a market-based system emerging as the only means to obtain IPv4 address space in future, and the potential for certain forms of market failures, including the possibility of hoarding, speculation and price manipulation. A number of factors mitigate these risks. As the transition to IPv6 gathers pace, a market-based value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. An additional constraint would apply if this policy were to be adopted while IPv4 addresses are still available from APNIC, as APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry. 6. Effect on APNIC members ---------------------------- APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC account holders. 7. Effect on NIRs ------------------- This policy does not encompass IPv4 address holdings administered by NIRs, nor the transfer of resources where the source or recipient are NIR-serviced entities. (end of document)

8 20

[Sig-policy][Draft announcement]prop-050: IPv4 addresstransfers
by zhangjian 15 Aug '08

15 Aug '08

Dear SIG members An updated version of the proposal 'IPv4 address transfers' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-050-v003.html This new version of the proposal has expanded commentaries in sections 2 and 5. Section 3 now includes a reference to the transfer proposal under discussion in the ARIN region. 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? randy and jian ________________________________________________________________________ prop-050-v003: IPv4 address transfers ________________________________________________________________________ Author: Geoff Huston gih(a)apnic.net Version: 3 Date: 22 July 2008 1. Introduction ---------------- This is a proposal to amend APNIC policy restrictions on the transfer of registration of IPv4 address allocations and IPv4 portable address assignments between current APNIC account holders. This proposal is a refinement of the historical resource transfer policy and applies to IPv4 resources held by current APNIC account holders. 2. Summary of current problem ------------------------------ Current APNIC policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network. It is currently anticipated that the IPv4 unallocated address pool will be exhausted in a timeframe of between 2009 and 2011. There is a very considerable level of investment in IPv4-based services in the Asia Pacific region, and a transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks. It is the objective of the APNIC IPv4 address registry to accurately record current address distribution information. This proposal allows APNIC to recognise the transfer of IPv4 addresses between current APNIC account holders, and places some constraints on the parties to the transfer as a precondition for the registration of the IPv4 address transfer to be undertaken by APNIC. The underlying assumptions behind this policy proposal are: - There will continue to be need for additional IPv4 address resources in the AP region after the exhaustion of the APNIC IPv4 unallocated address pool - The amount of returned address space to APNIC will not meet those needs - Some IPv4 address holders will be in a position to release address space and convert to NAT or similar solutions if they are given some level of incentive - Some amount of transfer of address space will occur in the APNIC region following the exhaustion of the unallocated IPv4 address pool - The registry of IPv4 addresses operated by APNIC is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community. This proposal's central aim is to ensure the continuing utility and value of the APNIC address registry by allowing the registry to record transactions where IPv4 addresses are transfered between APNIC account holders. It proposes that APNIC will recognise and register a transfer of addresses where the parties to the transfer are 'known' to APNIC and that the address block being transferred is part of APNIC's current (non-historical) address set The proposal does not: - Prescribe how such transfers may occur, nor - Impose any further constraints on the transfer or on the parties involved. 3. Situation in other RIRs ---------------------------- Proposals for address transfers similar to this proposal are being discussed at the following RIRs: RIPE 2007-08: Enabling Methods for Reallocation of IPv4 Resources http://www.ripe.net/ripe/policies/proposals/2007-08.html ARIN Policy Proposal 2008-2: IPv4 Transfer Policy Proposal http://www.arin.net/policy/proposals/2008_2.html 4. Details of the proposal ---------------------------- APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions: Conditions on the IPv4 address block: - Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical". Conditions on source of the transfer: - The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation. Conditions on recipient of the transfer: - The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held. The address transfer process: After APNIC is notified of the transfer by both the source and the recipient of the transfer: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the source's address holdings as of the date of transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date. 3. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date. In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient, and subject to availablility of an alternate address block from APNIC 4. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Recipient - Address resources - Date of transfer Transfer fees: APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges. 5. Advantages and disadvantages of the proposal ------------------------------------------------- 5.1 Advantages This proposal, by acknowledging the existence of address transfers and registering the outcomes, would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith. In particular, it would: - Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders. - Mitigate the risks to the integrity of the network, and its routing and addressing infrastructure in particular, associated with the unregistered transfers of IPv4 addresses. - Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition. 5.2 Disadvantages (and responses) 5.2.1 Altering the traditional concepts of IP addresses This proposal has the potential to alter a number of traditional preconceptions relating to addresses and their value, including challenging the concept that addresses are not in and of themselves assets and addresses do no in and of themselves have monetary value outside of the narrow constraints of use in networks for routing and end point identification. Changing these common percpetions about addresses and their use opens up the potential for a number of responses, including: - The loss of strong aggregation capability in the address space, with the consequent load being imposed on the routing system. - The significant shift away from a universal need-based address allocation model in the underlying policy framework. - The treatment of addresses as property with the associated legal ramifications in terms of corporate and contract law. - The imposition of taxes on addresses and their movement. - The potential for unfairness and inequities to be realized in terms of access to addresses for use by network service providers. Response: A number of factors mitigate the risks above: - As the transition to IPv6 gathers pace, any residual value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. - If this policy were to be adopted while IPv4 addresses are still available from APNIC, APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry. 5.2.2 Proposal diverts attention from address reclamation and resuse It has been argued that the proposal diverts attention from policy development that encourages IP address reclamation and reuse. Response: To date the level of return and reclamation of addresses has been minimal. Aside from price-based mechanisms it is unclear that further policy refinement would alter this situation. Even if policy development encouraged address reclamation and reuse, there is the distinct possibility that the amount reclaimed addresses would be smaller than the amount needed for APNIC to continue to allocate addresses on a needs-basis after the unallocated address pool has been exhausted. An open and significant issue is how APNIC could fairly ration limited addresses when faced with a much larger set of demands. In other words, concentrating on relamation and reuse policies rather than transfer policies also contains significant issues that may prove challenging to resolve as a policy matter. 5.2.3 Potential for APNIC to be cast as a regulator If APNIC adopted this policy, APNIC may be cast as a regulator of a secondary market in addresses. Concerns have been expressed that APNIC has no experience, expertise nor the authority to enforce regulatory actions. Such a role may also expose APNIC to additional litigation. Response: This proposal does not advocate such a role for APNIC. The scope of this policy is explicitly limited to the conditions that would allow APNIC to recognise and record a transfer of addresses in its registry. There is a general belief that adoption of this policy would act as an incentive for a market in addresses. However, that does not imply that markets would act outside existing regulatory structures. Nor does it mean that market participants would be immune from existing regulatory measures within their respective regimes. The potential for additional liabilities associated with this policy should be the subject of legal review by an appropriately qualified party. 5.3 Summary of comments on transfer proposals There are a number of views of this that have been noted in the various policy discussions on this topic in the various RIR policy forums. The APNIC policy proposal is broadly similar to a policy proposal under consideration in RIPE, which is referred to here as a "minimal' policy for address transfers. The address transfer proposal currently under consideration in ARIN has a larger set of constraints to be applied to determine if a transfer would be recognised by the registry. A summary of the discussion of the differences in these policy proposals follows. 5.3.1 In favor of a 'minimal' policy - The policy places APNIC in the role of a 'title office' for addresses, and ensures that APNIC, as a registry operator, is neutral in terms of the means used by APNIC members to determine that they wish to proceed with a transfer of addresses. As long as the criteria for a valid transfer are met, by whatever means agreed to by the parties involved, then the registry should allow the transaction to be duly recorded. - APNIC has no practical operational experience in the area of enforcing various constraints on parties as to how and why addresses may be transferred, and does not currently have any recognized authority to do so. Making policy in the absence of a well understood and commonly accepted authority model calls into question the legitimacy and authority of outcome. - Regulation is a well understood and familiar concept in many, if not all, regimes. If there is a general desire to place constraint and regulate the actions of parties who wish to undertake a transfer of addresses, then it may be preferred to do so in the context of a broader framework that involves other bodies and authorities that have a greater level of experience and authority in this area of activity, and leverage from existing regulatory structures and enforcement mechanisms. In this manner the policy proposal does not attempt to create a novel, and potentially superfluous additional regulatory framework. - APNIC has no experience in determining what actions by potential parties to a transfer may need to be constrained in some fashion. Attempting to create policy in anticipation of the need for such constraints is going to be a guessing game that has accompanying flaws, Irrespective of what constraints are initially specified in policy, it will be the case that as the levels of experience in this form of activity increases some iterations over the policy of constraints will be necessary in any case. This approach argues to start from a position that is relatively open and unrestricted, and recommend that APNIC impose additional constraints only when all other forms of constraint are inapplicable and there is a clear need and common desire for such constraints to be enforced by APNIC as distinct from using another party for such a role. 5.3.2 In favour of applying a greater level on constraint in the policy - APNIC has no practical operational experience in address transfers, so we should take incremental steps form the current position rather than a complete relaxation of the entire set of constraints associated with the existing allocation framework. Recipients of a transfer should be qualified by the registry on the basis of demonstrated need in the same fashion as recipient of address allocations today. Address blocks should not be arbitrarily fragmented. Timing constraints should be applied to stop transfers of addresses occurring that are primarily motivated by reasons other than immediate need for use in deployed networks. - Constraints that are generally considered to be onerous and unnecessary can always be removed at a later date, while applying and enforcing additional constraints at a later date will prove to be a far harder task. - There are a number of technical risks associated with address trading. Unconstrained deaggregation will lead to a fracture of the routing system due to unconstrained and large scale expansion of the inter-domain routing table. This is an irreversible state. 5.3.3 Discussions of the emergence of a market The various comments made on this and the related address transfer policy proposals provides grounds for the observation that there is a general perception that the recognition of address transfers leads to a de facto recognition of the emergence of a market or markets for IPv4 addresses. A related topic of discussion about the merits or otherwise of these proposals has been the consideration of the relative merits and risks of market behaviours when applied to this situation. The comments opposed to the emergence of markets include the following: - Markets in addresses are an inevitable consequence of a transfer policy, and unconstrained markets are prone to a number of risks of distortion. These risks include deceptive trading, margin trading, trading in market derivatives and futures, hoarding, and speculation. The utility of an address as a token for addressing a packet is devalued in a market situation. - Operation of a market will lock out all but the largest of players in the network from access to further addresses, as the value of the address will be set by the bidder with the highest price and the ability to exploit the address to its maximal extent. - The operation of a market in IPv4 addresses will lead to the erosion of the effectiveness of self-imposed policies in IPv6, and may lead to the emergence of a market in IPv6 addresses. - Markets are unfair in terms of the implicit bias of a market in favour of those parties who are in a position to set the market price, and inherently discriminating against those parties who do not have the capacity to pay. In an international context this is counter to the general objective of a generally available, neutral and non-discriminatory communications infrastructure. Comments in favour of the emergence of a market in IPv4 addresses include: - Address exhaustion poses an insoluble problem to the address registries in that for as long as there is a continuing demand for addresses the registries have no means to meet that demand. Markets create a means for addresses to be recycled, and create a means for the various levels of demand and supply of addresses in IPv4 to reach a balance through a market-based pricing mechanism. - At every stage there is always an alternative to bidding for IPv4 addresses in the context of a market transaction: namely the use of IPv6 within the network, and the use of an upstream protocol translation service to provide legacy access to other IPv4 networks. Given that substitutes exist, the potential price of IPv4 addresses in a market is capped by the cost of deployment of IPv6 and IPv4 transitional mechanisms. - This is a temporary measure during the dual stack phase of IPv6 transition. The higher the market price for IPv4 addresses the greater the cost pressure placed on the industry to undertake the IPv6 transition, which in turn limits the lifetime of the market and the speculative potential of any such market. Players will have an incentive to act quickly in terms of releasing address resources into such a market given that withholding for too long will result in no return as the market will naturally terminate once IPv6 transition has reached a critical deployment mass. It should be noted that this address transfer policy proposal is mute on the topic of a market for address transfers, and neither advocates nor specifically opposes the emergence of any such market or markets. The policy constrains itself to enumeration of the set of constraints that would apply for APNIC to recognise and register a transfer of addresses between APNIC members. How those parties arrived at the decision to undertake the transfer, and the related issues concerning property, financial and legal frameworks and the emergence of markets, the need to regulate such markets and identification of the market regulator are specifically not encompassed by this policy proposal, nor does this proposal advocate that such a role be undertaken by APNIC. 6. Effect on APNIC members ---------------------------- APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC members. 7. Effect on NIRs ------------------- This policy does not encompass IPv4 address holdings administered by NIRs, nor the transfer of resources where the source or recipient are NIR-serviced entities. _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair(a)apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair

3 3

Monthly List Reminder
by noreply＠apnic.net 31 Jul '08

31 Jul '08

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

prop-061-v001: 32-bit ASNs for documentation purposes
by Randy Bush 29 Jul '08

29 Jul '08

Dear SIG members The proposal '32-bit ASNs for documentation purposes' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-061-v001.html 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? randy and jian ________________________________________________________________________ prop-061-v001: 32-bit ASNs for documentation purposes ________________________________________________________________________ Author: Philip Smith pfs(a)cisco.com Gaurab Raj Upadhaya gaurab(a)lahai.com Version: 1 Date: 14 July 2008 1. Introduction ---------------- This document discusses the requirement to reserve 32-bit ASNs for the sole purpose of assisting the creation of Internet related documentation. 2. Summary of current problem ------------------------------ For 32-bit ASNs, the AS space above 65535 (or 1.0 in "dot" notation) is either reserved for future use or allocated, with no portion of the space available for documentation purposes. Authors often need to include example address space and AS numbers when documenting the Internet and the configuration of equipment used in the operation of the Internet. Authors currently use Internet resources from a variety of sources. The following examples describe typical example usage of such Internet resource: 1. Using private address space and/or private AS space RFC 1918 [1] address space is often used for documentation requiring the use of IPv4 address space. It's not ideal, but given that the addresses look like the rest of IPv4 address space, and that it is an ISP BCP to filter private addresses out of Internet announcements, its use protects against cut-and-paste accidents. The AS range 64512 to 65534 [2] is often used for documentation requiring the use of 16-bit AS numbers. Most ISPs automatically filter private ASNs out of the AS path as they announce them to the Internet, so the use of private ASNs for documentation is not normally a problem. 2. Resources reserved for documentation purposes RFC 3849 [3] describes an IPv6 address block which can be used exclusively for documentation purposes. 3. Using Internet resources from their employer. This is easy to do, and this resource is typical of that which is routed on the Internet. 4. Using Internet resources of a typical network on the Internet. Quite often the resources of the larger and more commonly known ISPs are used in examples. 5. Easy to remember address values and ASNs are used. Typical examples might be 1.1.1.1, 2.2.2.2, AS100, AS2.4 and so on. Quite often these resources are from existing allocations. 6. Resources from ranges unassigned/unallocated at the time the documentation is written have been used. For example, ASNs above 48000, or the network 222/8 address block have been used. There are two major problems with the last four options above: - Readers, especially those who are learning about the Internet, do tend to cut and paste the configuration examples onto running equipment. Quite often this lab equipment is connected to a live production network, causing confusion and disruption to the innocent network used in the example. The Internet today is a serious commercial entity with the vast majority of business participating in it attributing a serious portion of their annual revenue to business done over the net. Dealing with a denial of service attack caused by an innocent cut and paste by a student of the industry has in the past caused major revenue loss for some organisations this has the potential to reoccur in the future. - Using address and AS space which is unused at the time the documentation is written means that at some stage in the near future the examples can disrupt real live networks, as has just been discussed in the previous point. 3. Situation in other RIRs ---------------------------- The RIRs currently have no formal common policy for making a 32-bit ASN allocation exclusively for documentation purposes. 4. Details of the proposal ----------------------------- It is proposed that: 4.1 APNIC set aside a common block of 32-bit ASNs to be used solely for the purpose of documentation. 4.2 The 32-bit ASN block for documentation include four ASNs. This is sufficient for a small network topology to include either exclusive 32-bit ASN or a mixture of 16-bit or 32-bit ASNs for purposes of documenting relationships between ASNs. 5. Advantages and disadvantages of the proposal ------------------------------------------------- Advantages: - Authors of documentation and Internet books no longer have to use 32-bit ASNs which belong to their employer (and risk causing disruption to their employers business), or using 32-bit ASNs allocated to random organisations around the Internet (and risk causing disruption to a multitude of organisations). Disadvantages: - Acceptance of this proposal will mean that four 32-bit ASNs will be added to the non-routable ASN space of the Internet. The four 32-but ASNs will need to be added to the existing AS_PATH filter list used by all ISPs, in the same way that RFC 1918 and RFC 3849 address space should never appear on the public Internet. - Acceptance of this proposal could potentially make some people believe that this ASN block is effectively private ASN space as it is not routable. - If this proposal is rejected, authors will have to carry on with the practice highlighted in the Background section of this proposal, with the associated risks to the integrity of the commercial Internet. 6. Effect on APNIC members ---------------------------- This proposal has no direct effect on APNIC members. 7. Effect on NIRs ------------------- This proposal has no direct effect on NIRs. 8. References --------------- [1] RFC 1918, Address Allocation for Private Internets http://www.ietf.org/rfc/rfc1918.txt [2] Autonomous System (AS) Numbers, http://www.iana.org/assignments/as-numbers [3] RFC 3849, IPv6 Address Prefix Reserved for Documentation http://www.ietf.org/rfc/rfc3849.txt -30-

9 20

prop-066 bis - Ensuring efficient use of historical IPv4 resources
by Randy Bush 29 Jul '08

29 Jul '08

Dear SIG members Version 2 of the proposal 'Ensuring efficient use of historical IPv4 resources' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-066-v002.html This new version of the proposal contains an updated section 3, "Situation in other RIRs". 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? randy and jian ________________________________________________________________________ prop-066-v002: Ensuring efficient use of historical IPv4 resources ________________________________________________________________________ Authors: Brenda D. Tarimel btarimel(a)palaunet.com Philip Smith pfs(a)cisco.com James Spenceley james(a)vocus.com.au Version: 2 Date: 28 July 2008 1. Introduction ---------------- This is a proposal to include all historical address allocations when assessing a network's eligibility for more IPv4 addresses. 2. Summary of current problem ------------------------------ The unallocated pool of IPv4 addresses is predicted to run out within the next few years. As the unallocated pool dwindles, it is important to ensure that the remaining IPv4 addresses are allocated responsibly and fairly. Currently, when LIRs apply for new IPv4 allocations from APNIC, they only have to include the past allocations they have received from APNIC as part of the documentation and justification process. They do not have to declare any historical addresses [1] they may have received prior to receiving address space from APNIC. As a result of this, there is a large amount of historical IPv4 address space where little or nothing is known about its use. At the moment LIRs can receive more scarce IPv4 address space from APNIC while at the same time hoarding unused historical address space. This uses up the remaining IPv4 pool more rapidly than is really necessary. 3. Situation in other RIRs --------------------------- The situation in other RIRs is as follows: AfriNIC and the RIPE NCC only ask for utilisation of previous allocations and assignments made by AfriNIC and the RIPE NCC respectively. They do not require legacy holdings to be declared. ARIN and LACNIC always ask for utilisation for all previous allocations and assignments, including all legacy holdings. This proposal has not been submitted to any other region. 4. Details of the proposal --------------------------- This is a proposal to modify the criteria for receiving IPv4 address space so that both historical addresses and previous allocations are included. - This proposal applies to all historical IPv4 resources registered in the APNIC Whois Database. - Historical IPv4 resources that are not managed under the existing historical maintenance or transfer policies will remain free of fees. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Ensures that organisations are using scarce IPv4 address space resources to the fullest extent possible. - The utilisation of historical IPv4 addresses will be brought into line with current best practices for address management. - The remaining IPv4 free pool will be delegated to LIRs that have a genuine need for IP addresses. 5.2 Disadvantages - Organisations can no longer hoard unused address space while at the same time receive more scarce address space from APNIC's pool. - LIRs with historical IPv4 addresses may find it time consuming to change network architecture that uses historical IPv4 addresses in an inefficient manner. However, the difficulties felt by these networks is outweighed by the greater benefits of ensuring that the remaining IPv4 address space is delegated to networks with a genuine need for IPv4 allocations. 6. Effect on APNIC members --------------------------- APNIC members who have applied best practices for address space management for all their address ranges will not be affected. APNIC members who have not applied best practices for all their address ranges may need to modify their management of historical addresses before they can qualify for IPv4 addresses from APNIC. There will be no impact on fees paid by members. 7. Effect on NIRs ------------------ The proposal has no direct impact on NIRS, but impacts members of NIRs in the same way it impacts APNIC members. 8. References --------------- [1] Historical resources definition http://www.apnic.net/policy/historical-resource-policies.html#2.2 randy & jian

1 0

Reminder: upcoming APNIC policy implementations
by Sam Dickinson 28 Jul '08

28 Jul '08

________________________________________________________________________ Upcoming APNIC policy implementations ________________________________________________________________________ This is a reminder that on 4 August 2008, APNIC will implement two policy proposals that reached consensus at the APNIC 25 Policy SIG in Taipei, Taiwan in February 2008. The APNIC Executive Council (EC) endorsed the proposals during their May 2008 meeting. The two policy changes are: - Changing the minimum IPv4 allocation size to /22 This change will make it easier for small ISPs to receive direct allocations from APNIC. - Adding an alternative IPv6 initial allocation criteria This change will make it easier for more ISPs to receive IPv6 allocations from APNIC by enabling current LIRs with IPv4 allocations to receive IPv6 initial allocations without a plan for making 200 assignments. To view the history of these policy proposals, see: prop-053: Changing minimum IPv4 allocation size to /22 http://www.apnic.net/policy/proposals/prop-053-v003.html prop-057: Proposal to change IPv6 initial allocation criteria http://www.apnic.net/policy/proposals/prop-057-v002.html Regards _____________________________________________________________________ Samantha Dickinson email: sam(a)apnic.net Policy Development Manager, APNIC sip: sam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

1 0

prop-064: Change to assignment policy for ASnumbers
by zhangjian 27 Jul '08

27 Jul '08

Dear SIG members Version 2 of the proposal 'Change to assignment policy for AS numbers' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-064-v002.html The updated proposal adds a specific date for the intermediary stage described in section 4.3 of the proposal. 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? Randy and Jian ________________________________________________________________________ prop-064-v001: Change to assignment policy for AS numbers ________________________________________________________________________ Authors: James Spenceley james(a)vocus.com.au Version: 1 Date: 22 July 2008 1. Introduction ---------------- The policy seeks to create awareness earlier within the community for the need to support 4-byte AS numbers without mandating an absolute final adoption of 4-byte AS numbers. 2. Summary of current problem ------------------------------ The current policy has three critical dates with associated policy changes for the assignment of 4-byte AS numbers as documented in APNIC-094-v003, "Policies for Autonomous System number management in the Asia Pacific region [1]: 1 January 2007 APNIC assigns two-byte AS numbers by default. APNIC assigns four-byte AS numbers on request. 1 January 2009 APNIC assigns four-byte AS numbers by default. APNIC assigns two-byte AS numbers on request. 1 January 2010 APNIC ceases to make any distinction between two- and four-byte AS numbers. APNIC assigns from an undifferentiated four-byte AS number pool. As the policy currently stands today, we have a specific jump from 'must request a 2-byte AS' to 4-byte AS numbers being generally assigned. Currently LIRs may if they choose, simply continue to request 2-byte AS numbers until 1 January 2010 at which time APNIC will begin assignment of 4-byte AS numbers from without differentiation, This places little requirement on the general provider community to support 4-byte AS numbers or equipment vendors to implement and support 4-byte AS numbers. 3. Situation in other RIRs --------------------------- The other RIRs assign 4-byte ASNs in the same way as APNIC. If successful, it is expected that this policy will be presented to the other RIRs for adoption. 4. Details of the proposal --------------------------- 4.1 This proposal seeks to create an intermediary stage where LIRs will be assigned a 4-byte AS number by default unless it is unsuitable. An LIR requesting a 2-byte AS number would need to demonstrate that one (or more) of their peers or transit providers are unable or unwilling to support a 4-byte AS number. 4.2 An LIR can demonstrate the need for a 2-byte AS number by submitting supporting documentation such as an email or trouble ticket stating that that the peer or provider is unable or unwilling to accept a 4-byte AS number. 4.3 The intermediary stage would commence 1 July 2009. The new timeline would be: 1 January 2007 APNIC assigns two-byte AS numbers by default APNIC assigns four-byte AS numbers on request. 1 January 2009 APNIC assigns four-byte AS numbers by default. APNIC assigns two-byte AS numbers on request. 1 July 2009 APNIC assigns four-byte AS numbers by default. APNIC assigns two-byte AS numbers if a four-byte AS number is demonstrated to be unsuitable 1 January 2010 APNIC ceases to make any distinction between two- and four-byte AS numbers. APNIC assigns from an undifferentiated four-byte AS number pool. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - The greater awareness and the earlier delegation of 4-byte AS numbers is expected to create greater demand on Service Providers to support 4-byte AS numbers. - More 4-byte AS numbers will be seen in routing tables. - Makes more service providers aware of their requirement to support 4-byte AS numbers earlier. - The extent of people unwilling to support 4-byte AS numbers will be known and documented. This will provide feedback as to the state of deployment and readiness to begin general assignments. - Provides more pressure to vendors and Service Providers to implement 4-byte code. - Will encourage Service Providers to request 4-byte code from their vendors, and provides more pressure to equipment vendors and Service Providers alike. - Increase the chance of an orderly transistion when 4-byte AS numbers are delegate as part of the general pool. - Creates greater awareness of the need to support 4-byte AS numbers as more parties become in involved in the application for a 2-byte AS number. 5.2 Disadvantages - Could create greater administrative overhead on APNIC staff. 6. Effect on APNIC members --------------------------- The proposal impacts all APNIC members. 7. Effect on NIRs ------------------ The proposal has no direct impact on NIRs, but impacts members of NIRs in the same way it impacts APNIC members. 8. References ------------- [1] Policies for Autonomous System number management in the Asia Pacific region http://www.apnic.net/policy/asn-policy.html _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair(a)apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair

5 4

Re: [sig-policy] prop-066: Ensuring efficient use of historicalIPv4 resources
by Ray Plzak 27 Jul '08

27 Jul '08

The policy document states, "The other RIRs do not currently include historical allocations when assessing requests for allocations from the RIR pools." This statement is incorrect regarding the ARIN region. ARIN has always asked for utilization for all previous allocations and assignments. This includes all legacy holdings. Ray From: sig-policy-bounces(a)lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of zhangjian Sent: Tuesday, July 22, 2008 04:10 To: 'APNIC Policy SIG List' Subject: [sig-policy] prop-066: Ensuring efficient use of historicalIPv4 resources Dear SIG members The proposal 'Ensuring efficient use of historical IPv4 resources' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 26 in Christchurch, New Zealand, 25-29 August 2008. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-066-v001.html 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? Randy and Jian ________________________________________________________________________ prop-066-v001: Ensuring efficient use of historical IPv4 resources ________________________________________________________________________ Authors: Brenda D. Tarimel btarimel(a)palaunet.com Philip Smith pfs(a)cisco.com James Spenceley james(a)vocus.com.au Version: 1 Date: 22 July 2008 1. Introduction ---------------- This is a proposal to include all historical address allocations when assessing a network's eligibility for more IPv4 addresses. 2. Summary of current problem ------------------------------ The unallocated pool of IPv4 addresses is predicted to run out within the next few years. As the unallocated pool dwindles, it is important to ensure that the remaining IPv4 addresses are allocated responsibly and fairly. Currently, when LIRs apply for new IPv4 allocations from APNIC, they only have to include the past allocations they have received from APNIC as part of the documentation and justification process. They do not have to declare any historical addresses [1] they may have received prior to receiving address space from APNIC. As a result of this, there is a large amount of historical IPv4 address space where little or nothing is known about its use. At the moment LIRs can receive more scarce IPv4 address space from APNIC while at the same time hoarding unused historical address space. This uses up the remaining IPv4 pool more rapidly than is really necessary. 3. Situation in other RIRs --------------------------- The other RIRs do not currently include historical allocations when assessing requests for allocations from the RIR pools. This proposal has not been submitted to any other region. 4. Details of the proposal --------------------------- This is a proposal to modify the criteria for receiving IPv4 address space so that both historical addresses and previous allocations are included. - This proposal applies to all historical IPv4 resources registered in the APNIC Whois Database. - Historical IPv4 resources that are not managed under the existing historical maintenance or transfer policies will remain free of fees. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Ensures that organisations are using scarce IPv4 address space resources to the fullest extent possible. - The utilisation of historical IPv4 addresses will be brought into line with current best practices for address management. - The remaining IPv4 free pool will be delegated to LIRs that have a genuine need for IP addresses. 5.2 Disadvantages - Organisations can no longer hoard unused address space while at the same time receive more scarce address space from APNIC's pool. - LIRs with historical IPv4 addresses may find it time consuming to change network architecture that uses historical IPv4 addresses in an inefficient manner. However, the difficulties felt by these networks is outweighed by the greater benefits of ensuring that the remaining IPv4 address space is delegated to networks with a genuine need for IPv4 allocations. 6. Effect on APNIC members --------------------------- APNIC members who have applied best practices for address space management for all their address ranges will not be affected. APNIC members who have not applied best practices for all their address ranges may need to modify their management of historical addresses before they can qualify for IPv4 addresses from APNIC. There will be no impact on fees paid by members. 7. Effect on NIRs ------------------ The proposal has no direct impact on NIRS, but impacts members of NIRs in the same way it impacts APNIC members. 8. References -------------- [1] Historical resources definition http://www.apnic.net/policy/historical-resource-policies.html#2.2 _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair(a)apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair

3 2

Re: [sig-policy] [apnic-talk] [Apnic-announce] AS number change could affectInternet routing from 1 January 2009
by Jeffrey A. Williams 24 Jul '08

24 Jul '08

Dear secretariat and all, I share these concerns to which you properly mention. secretariat(a)apnic.net wrote: > ________________________________________________________________________ > > AS number change could affect Internet routing from 1 January 2009 > ________________________________________________________________________ > > Manufacturers urged to upgrade routers and network management > software to support the use of four-byte Autonomous System numbers > by 1 January 2009. > > Regional Internet Registries (RIRs), including Asia Pacific Network > Information Centre (APNIC), have warned that routers and network > management software should be upgraded ahead of the increased > distribution of four-byte (also known as 32-bit) Autonomous System (AS) > numbers. > > AS numbers are a vital part of the Internet's core routing system, the > Border Gateway Protocol (BGP). With existing two-byte AS numbers > predicted to run out in early 2011, RIRs will issue four-byte AS numbers > by default (unless otherwise specifically requested) beginning 1 January > 2009, as the next phase of a transition from two- to four-byte numbers. > Following a globally coordinated policy, RIRs began allocating four-byte > AS numbers by request only in January 2007; January 2009 marks the > transition to allocating four-byte AS numbers by default. > > Without timely support from vendors, network operators risk having > routers and network administration systems that won't accept the > expanded four-byte number format. As such, the RIRs urge operators to > verify their vendors' routers will support four-byte AS numbers. > > Geoff Huston, Chief Scientist at APNIC, expressed severe concerns over > failure to prepare for four-byte AS numbers: "AS numbers are often used > to identify external relationships, set routing attributes, and manage > traffic. Learning from our current experiences with IPv6 preparation > issues, Internet engineers designed four-byte AS numbers to be backward > compatible with much of the installed network infrastructure. But new > entrants and networks that are expanding or merging will need new AS > numbers and as of 1 January 2009 these will be, by default, four-byte AS > numbers. If router software and support systems in critical parts of the > Internet's infrastructure aren't upgraded by January, we'll encounter > some significant network routing problems. We're extremely concerned > that a lot of routers and network management software out there cannot > and will not be able to recognize four-byte AS numbers". > > An Autonomous System (AS) is a collection of networks, or routers, > administered as a group sharing a common set of routing policies, each > defined with a unique number, or AS number. Massive Internet growth has > depleted the existing pool of two-byte AS numbers (65,536 numbers in > total). As a result, engineers have expanded the AS number space from > two bytes to four-bytes, to include over 4 billion AS numbers. Some > routers do not currently support the use of four-byte AS numbers. > > To help vendors understand what they need to do to provide four-byte AS > number support and to help network operators find products that support > four-byte AS numbers, APNIC has set up a special website at: > > http://wiki.icons.apnic.net/display/ASN/Home > > > Yours sincerely > > ________________________________________________________________________ > > APNIC Secretariat > 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 > ________________________________________________________________________ > > ------------------------------------------------------------------------ > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce > > ------------------------------------------------------------------------ > _______________________________________________ > apnic-talk mailing list > apnic-talk(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy July 2008