sig-policy August 2004

sig-policy@lists.apnic.net

13 participants
14 discussions

RE: [sig-policy] Policy SIG Proposal - HD ratio for IPv4 allocations
by Anne Lord 26 Aug '04

26 Aug '04

Hi Izumi, > Let me introduce some of the discussions we had in JP about the > proposal. The general vibes so far is that there are no strong support > for the proposal. > Thanks very much for the feedback, very useful. I have tried to answer some of the feedback - in the hope that this is useful to the discussion. > > Comments received on our mailing list are: > > * Support the concept of considering heirachical management, but > concerned that utilization rate may be too low for large > allocations > If there is support and acknowledgement that hierarchical management imposes an overhead in 'efficiency' of managing the address space, then this is agreement with the basic premise of the proposal and an implicit acknowledgement that there is a problem with the current system. > I understand that there may be concern regarding the utilisation rate > in the proposal but this is meant to be a realistic measure of what is > possible. However, having said this in IPv6 the HD ratio value is 0.8, > in IPv4 it is proposed at 0.96 which is much more conservative. It could > be placed at a value which is yet more conservative. > > > * The idea of HD-ratio is conceptualistic. It does not necessarily > match the actual operation and it is difficult to judge if it is an > appropriate way to measure utilization > The logarithmic model and values used actually show a gradual decrease in efficiency, the larger and more complex the network. This is central to the proposal - the gradual decrease in "efficiency", the larger the network. If you accept that there is an overhead imposed on hierarchically managed address space then the question becomes what model fit this best? It has been observed that the logarithmic model is a good one (when compared to all others). Given this, I am not sure how a fixed utilisation fits, given that this implies a linear relationship - where there is no allowance made for overhead imposed by the hierarchy of managing a larger address block? > * Subsequent allocation rate should be considered in terms of how > much free address space should be secured in order to accmodate > customer increase between making an allocation request and > receiving the actual allocation. > I dont understand this comment. Could you explain it a bit more please? I thought the subsequent allocate rate was considered, in that if you are using the address space quickly, you will receive a larger subsequent allocation. > > It could be possible that ISPs with small allocations also have > problems as they have less capacity to accomodate large increase in > the number of subscribers. How about applying a flat rate with > lower percentage? (No comments on this suggestion from the others) > Applying a flat rate with a lower percentage basically rejects the premise of the proposal. It is unecessarily lenient to smaller guys and does not change address the problem with the larger networks. > > * It disadvantages star-up ISPs when conditions are not consistent in > areas which cannot be improved by efforts, such as service quality, > price, etc > I'm not sure how i can answer this except by saying that in the current situation the feedback to the Secretariat has been that those with larger networks feel they are disadvantaged. > > I think the general feeling at the moment is that there are no strong > opposition about reviewing the current utilization rate, but not sure > why HD-ratio should be applied(the concept already explained). > > Okay I understand. > > I have asked on our ML yesterday whether there is anybody who would > have a problem if HD-ratio is *NOT* applied, and there are no comments > on this yet. > > Thanks Izumi. It would be helpful to ask too if anyone has a problem if it is applied. Anyways thank you for the feedback and I look forward to hearing more. Best wishes, Anne -- > > > To confirm the situation, do large ISPs in the rest of AP consider > they would be strongly disadvantaged and have a problem if HD-ratio is > NOT applied, or would it meet their needs by simply lowering the flat > utilization rate? > > I note from Paul's explanation that some LIRs in the region are having > problems with the current rate and I do see that this should be > addressed in some way. > > I would like to know what is the difference in the situation between > JP and the rest of the region. > > > Izumi > JPNIC > > > From: APNIC Secretariat <secretariat(a)apnic.net> > Subject: [sig-policy] Policy SIG Proposal - HD ratio for IPv4 allocations > Date: Wed, 04 Aug 2004 15:25:03 +1000 > > > Dear All, > > Please find below a policy proposal for the forthcoming Policy SIG, to be > presented at APNIC18 in Fiji. > > The ideas in this proposal were presented at APNIC16 as an informational > item ("HD ratio for IPv4") on the agenda. You can find details of the > presentation, transcripts of the discussions and minutes at: > > http://www.apnic.net/meetings/16/programme/sigs/policy.html > > Your comments and feedback on this proposal are very much appreciated on > this mailing list. > > Best wishes, > ______________________________________________________________________ > APNIC Secretariat <secretariat(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064, Australia Fax: +61-7-3858-3199 > > See you at APNIC 18 Nadi, Fiji, 31 August-3 September 2004 > www.apnic.net/meetings > ______________________________________________________________________ > > > ______________________________________________________________________ > > prop-020-v001: Application of the HD ratio to IPv4 > ______________________________________________________________________ > > > Proposed by: Paul Wilson and Anne Lord, APNIC Secretariat > Version: 1.0 > Date: 4 August 2004 > > > 1 Summary > ------------- > > Internet address space is managed hierarchically, by allocation from > IANA to RIRs and from RIRs to LIRs (ISPs), and by assignment from LIRs > to infrastructure and customer networks. At each level of allocation or > assignment some address space may be reserved for future expansion > and/or efficient aggregation. As more hierarchical levels are > introduced, the overall efficiency of utilisation of the address space > will decrease. > > > The HD ratio (Host-Density ratio) has been proposed as a mechanism for > measuring the utilisation of addresses within hierarchically-managed > Internet address blocks [RFC 3194]. A given HD ratio value corresponds > to a percentage utilisation which decreases as the size of the address > space grows, thus allowing for the decreasing management efficiency > which is described above. > > The HD ratio is used as the utilisation metric for address space under > the current IPv6 management policy [ipv6-address-policy]. According to > this policy, a block of IPv6 address space is considered to be utilised > when its HD ratio reaches 0.80. This value is said to represent a > conservative but manageable figure ("values of 80% or less correspond to > comfortable trade-offs between pain and efficiency" [RFC 3194]). > > This document proposes the use of the HD ratio for measurement of IPv4 > utilisation, for the same purpose of determining when a given block of > address space should be considered as fully utilised. The proposed value > of the HD ratio for IPv4 is 0.96. > > > 2 Background and problem > ---------------------------- > > Under the current management framework for IPv4 address space > [ipv4-address-policy] a block of IPv4 addresses is considered "utilised" > when 80% of the addresses within the block have been allocated or > assigned. This measure is applied equally for all address blocks, > regardless of size. > > Current policies assume a hierarchical system of address space > delegation (from IANA to RIRs to LIRs to customers, as described above), > but they make no allowance for hierarchical management within allocated > address space. For LIRs in particular, a hierarchical approach is often > required for assignment of address space to service elements such as > customer networks, individual PoPs, regionalised topologies, and even > distinct ISP products. Small network infrastructures may require simple > hierarchies, but large infrastructures can require several levels of > address space subdivision. These levels of hierarchy are "hidden" in > terms of recognition by the current RIR policy framework, and highly > constrained by the 80% utilisation requirement. As a result, management > of large blocks is often extremely difficult, requiring large internal > routing tables and/or frequent renumbering of internal address blocks. > > One of the goals of the RIR system is to avoid unnecessary depletion of > IPv4 address space, and the 80% utilisation requirement is justified on > that basis. However address management policies must also be practical > in terms of management overhead imposed. It may be argued that when > large address spaces are involved, the "80% rule" imposes unreasonable > management overheads on an LIR. > > A more reasonable approach should impose a more uniform degree of > management overhead, rather than penalising the holders of large address > blocks. This is achievable to some degree by basing utilisation > requirements on the HD ratio rather than the fixed percentage-based > measure which is in use today. > > > 3 Proposal > -------------- > > In recognition of the problems outlined above, it is now proposed to > consider replacing the current fixed percentage based utilisation > requirement for IPv4 address space with an HD ratio based requirement. > > 3.1 The HD ratio > ----------------- > > > According to RFC3194, The HD ratio is calculated as follows: > > HD = log(U)/log(S) > > Where: > > S is the size of the address block concerned, and > U is the number of addresses which are utilised. > > Note: Under the current IPv4 policy framework, addresses are > considered to be utilised once they are assigned or sub-allocated > by the LIR. > > 3.2 Selection of HD ratio value > -------------------------------- > > The appropriate HD ratio value should be decided on a rational > basis. In order to do this, we make certain assumptions about the > depth of "hidden" hierarchy involved in managing address blocks of > various sizes. If we assume that 80% utilisation is achieved at > each level of this assumed hierarchy, then the overall utilisation > can be easily calculated. > > The following table proposes a set of hierarchical depths which may > be reasonably expected within address spaces of given sizes. If 80% > utilisation is achieved at each hierarchical level, then the > overall utilisation will be (0.80 to the power of "n"); and from > this value, corresponding HD ratio levels can then be calculated. > > Size range Depth Utilisation HD ratio > (prefix) (n) (0.80**n) (calculated) > ---------- ----- ----------- ------------ > > /24 to /20 1 80% .960 to .973 > /20 to /16 1.5 72% .961 to .970 > /16 to /12 2 64% .960 to .968 > /12 to /8 2.5 57.2% .960 to .966 > /8 to /4 3 51.20% .960 to .966 > > The depths of hierarchy listed above are based on simple > assumptions about the likely size and structure of LIRs holding > address blocks of these sizes. From the table, a rational HD ratio > value may be chosen as 0.96 (a round figure which occurs within > most of the above ranges). For this value, the following table > gives the utilisation requirement for IPv4 address blocks from /24 > to /8. > > IPv4 Addresses Addresses Util% > prefix total utilised > ------ --------- --------- ------ > > 24 256 205 80.11% > 23 512 399 77.92% > 22 1024 776 75.79% > 21 2048 1510 73.71% > 20 4096 2937 71.70% > 19 8192 5713 69.74% > 18 16384 11113 67.83% > 17 32768 21619 65.98% > 16 65536 42055 64.17% > 15 131072 81811 62.42% > 14 262144 159147 60.71% > 13 524288 309590 59.05% > 12 1048576 602249 57.43% > 11 2097152 1171560 55.86% > 10 4194304 2279048 54.34% > 9 8388608 4433455 52.85% > 8 16777216 8624444 51.41% > > Note: This table provides values for CIDR blocks only, however for > non-CIDR blocks the same calculations can be applied to produce > equally meaningful results. > > > 4 Implementation > ------------------- > > This proposal will impact on procedures for allocation from APNIC to > LIRs. > > 4.1 RIR-LIR procedures > ----------------------- > > The impact of the proposal on the RIR-LIR administrative procedures > would be to replace the current 80% utilisation requirement, with a > 0.96 HD ratio requirement. > > By way of examples, an LIR holding a total address space equal to a > /16 would be able to receive more address space when they had > allocated or assigned 64.17% of that space; while an LIR holding a > /9 would be able to receive more space when they had allocated or > assigned 52.85% of their address space. > > The HD ratio calculation is trivial, but slightly more complex than > the existing 80% calculation. Some APNIC members may in some > circumstances require extra assistance, however for those using > MyAPNIC, the calculation would be automatic and require no > additional effort. > > 4.2 Implementation timeline > ---------------------------- > > If implemented, this policy could be effective within 3 months of the > implementation date. > > > 5 References > --------------- > > [RFC 3194] "The Host-Density ratio for address assignment efficiency: An > update on the H ratio", A. Durand, C.Huitema, November 2001. > > [ipv6-address-policy] APNIC document: "IPv6 address allocation and > assignment policy" http://www.apnic.net/docs/policy/ > > [ipv4-address-policy] APNIC document: "Policies for IPv4 address space > management in the Asia Pacific region" http://www.apnic.net/docs/ > policy/add-manage-policy.html > >

2 1

IPv6 address space management - informational
by APNIC Secretariat 23 Aug '04

23 Aug '04

Dear Colleagues, The following informational paper "IPv6 address space management" is intended to augment the policy proposal [prop-005-v002] "Internet Assigned Numbers Authority (IANA) policy for the allocation of IPv6 blocks to Regional Internet Registries". Discussion and comments on both are most welcome. Kind regards, APNIC Secretariat ______________________________________________________________________ IPv6 address space management ______________________________________________________________________ Written by: Geoff Huston, APNIC Secretariat Version: 1.0 Date: 19 August 2004 Abstract -------- This document provides a description of the management process that is proposed for use by the Regional Internet Registries (RIRs) in managing global unicast IPv6 address resources. The document describes the proposed process of address allocation that is undertaken by the Internet Assigned Numbers Authority (IANA) to an RIR, as well as the RIRs' proposed address management process, whereby address allocations are made from the managed address block according to a "sparse allocation" algorithm. This sparse allocation management process is designed to maximise aggregation of address space within the confines of each allocated block, ensuring that most ISPs and Local Internet Registries (LIRs) retain a single aggregate address prefix as they grow. This paper is intended to augment previous work, in particular the proposal "Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries" [1]. 1. Overview -------------- Under the system of management of global IP address space, RIRs are responsible for the allocation of address space to organisations within their respective geographic regions. RIRs receive address space periodically from the IANA, and then manage that address space as a local pool from which subsequent allocations are made to organisations within their regions. RIRs individually use various allocation techniques within their respective pools of address space (including sparse allocation techniques), in an attempt to maximise the likelihood that the initial and subsequent allocations to ISPs are able to be aggregated into a single unit. Under this system, aggregation of allocated address space is limited by several factors. In the context of management of IPv4 addresses these factors include the requirement for RIRs to utilise their existing pool of addresses to a level of 80% prior to requesting more address space from IANA, as well as the relatively small size of the address pools held by RIRs at any one time. Over a period of several years, a single large ISP may receive a number of discontiguous allocations from its RIR. The management system for IPv6 described here avoids these problems of undue levels of fragmentation of the IPv6 address space through the allocation of address blocks from the IANA to the RIRs that take into account both the RIRs' sparse allocation practice and the desire to undertake ISP and LIR allocations from an address block that can preserve aggregation windows per ISP or LIR for periods of between one and two years per allocated entity. The sparse allocation management scheme is intended to maximise the room for future expansion of each allocation as a single aggregateable block. The existing IPv6 address allocations use a threshold metric of address utilisation efficiency termed the "HD ratio" [2]. This metric takes into account a commonly observed aspect of address deployment that the efficiency of a deployment drops as the size of the deployment increases. It is proposed that IANA allocates address blocks to the RIRs using an allocation unit of a /12. Further allocations will be made from IANA to the RIRs such that the RIR will have a minimum pool of allocateable addresses that allow at least a further 36 months of allocations at the average allocation rate of the previous 12 months. The RIR will manage each allocated address block according to methods of its own choosing, including but not limited to the sparse allocation mechanisms described in this document. 2. IP address allocation framework ------------------------------------- The framework of management of IPv6 address space is described in a number of source documents. 2.1 Global unicast address space ---------------------------------- The range of addresses managed within this framework is the address pool termed the "global unicast" IPv6 address pool. This pool is defined in RFC 3513 [3] as the address block with the prefix 2000::/3: "The rest of the global unicast address space (approximately 85% of the IPv6 address space) is reserved for future definition and use, and is not to be assigned by IANA at this time." (RFC 3513) 2.2 IANA allocations to RIRs ------------------------------ Allocations of global unicast address space to RIRs are described by RFC 2450 [4]. This document uses the terminology of Format Prefix (FP), Top Level Aggregation Identifier (TLA), and Sub Top Level Aggregation Identifier (Sub-TLA). The structure is these fields is defined in RFC 2450 as follows: | 3 | 13 | 13 | 19 | +----+----------+---------+---------------+ | FP | TLA | Sub-TLA | NLA | | | ID | | ID | +----+----------+---------+---------------+ The IANA-to-RIR allocation framework is as follows: "The IANA will assign small blocks (e.g., few hundred) of Sub-TLA ID's to registries. The registries will assign the Sub-TLA ID's to organizations meeting the requirements specified in Section 5.2. When the registries have assigned all of their Sub-TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous." (RFC 2450, section 5.1) A Sub-TLA in this context is a /29 address block, and "a few hundred" Sub-TLAs is either 256 or 512 Sub-TLAs if using a bit-aligned address management regime. This document appears to propose IANA assignments using a /21 prefix (256 Sub-TLAs) or a /20 prefix (512 Sub-TLAs). The initial IANA allocations have been documented in RFC 2928 [5]. These initial assignments were smaller than that proposed, and the document notes that: "The initial Sub-TLA ID assignments to IP address registries are in blocks of 64 Sub-TLA IDs." (RFC2928) These initial allocations were in units of /23 address blocks. The IANA IPv6 Sub-TLA assignment registry [6] lists these allocations, and also all subsequent allocations, with a common allocation unit of a /23 from the sub-TLA assignment registry. It is noted that the terminology of TLAs and Sub-TLAs has been deprecated within the context of the IPv6 addressing architecture specifications [3], but the practice of IANA IPv6 allocations to RIRs using a /23 address block remains in place. 2.3 IPv6 address allocation and assignment policy --------------------------------------------------- IPv6 allocations from RIRs to LIRs and ISPs is described within the framework of a coordinated policy across the RIRs [7]. The goals of the address management function include an outcome of address aggregation: "RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held." (IPv6 address allocation and assignment policy, Section 3.4) And in reference to potential conflicts of goals: "In IPv6 address policy, the goal of aggregation is considered to be the most important." (IPv6 address allocation and assignment policy, Section 3.8) The document references the minimum size of IPv6 allocations as a /32, and proposes that the determination of the allocation will be based on the application of the HD ratio metric to the applicant? proposed IPv6 deployment, with a threshold HD ratio value of 0.8 being specified as a means of determining an initial allocation size. However it is envisaged within this policy framework that established ISPs would be eligible for potentially much larger initial allocations. "Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure." (IPv6 address allocation and assignment policy, Section 4.4) The RIR allocation to LIRs and ISPs uses a doubling function for subsequent allocations, namely: "When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left." (IPv6 address allocation and assignment policy, Section 5.2.3) 3. Sparse allocation address pool management ----------------------------------------------- Allocations from the RIRs' IPv6 managed address pools may be determined according to a sparse allocation (or "binary-chop") algorithm, designed to maximise aggregation of address blocks allocated. In order for this method to produce effective results in the long-term, the source address block from which allocations are made should be as large as reasonably possible. 3.1 Sparse allocation algorithm --------------------------------- Under the sparse allocation system, the start addresses for successive allocations are generated according to a binary chop algorithm, as illustrated below. For example, within a 6-bit address space, the first 8 start addresses would be as follows: Seq# Address Decimal ---- ------- ------- 1 000000 00 2 100000 32 3 010000 16 4 110000 38 5 001000 08 6 101000 40 7 011000 24 8 111000 56 The following illustration shows this 6-bit address space (comprising 64 locations), and the location of the first 16 allocations to be made (according to their sequence number), according to the above list. |-------|-------|-------|-------|-------|-------|-------|-------| 1 | | | 2 | | | | 3 | | 4 | 5 7 6 8 The effect of the sparse allocation algorithm is to successively subdivide each remaining block of unallocated address space into 2 equal parts, the first being left to accommodate growth of an existing allocation, and the second being made as a new allocation. As more allocations are made from the address block the free space will become progressively fragmented, and the maximal size of the free block pool will decrease, as the progressive operation of this algorithm ensures that the size of the largest free block is at most 1 bit longer than the smallest. This implies that a large address pool can become excessively fragmented in response to a sustained sequence of minimal address allocation requests, leading to an inability to meet a large allocation request, or an inability to meet a requirement to undertake an additional allocation in an adjacent address block. 3.2 Avoiding fragmentation ---------------------------- Depending on the rate of allocation, and the rate of growth of individual allocations, the avoidance of fragmentation will need to be addressed eventually. A technique is proposed here that attempts to mitigate the extent to which address pool fragmentation causes fragmentary (non-aggregateable) allocations. The information used in this approach is the growth rate of each allocation. The modified selection algorithm is to perform a binary chop allocation such that the allocation maximises the time before the first "meeting", where an allocation immediately adjoins the next allocation in sequence. Growth rates are derived from reallocation frequency, where reallocations have been performed, and where no growth rate information is available (in the case of initial allocations) a 100% growth rate per 2 years is assumed. For each allocation address block a growth rate is calculated. The associated aggregate allocation lifetime for the block can be calculated by dividing the remaining adjacent unallocated space by the growth rate. The selection aggregate allocation lifetime can be calculated by performing a binary chop on the unallocated space and dividing the remaining allocation space by the growth rate. To perform an allocation selection each unallocated space is tested by performing a binary chop and calculating the selection aggregate allocation lifetime on the existing allocated block, and on the created initial allocation block. The minimum of these two time values is the lifetime for that particular selection position. The selection position that offers the maximal lifetime is the one used for this allocation. A statement of the rate-controlled sparse allocation algorithm is as follows: For each allocation A[i] the corresponding expansion slot, X[i], is subdivided according the to the binary chop, resulting in a new expansion slot X'[i] and an initial allocation window W[i]. If W[i] is less than the required initial allocation size, A[x] then the associated slot lifetime, P[i], is assigned a value of 0. Otherwise the growth rate of A[i] , R[i], is used. The lifetime for A[i] is calculated as X'[i] / R[i]. The rate of the new allocation, R[x], is calculated as A[x]/year. The lifetime of using W[i] for this new allocation, T[x] is calculated as (W[i] ?A[x]) / R[x]. The lifetime associated with selection of slot i for this new allocation, P[i], is the minimum of T[i] and T[x]. The selected slot is the value of i that maximises the value of P[i] over all i. In order to ensure that sufficient space is held in reserve for larger allocations the address pool may be seeded with a number of large allocation reservations, useable only for allocations of a certain minimum size. The outcomes of this algorithm is that smaller allocations tend to cluster together, while larger initial allocations tend to have their expansion window held intact for longer periods. This, in turn, preserves the ability of the address pool to service expansion windows in a more effective manner than a simple binary chop algorithm. 4. IANA allocation size -------------------------- The requirements relating to the size of the address block allocated by IANA to a RIR include that it should be sufficient for the RIR to service all forms of allocations, and make reasonable allowance for additional allocations that preserve aggregation properties. The anticipated timeframe of utility for each allocated block is 36 months, using the average assignment rate of the previous 12 months. A proposed IANA allocation size of a /12 is reasoned using 2 distinct comparisons with the current IPv4 allocation system. The first comparison considers the requirement for address space from ISPs and LIRs (namely the "demand side"), while the second considers the allowable allocations which may be made by IANA from the total available space (namely the "supply side"). 4.1 ISP address space requirements the demand side ------------------------------------------------------ The current IANA IPv6 allocation unit of /23 is the equivalent of 33,554,432 end customer /48 assignments, while the current IPv4 allocation unit of /8 corresponds to 16,777,216 end customer assignments (assuming an end customer assignment unit of /32). The consumption rates of these address blocks differ greatly between IPv4 and IPv6. IPv4 address management policies assume a constant address utilisation rate of 80% as a threshold for further allocations. An IPv4 deployment encompassing some 800,000 end customer /32 assignments, for example, would therefore utilise a /12 allocation, or 1/16 of the IANA IPV4 allocation unit. The same ISP could request an allocation of IPv6 address space based on a deployment of IPv4 that entails some 800,000 customer assignments. The HD ratio applied to this scenario produces the outcome that the allocation size to the ISP is a /23, which is equal the entire IANA allocation to the RIR. In order to allow aggregation of a subsequent allocation, the allocating RIR, according to this policy would allow for the possibility of a doubling of this assignment, so that the RIR would normally reserve the adjacent /23 address block in addition to the initial /23. In order for the RIR to be able to service the same profile of requests that it services from the /8 IPv4 IANA allocation, the equivalent IPv6 allocation needs to be significantly larger than a /23. The equivalent of a /8 allocation in IPv4 using a 80% address utilisation efficiency is a /18 allocation in IPv6, using an HD ratio value of 0.8. 4.2 IANA address space availability ?the supply side ----------------------------------------------------- The current IANA IPv4 allocation to the RIRs is 1/256 of the entire IPv4 address space, or 1/220 of the IPv4 Global Unicast space. An equivalent IPv6 allocation from the currently assigned Global Unicast space is a /11 address block. The objectives here are to set an allocation size that allows the RIR to service allocation requests from the IANA-allocated address blocks within the allocation policy framework, allowing each LIR and ISP the potential for further allocations within an encompassing aggregate address block; and to be able to service such requests without constant referral to IANA for further allocations. The IPv6 framework is proposed to set an allocation size equivalent to at least 36 months expected utilisation, based upon the previous 12 months RIR allocation activity. The basis for this proposal is to allow ISPs and LIRs to achieve very high levels of aggregation within the address space, effectively limiting the long term fragmentation-induced overheads that would otherwise be placed on the IPv6 inter-domain routing system. It is notable that the current IPv4 allocation size of /8 corresponds to an administrative boundary for delegation of "reverse" DNS zones under the in-addr.arpa tree. This allows entire zones to be delegated by the IANA to each RIR, without the need for sharing of zones between RIRs. This administrative factor should also be considered in determining the IPv6 allocation size. 4.3 Simulation of IPv6 allocations ---------------------------------- Simulation of the operation of an RIR IPv6 registry has been undertaken using historical IPv4 allocation data as the seed data. The simulation has assumed that the underlying network metrics for IPv4 allocations have been based on an 80% uniform host density metric. This has been translated to a derived customer count, that, in turn, has been used to seed an HD ratio-based allocation with each IPv6 customer receiving a /48 and the minimum IPv6 allocation size from the RIRs being a /32. The simulation has assumed that in the steady state some 75% of allocations are additional address allocations to existing ISPs and LIRs, and that the average lifespan for each allocation is 1 year, with a randomised range from 6 months to 2 years and 6 months. Using IPv4 delegation data published by ARIN, and the above simulation conditions a /12 IP address pool managed using rate managed sparse allocation over a 36 month period will have 7,269 transactions, with 3,571 ISPs and LIRS. A /12 IPv6 address block will be 48% allocated, with only 135 allocations failing to be allocated from ISP's aggregated assignment windows. The average assignment is a /25.5 address block and the largest single allocation space available at the end of the simulation is a /23. All allocations were serviced from the block, and there were no failures to find space. A comparable simulation using the RIPE NCC delegation data indicates a similar picture, with 4,273 transactions to 2,023 ISPs and LIRS. The block was filled to 51% and only 144 allocations failed to be allocated from the ISP aggregate allocation window. The average assignment is a /24.7 and the largest remaining single window of a /23. The simulations indicate that the rate-managed sparse allocation mechanism can provide effective aggregation of address blocks over extended periods, and, under the current framework of HD ratio-based address allocations, a /12 is the minimum address block size that can provide an RIR with effectively aggregated allocation outcomes over a period of a 36 month operational window. 4.4 Conclusion -------------- In considering the spectrum of size of current IPv4 network deployments, and the requirement to allow reallocations within the same aggregate window, the minimum IANA IPv6 allocation size should be in a range of between a /10 and a /18. A /10 divides the current IPv6 global unicast space into 128 allocation units (or the entire IPv6 space into 1024 allocation units), while a /18 creates 32,768 such allocation units. The midpoint is a /13 or /14, dividing the current IPv6 global unicast address space into 1024 or 2048 allocation units. An IANA allocation unit of a /13 allows an RIR to service requests that include a small number of allocations for large ISPs, as large ISP would encompass some 10**7 customers, equating to an initial allocation of a /18 with an associated initial expansion window of a further 2 bit positions, or a /16. A /13 allocation would allow each RIR, if it chooses, to operate a sparse allocation address management system that would allow significant capability to ensure aggregateability of allocated address blocks. However, using IPv4 allocation data and an allocation simulation, it is evident that a /13 would not be adequate for 36 months of RIR operation. If effective aggregation is required over a 36 month window it is appropriate to propose use of a /12 as the IANA allocation unit. The issue of administrative management of reverse DNS zones should also be considered, particularly considering the importance of stability of these zones at points close to the root. It is proposed that the IANA allocation unit to RIRs should be equal to a /12, which represents the operational of a sparse allocation registry with aggregated outcomes over a 36 month window, as well as representing the closest administrative boundary for reverse DNS delegation. 5. IPv6 address space management process ------------------------------------------- It is proposed that: - IANA shall allocate address blocks to the RIRs using an allocation unit of a /12 address block. Further allocations will be made from IANA to the RIRs such that the RIR will have a minimum pool of allocateable addresses that encompass at least a further 36 months of allocations at the average allocation rate of the previous 12 months without compromising the ability to service allocation extension requests within aggregateable blocks according to the sparse allocation procedure. - The RIR may choose to manage each allocated address block using sparse allocation mechanisms described in this document. If so, each allocation would be performed in a manner such that allocation selection preserves the longevity of the usefulness of the address block with respect to both servicing initial allocations and servicing allocation extensions within aggregation block boundaries by using a rate-governed window selection algorithm. References ---------- [1] [prop-v005-v002] Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries http://www.apnic.net/mailing-lists/sig-policy/archive/2004/08/ msg00003.html [2] RFC 3914, The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio [3] RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture [4] RFC 2450, Proposed TLA and NLA Assignment Rules [5] RFC 2928, Initial IPv6 Sub-TLA Assignments [6] IANA IPv6 Top Level Aggregation Identifier Assignments http://www.iana.org/assignments/ipv6-tla-assignments [7] IPv6 Address Allocation and Assignment Policy http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02

1 0

Forwarded reply from Gordon Bader
by APNIC Secretariat 20 Aug '04

20 Aug '04

The email below is forwarded to the list on behalf of Gordon Bader. He is now subscribed to the list. regards, APNIC Secretariat. >Date: Fri, 06 Aug 2004 07:15:16 -0700 >From: GB <gbader(a)cox.net> >To: Izumi Okutani <izumi(a)nic.ad.jp> >CC: secretariat(a)apnic.net, sig-policy(a)apnic.net, sig-policy-chair(a)apnic.net >Subject: Re: [sig-policy] SIG Policy Proposal 'Preventing the routing of >'dark' address space > >Good Morning Mr. Okutani and APNIC Secretariat, > > Thank you for reading the proposal and your associated questions on >the sig-policy proposal >'Preventing the routing of 'dark' address space'. I have responded in >line using the tag [Response] >below for each one of your concerns. I have also included an example. > >Izumi Okutani wrote: > > >Dear Gordon/APNIC secretariat, > > > > > >I understand the issue you have raised, but I still can't quite > >understand your proposal. > > > >Could you please clarify what specific actions you expect APNIC and > >possibily, the community members to take? > > > >I've also added my comments inline. > > > >From: APNIC Secretariat <secretariat(a)apnic.net> > >Subject: [sig-policy] SIG Policy Proposal 'Preventing the routing of > 'dark' address >space > >Date: Wed, 04 Aug 2004 17:39:27 +1000 > > > > > > > >>This proposal is being sent to the mailing list on behalf of Gordon Bader > >><gbader(a)cox.net>. Feedback and comments about this proposal are welcome on > >>this mailing list. > >> > >>regards, > >>APNIC Secretariat. > >>--- > >> > >> > >>______________________________________________________________________ > >> > >>prop-023-v001: A proposal to prevent the routing of "dark" address > >> space > >>______________________________________________________________________ > >> > >> > >>Proposed by: Gordon Bader > >> <gbader(a)cox.net> > >>Version: 1.0 > >>Date: 4 August 2004 > >> > >> > >>Introduction: > >> > >>"Dark" address space is unallocated IP address space. Bandwidth > >>originating from "dark" address space should not be routed at any level. > >> > >>Summary: > >> > >>Bandwidth originating from unallocated IP address space is being > >>used for SPAM. In addition, unallocated IP address space is being > >>used to host websites that support SPAM. > >> > >>APNIC has the ability to grant IP space. Given that ability, it also > >>has the inherent ability to remove what was granted. The implicit > >>grant of IP space, carries with it the ability to route, and route > >>in a "legal" manner. When "illegal" (dark address space) routing is > >>detected, then the price should be loss of the initial grant - in this > >>case the ability to operate which carries with it economic measures. > >> > >>Details: > >> > >>Routing tables should be configured for non routing (filtering) of > >>unallocated IP address space as well as allocated IP address space. > >>Traffic to and from unallocated (or allocated but unused) IP address > >>space should be dropped as soon as recognized, thus saving bandwidth up > >>channel. > >> > >> > >Are you proposing ISPs in the community to apply the above policy, or > >is this simply an explanation of something which should be done, and > >not a part of the proposal? > > > >If it's the first, I think it is out of scope of the address policy. > > >[Response] - Yes, I am essentially proposing the first at ALL levels of >routing. I do understand that >this would be larger than APNIC's reach and would need to be applied >Internet wide. I am proposing >this be applied to ALL who receive their IP address allocations from >APNIC directly or indirectly. >Included within the proposal are the Tier 1 backbone providers as well >as individual ISP. I have >attached an example of what I am proposing below. > >However I do believe that it would be within APNIC's address policy >because if APNIC >was able to initially assign the IP address space to begin with, APNIC >should be able to >remove the address space it originally assigned. > > > > > > > > >>Employ the basic law - what can be given, can be taken away. APNIC > >>should issue a warning first, followed by removal of IP space from the > >>offending ISP or entity at what ever level. IP addresses are provided > >>under a contract, thus using contract law, removal is possible. > >> > >> > >If the offending entities are using unallocated address blocks, I'm > >not sure what you mean by "removal". Would there be anything to remove > >if allocations were not made in the first place? > > > >I don't quite understand how APNIC can be invloved in this, and how > >effective it would be in addressing the problem. I hope you can > >clarify this a little bit more. > > >[Response] - The proposal I have submitted proposes the loss of IP >address space at the point >where routing "drops off" in to "dark space". Let me provide an actual >traceroute. As of a couple >of minutes ago, node 19 222.233.52.27 was still active. That is 6 days >after this traceroute was >taken. > >I received an "Failure to Delivery Notice" for an email that I had not >sent, that was a item of SPAM >that directed the reader to the IP address 222.233.52.27. > >=============== > 07/31/04 16:12:27 Fast traceroute 222.233.52.27 > Trace 222.233.52.27 ... > 1 10.84.224.1 12ms 13ms 17ms TTL: 0 (No rDNS) > 2 68.2.4.73 11ms 13ms 13ms TTL: 0 >(ip68-2-4-73.ph.ph.cox.net ok) > 3 68.2.0.37 14ms 11ms 12ms TTL: 0 >(ip68-2-0-37.ph.ph.cox.net ok) > 4 68.2.0.113 12ms 14ms 15ms TTL: 0 >(ip68-2-0-113.ph.ph.cox.net ok) > 5 68.2.14.13 14ms 16ms 14ms TTL: 0 >(chnddsrc02-gew0303.rd.ph.cox.net ok) > 6 68.1.0.168 14ms 15ms 13ms TTL: 0 >(chndbbrc02-pos0101.rd.ph.cox.net ok) > 7 64.154.128.29 17ms 15ms 16ms TTL: 0 >(p1-0.hsa1.phx1.bbnplanet.net ok) > 8 4.68.113.253 14ms 17ms 23ms TTL: 0 >(so-6-2-0.mp2.Phoenix1.Level3.net ok) > 9 64.159.1.30 25ms 25ms 22ms TTL: 0 >(as-0-0.bbr1.LosAngeles1.Level3.net ok) > 10 209.247.9.214 28ms * 25ms TTL: 0 >(so-7-0-0.gar1.LosAngeles1.Level3.net ok) > 11 4.68.127.134 25ms 25ms 31ms TTL: 0 >(att-level3-oc48.LosAngeles1.Level3.net ok) > 12 12.123.29.2 28ms 27ms 23ms TTL: 0 >(tbr1-p014001.la2ca.ip.att.net probable bogus rDNS: No DNS) > 13 12.123.199.185 25ms 23ms 26ms TTL: 0 (No rDNS) > 14 12.119.138.38 25ms 25ms 24ms TTL: 0 (No rDNS) > 15 210.180.97.21 181ms 105ms 161ms TTL: 0 (No rDNS) > 16 211.108.90.2 107ms 162ms 140ms TTL: 0 (No rDNS) > 17 211.108.63.138 145ms 171ms 146ms TTL: 0 (No rDNS) > 18 221.139.106.66 130ms 146ms 145ms TTL: 0 (No rDNS) > 19 222.233.52.27 141ms 145ms 94ms TTL: 49 (No rDNS) >================= > >You will notice that starting with node 15 the address space is un >allocated. Thus the last >legal space rests with node 14 which now has a problem with their >routing tables. >I am proposing that notification be given (in this case) to >12.119.138.38 "holder" to repair their >routing tables. If not acted upon within a reasonable period of time >and possibly a number >of similiar instances, then the "holder" of the 12.0.0.0 - >12.255.255.255 address space loose >their IP assignment. Yes, I am proposing that in this example, the >POSSIBLY that after 7 days of >inaction after being notified, AT&T WorldNet Services would loose their >IP allocation, >if they received their IP allocation from APNIC. In this case they did >not, and that is why I >do understand that this would need to be adopted Internet wide. I am >also interested to see how >long 222.233.52.27 remains active after this email is sent. > >How might this work. There are a number of SPAM services that receive >spam from their users. >They parse the spam extracting the possible originating IP addresses of >the spam, AND the IP addresses >the SPAM is directing the reader to. I am proposing to take the >extracted address the SPAM reader >is sent to, traceroute it, determine the last legal IP address on the >route and send an automated >notification to that service provider, whom ever that may be. > >With respect to the question of "removal" of IP address space, I would >propose the logical loss >of routing to the IP address space in question. > >I hope I have answered your questions. > >Thank you very much, >Gordon > > > > > > >Izumi > >JPNIC > > > > > > > > > >>Pros/Cons: > >> > >>Pros: > >>By adopting this policy, bandwidth utilization will be reduced. >Criminal > >>enterprises will no longer be served. > >> > >>Cons: > >>Disadvantages include new routing tables of increasing complexity > >>to handle the non routing issues associated with dark address space > >>activities and the associated traffic generated. > >> > >>Effect on APNIC: > >> > >>Reduction in bandwidth handled and in it's associated rate of growth. > >> > >>* 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 > >> > >> > >> > >> > > > > > > > > > > > >______________________________________________________________________ > >Samantha Dickinson, Technical Editor <sam(a)apnic.net> >Asia Pacific Network Information Centre ph +61 7 3858 3100 >http://www.apnic.net fx +61 7 3858 3199 >______________________________________________________________________

8 33

APNIC 18 Proposal
by fujisaki＠syce.net 19 Aug '04

19 Aug '04

Dear APNIC Address Policy SIG members, I'll propose below item in APNIC 18th Address Policy SIG at Fiji. Please send me your feedbacks or comments. Thank you. Yours sincerely, -- Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation ----------8<----------8=----------8<----------8=----------8<---------- Your name : Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation/JPNIC Policy WG Chair Your email address: fujisaki(a)syce.net Names of any co-authors: SIG for discussion: Policy Title of proposal: Expansion of the initial allocation space for existing IPv6 address space holders Introduction: I propose making it possible for existing IPv6 address holders with the initial allocation address space to expand their address space without clearing the subsequent allocation requirement. This proposal has reached a consensus at JPNIC Open Policy Meeting. Summary of the current problem: In the past, many of the organizations had requested for the minimum allocation size(/32) as an initial allocation due to the following reasons: + Based on the idea of the "slow start" in IPv4 policy, many organizations believed it would be difficult to justify all of their address requirements at an initial allocation. + It was difficult to estimate their needs as IPv6 network was not commercially developed. Many organizations requested for address space for a test service in order to kick off the commercial service, not for the commercial service itself. + `PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT' specified the initial allocation size as /35. LIRs which received allocations under this policy were only allowed an upgrade of their allocations to a /32. In recent days, most of the ISPs learned that /32 space is too small for the real scale service deployment if they cover their existing IPv4 users. Organizations currently requesting for initial allocations can simply request for a larger space as the RIRs actively emphasize to their communities that they are able to request for allocations greater than /32, which is already a common practice. However, ISPs with the default address space need to design the IPv6 service network within the small space untill they clear the subsequent allocation requirement (HD-Ratio) for more address space. This makes the real IPv6 service deployment difficult, especially for large ISPs. Situation in other RIRs: none. Details of your proposal: Existing IPv6 initial allocation address holders should be able to expand their address space without satisfying subsequent allocation criteria if they are able to demonstrate their concrete plan. The same criteria should apply as organizations requesting for an initial allocation larger than /32. This proposal does not intend to change the current policy but to apply the current allocation practice to existing IPv6 address holders. If it is possible to expand the address space under the current policy, it is desirable to be documented clearly (e.g. in the guidelines document). Advantages and disadvantages of adopting the proposed policy: Advantages: Existing IPv6 address holders will be possible to start their services under up-to-date situation. Disadvantages: none Effect on APNIC members: The expanded address space would be considered in the assessment of the APNIC membership tier of the organization, on the renewal of their membership. Effect on NIRs: NIRs providing IPv6 address allocation service should apply the same policy.

2 5

Fwd: IPv6 Address Allocation document
by Anne Lord 19 Aug '04

19 Aug '04

Save this presentation is to go after Pauls presentation on the global IPv6 IANA - RIR policy proposal. this is the word document for Yun. i'll liaise with Sam to produce a text version for the web site. btw. they are going to present together and then take questions. thanks! Anne >X-Sender: gih@localhost >X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 >Date: Thu, 19 Aug 2004 15:43:15 +1000 >To: Anne Lord <anne(a)apnic.net>, paul Wilson <pwilson(a)apnic.net> >From: Geoff Huston <gih(a)apnic.net> >Subject: IPv6 Address Allocation document >X-AP-Spam-Status: No, hits=-0.349 required=6 >X-AP-Spam-Score: -0.349 (notspam) BAYES_30 >X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash >mimedefang) > >Hi, > >This should be ready now Anne - it has your suggested edits applied, and >some cleanup of the formatting and references. > >cheers, > > Geoff > >

1 1

Policy SIG Proposal - HD ratio for IPv4 allocations
by APNIC Secretariat 19 Aug '04

19 Aug '04

Dear All, Please find below a policy proposal for the forthcoming Policy SIG, to be presented at APNIC18 in Fiji. The ideas in this proposal were presented at APNIC16 as an informational item ("HD ratio for IPv4") on the agenda. You can find details of the presentation, transcripts of the discussions and minutes at: http://www.apnic.net/meetings/16/programme/sigs/policy.html Your comments and feedback on this proposal are very much appreciated on this mailing list. Best wishes, ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064, Australia Fax: +61-7-3858-3199 See you at APNIC 18 Nadi, Fiji, 31 August-3 September 2004 www.apnic.net/meetings ______________________________________________________________________ ______________________________________________________________________ prop-020-v001: Application of the HD ratio to IPv4 ______________________________________________________________________ Proposed by: Paul Wilson and Anne Lord, APNIC Secretariat Version: 1.0 Date: 4 August 2004 1 Summary ------------- Internet address space is managed hierarchically, by allocation from IANA to RIRs and from RIRs to LIRs (ISPs), and by assignment from LIRs to infrastructure and customer networks. At each level of allocation or assignment some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of utilisation of the address space will decrease. The HD ratio (Host-Density ratio) has been proposed as a mechanism for measuring the utilisation of addresses within hierarchically-managed Internet address blocks [RFC 3194]. A given HD ratio value corresponds to a percentage utilisation which decreases as the size of the address space grows, thus allowing for the decreasing management efficiency which is described above. The HD ratio is used as the utilisation metric for address space under the current IPv6 management policy [ipv6-address-policy]. According to this policy, a block of IPv6 address space is considered to be utilised when its HD ratio reaches 0.80. This value is said to represent a conservative but manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document proposes the use of the HD ratio for measurement of IPv4 utilisation, for the same purpose of determining when a given block of address space should be considered as fully utilised. The proposed value of the HD ratio for IPv4 is 0.96. 2 Background and problem ---------------------------- Under the current management framework for IPv4 address space [ipv4-address-policy] a block of IPv4 addresses is considered "utilised" when 80% of the addresses within the block have been allocated or assigned. This measure is applied equally for all address blocks, regardless of size. Current policies assume a hierarchical system of address space delegation (from IANA to RIRs to LIRs to customers, as described above), but they make no allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual PoPs, regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are "hidden" in terms of recognition by the current RIR policy framework, and highly constrained by the 80% utilisation requirement. As a result, management of large blocks is often extremely difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space, and the 80% utilisation requirement is justified on that basis. However address management policies must also be practical in terms of management overhead imposed. It may be argued that when large address spaces are involved, the "80% rule" imposes unreasonable management overheads on an LIR. A more reasonable approach should impose a more uniform degree of management overhead, rather than penalising the holders of large address blocks. This is achievable to some degree by basing utilisation requirements on the HD ratio rather than the fixed percentage-based measure which is in use today. 3 Proposal -------------- In recognition of the problems outlined above, it is now proposed to consider replacing the current fixed percentage based utilisation requirement for IPv4 address space with an HD ratio based requirement. 3.1 The HD ratio ----------------- According to RFC3194, The HD ratio is calculated as follows: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of addresses which are utilised. Note: Under the current IPv4 policy framework, addresses are considered to be utilised once they are assigned or sub-allocated by the LIR. 3.2 Selection of HD ratio value -------------------------------- The appropriate HD ratio value should be decided on a rational basis. In order to do this, we make certain assumptions about the depth of "hidden" hierarchy involved in managing address blocks of various sizes. If we assume that 80% utilisation is achieved at each level of this assumed hierarchy, then the overall utilisation can be easily calculated. The following table proposes a set of hierarchical depths which may be reasonably expected within address spaces of given sizes. If 80% utilisation is achieved at each hierarchical level, then the overall utilisation will be (0.80 to the power of "n"); and from this value, corresponding HD ratio levels can then be calculated. Size range Depth Utilisation HD ratio (prefix) (n) (0.80**n) (calculated) ---------- ----- ----------- ------------ /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 The depths of hierarchy listed above are based on simple assumptions about the likely size and structure of LIRs holding address blocks of these sizes. From the table, a rational HD ratio value may be chosen as 0.96 (a round figure which occurs within most of the above ranges). For this value, the following table gives the utilisation requirement for IPv4 address blocks from /24 to /8. IPv4 Addresses Addresses Util% prefix total utilised ------ --------- --------- ------ 24 256 205 80.11% 23 512 399 77.92% 22 1024 776 75.79% 21 2048 1510 73.71% 20 4096 2937 71.70% 19 8192 5713 69.74% 18 16384 11113 67.83% 17 32768 21619 65.98% 16 65536 42055 64.17% 15 131072 81811 62.42% 14 262144 159147 60.71% 13 524288 309590 59.05% 12 1048576 602249 57.43% 11 2097152 1171560 55.86% 10 4194304 2279048 54.34% 9 8388608 4433455 52.85% 8 16777216 8624444 51.41% Note: This table provides values for CIDR blocks only, however for non-CIDR blocks the same calculations can be applied to produce equally meaningful results. 4 Implementation ------------------- This proposal will impact on procedures for allocation from APNIC to LIRs. 4.1 RIR-LIR procedures ----------------------- The impact of the proposal on the RIR-LIR administrative procedures would be to replace the current 80% utilisation requirement, with a 0.96 HD ratio requirement. By way of examples, an LIR holding a total address space equal to a /16 would be able to receive more address space when they had allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had allocated or assigned 52.85% of their address space. The HD ratio calculation is trivial, but slightly more complex than the existing 80% calculation. Some APNIC members may in some circumstances require extra assistance, however for those using MyAPNIC, the calculation would be automatic and require no additional effort. 4.2 Implementation timeline ---------------------------- If implemented, this policy could be effective within 3 months of the implementation date. 5 References --------------- [RFC 3194] "The Host-Density ratio for address assignment efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] APNIC document: "IPv6 address allocation and assignment policy" http://www.apnic.net/docs/policy/ [ipv4-address-policy] APNIC document: "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/docs/ policy/add-manage-policy.html

5 7

Re: [ATTN JLB CC] Re: [sig-policy] Forwarded reply from Gordon Bader
by GB 17 Aug '04

17 Aug '04

Good Day Everyone, I absolutely agree with the comments of Mr. Baptista. This proposal is legally explosive, and it is a backwater area that has been overlooked. Additionally, there probably are no contracts on various areas of IP space. However, that being said and agreed to, just because something is hard, does it make it not worth doing? The reason why this is a problem is because of these conditions. The reason the dark IP address space is being used, is because it is not being controlled as it should be. In a perfect system this would not happen. Some service carriers are filtering out dark space. Some are keeping their routing tables as clean as possible, while others are not. Let me return to my original argument. APNIC's primary function is to help bring control to the internet and to allocate IP space. If it does not control various areas of the IP address space it has been allocated then APNIC is not doing it's job. The problem will only get worse. Is this the proper proposal? I do not know, that is your call. I do know that if nothing is done, specifically due to the problems you cite, the problem will get worse and it will be more difficult to regain control in the end. As we all know the people who are using the unallocated IP address space, are using it for purposes that would cause them to loose their Internet access with a normal ISP due to their APUs. So they set up shop in "no-man's land", thus thinking that their access can not be denied. So far it appears that they are correct. APNIC has not allocated them access. The carriers who's routing tables route to the dark space are allocating them the space, the service, and essentially recognizing their "right" to use the space. Essentially "squatter's rights". The carriers who are providing them access through compromised routing tables are essentially for all purposes ceding ownership to their Internet access on behalf of everyone. That returns us to APNIC's charter providing for control and IP allocation. That also leaves us with the question of what can and will be done? In the early days, UseNet administrators reserved the death penalty for users who did not comply with some basic standards. You cause no problems, you stay connected. A number of years ago, I remember the @home service nearly receiving the "death penalty" for their lack of actions on behalf of their users. This proposal operates along the same lines. There was no UseNet contracts that were available to enforce. Again I know that this is uncharted. However, I again ask, how will APNIC regain control and how will carriers (at all levels) be forced to stop providing access to users who have "claimed" various segments of unallocated IP address space? With regards, Gordon Joe Baptista wrote: >On Mon, 9 Aug 2004, Jeff Williams wrote: > > > >>>>>>APNIC has the ability to grant IP space. Given that ability, it also >>>>>>has the inherent ability to remove what was granted. The implicit >>>>>>grant of IP space, carries with it the ability to route, and route >>>>>>in a "legal" manner. When "illegal" (dark address space) routing is >>>>>>detected, then the price should be loss of the initial grant - in this >>>>>>case the ability to operate which carries with it economic measures. >>>>>> >>>>>> > >Your gettin into legally explosive backwaters here. I know of many who >have address space outside the control of the RIR - in many cases no >legal agreements exists. > >Much of this no mans land is in North America and a few other countries. > >The RIR in fact control nothing but the reverse arpa. Routing is between >the provider and the IP administrator. > > > >>>>>>Routing tables should be configured for non routing (filtering) of >>>>>>unallocated IP address space as well as allocated IP address space. >>>>>>Traffic to and from unallocated (or allocated but unused) IP address >>>>>>space should be dropped as soon as recognized, thus saving bandwidth up >>>>>>channel. >>>>>> >>>>>> > >??? > > > >>>>>>Employ the basic law - what can be given, can be taken away. APNIC >>>>>>should issue a warning first, followed by removal of IP space from the >>>>>>offending ISP or entity at what ever level. IP addresses are provided >>>>>>under a contract, thus using contract law, removal is possible. >>>>>> >>>>>> > >Again I clearly point out - alot of IP address space is not under contract. > > > >>>>>I don't quite understand how APNIC can be invloved in this, and how >>>>>effective it would be in addressing the problem. I hope you can >>>>>clarify this a little bit more. >>>>> >>>>> > >You can't - it's not your business to act as judge nor jury. > >regards >joe baptista > > > >

2 1

APNIC Policy implementation update
by APNIC Secretariat 16 Aug '04

16 Aug '04

Dear Colleagues, ____________________________________________________________________ APNIC policy implementation update ____________________________________________________________________ The APNIC Secretariat has now implemented the following policies: [prop-014-v001] Lowering the IPv4 minimum allocation size and initial allocation criteria [prop-016-v002] IPv6 allocations to organisations with existing IPv4 infrastructure Lowering the IPv4 minimum allocation size and initial allocation criteria ----------------------------------------------------------------------- Under this modified policy, the IPv4 minimum allocation size has been lowered to a /21 (2,048 addresses) and to be eligible for an initial allocation, an LIR must: - have used a /23 from their upstream provider or demonstrate an immediate need for a /23; - have complied with applicable policies in managing all address space previously allocated to it; - demonstrate a detailed plan for use of a /22 within a year; and - commit to renumber from previously deployed space into the new address space within one year. Official documentation: - "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/docs/policy/add-manage-policy.html Proposal history: http://www.apnic.net/docs/policy/proposals/prop-014-v001.html IPv6 allocations to organisations with existing IPv4 infrastructure ----------------------------------------------------------------------- This policy clarifies the use of existing IPv4 infrastructure and customer base when evaluating IPv6 requests. Official documentation: - "IPv6 address allocation and assignment policy" http://www.apnic.net/docs/policy/ipv6-address-policy.html Proposal history: http://www.apnic.net/docs/policy/proposals/prop-016-v002.html Best regards APNIC Secretariat ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 Level 1,33 Park Road, Milton, QLD http://www.apnic.net ______________________________________________________________________

1 0

Step-down from co-chair of POLICY SIG
by ywju 16 Aug '04

16 Aug '04

Dear Anne, This is Yong Wan Ju at KRNIC of National Internet Development Agency in Korea. I hope that your everything will be fine, of couse other friends too. Because of our internal situation, I would like to deliver my resignation from co-chair position through this mail. I should have committed in SIG-matter more for Internet community, I feel some regrets. However, I hope Policy-SIG will be furuitful settings for AP internet development. Sincerely yours, Yong Wan Ju

3 3

Call for volunteers: Cable and DSL networks WG
by Anne Lord 16 Aug '04

16 Aug '04

Dear colleagues, ________________________________________________________________________ New Working Group: Criteria for Cable and DSL requests ________________________________________________________________________ Action pol-17-007: Proposer to call for the creation of a working group and volunteers to develop modified guidelines for cable and DSL networks in the IPv4 guidelines document. At the 17th APNIC Open Policy Meeting, the Policy SIG decided to review the guidelines for IPv4 requests for cable and DSL networks. The intention of the review is to develop modified guidelines for cable and DSL networks in the light of operational experience of the policies. This is a call for volunteers to join the working group. Volunteers will be responsible for contributing to and reviewing document contents. If you have some spare time that you can contribute to this effort, please email <sig(a)apnic.net> by September 6th, to join the editorial team. A mailing list <wg-ipv4-guide(a)apnic.net> will be live and ready to go after this deadline. We look forward to hearing from you. Kind regards, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison <anne(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 See you in Fiji, APNIC18, 31st August - 3rd September 2004 ---------------------------------------------------------------------- On 16/08/2004, at 11:51 AM, Anne Lord wrote: > Sam > > Please can u edit and make fit for human consumption: i modelled the > announcement on: > > http://www.apnic.net/mailing-lists/sig-policy/archive/2003/11/ > msg00000.html > > Darrin: > > can you please also take a look at setting up a mailing list for this > working group similar to the wg-ipv6-guide mailing list. > > Save: > > can you pls liaise with yun to find appropriate text to describe the > working group please. > > thanks very much! > > Anne > > -------------- > Dear Colleagues, > > ------- > New Working Group: Criteria for Cable and DSL requests > ------- > > pol-17-007: Proposer to call for the creation of a working group and > volunteers to develop modified guidelines for Cable and DSL networks > in the IPv4 Guidelines Document. > > At the APNIC17 Open Policy Meeting, the Address Policy SIG decided to > review the guidelines document for IPv4 requests in respect of Cable > and DSL networks. The intention of the review is to develop modified > guidelines for cable and DSL networks in the light of operational > experience of the policies. > > This is a call for volunteers to join the working group. Volunteers > will be responsible for contributing to and reviewing document > contents. If you have some spare time that you can contribute to this > effort, please email <sig(a)apnic.net> by August 30th, to join the > editorial team. A mailing list <wg-ipv4-guide(a)apnic.net> will be live > and ready to go after this deadline. We look forward to hearing from > you. > > ..... > ______________________________________________________________________ Samantha Dickinson, Technical Editor <sam(a)apnic.net> Asia Pacific Network Information Centre ph +61 7 3858 3100 http://www.apnic.net fx +61 7 3858 3199 ______________________________________________________________________

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy August 2004