August 2003 - address-policy-wg

Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Sascha Lenz 02 Sep '03

02 Sep '03

Hay, On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote: > Hi Daniel, > > I hope I can clarify some of your points below: actually i didn't really want to get into this discussion, but it looks like _noone_ else has anything to say about the issues Daniel raised? Than can't be since he is right in most points. > At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote: [...] most points have been more-or-less clearified by Dominic's answer, but: > >- [EQUIPMENT DESCRIPTION] > > > > This requirement _can't_ be meant serious. We're not on April 1st, > > are we? The silliness of such information requirement was already > > recognized within the IPv6 allocation realm, so why introducing it > > now again for IPv4? > > This is a difficult one as it does require the LIR to do more preparation on > their side. The less time a Hostmaster spends sending E-mails asking > for additional information, the sooner the LIR gets their requested resource. > Asking for the type of equipment used really helps the Hostmaster > understand what and why IP addresses are being requested. ... i still have a problem here if that should be a "must provide this information". I have no much problems with questions like "why-pi" or "routing-reasons" because they can obviously be answered with standard phrases (which renders them useless again, but if RIPE NCC sees that many "bad" requests from many LIRs (aren't they trained?), it's OK for me, no much work, no stupid questions). BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information). Besides that it's way too much work to fill that in seriously for big requests, and doesn't really make sense for small requests. This should be _optional_ information in cases where it's needed to explain an unusual request, whatever, "we have only one machine but it has 500 IP Adresses due to this and that special purpose which can't be handled otherwise due to these and those hardware and software limitations". Is it really only me who is of that opinion, or noone recognized this problem or doesn't think it's a problem? Or isn't it meant as _required_ information anyways and a "N/A" is enough in most cases as answer to this part of the request? ...curious. The reason i noticed that this might get a problem was due to the unholy [...] #[REQUIRED INFORMATION]# [...] % % 2. Please provide a network diagram in PostScript or JPEG % format showing your IPv6 network. Submission instructions % can be found in the RIPE document "Supporting Notes for the % Initial IPv6 Allocation Request Form in the RIPE NCC Service % Region" found at: % % http://www.ripe.net/ripe/docs/ipv6-support-initial.html % % The diagram should indicate expected completion dates of % construction as well as how much IPv6 address space is % expected to be used in each subnet. % % [...] in the (old and new) IPv6 Initial Allocation request form. Since it says "required information" there, i already assumed that it might get a problem to get the IPv6 Allocation for us without providing this one. But i didn't see the point in doing so if i can make our network plans clear in text form, and explain the reasons why a network diagram for an IPv6 network is _completely_useless_ in general at the moment and especially in our case. Though, even on my 2nd mail on that request i just got the reply from some RIPE Hostmistress that "the inability to provide this network topology map calls into question the need for the IPv6 addresses being requested.". At the moment i'm really mad about this. We are currently prevented from deploying IPv6 addresses immediately because i don't have any Windows PC with Viso or something at hand, let alone the time to paint a very useless topology of our IPv6 overlay network, though i explained it in detail in text. (Not to mention that the statement that an active LIR which assigns IPv4 addresses for years is questioned that it will assign IPv6 addresses just because it doesn't like to waste time on painting network maps of some routers and tunnels is VERY doubiously to me.) Why the hell is such information _required_? Information about what equipment being used and a network topology map on a picture might be additional information at best. I fear that IP(v4) request will be denied or at least delayed in future if the RIPE Hostmasters are gonna complain about missing or unsatisfying information about the equipment in the future, too. That's not acceptable i think. But i might be wrong, we're realatively small and don't have that many requests in general, i just wonder why noone of the "big LIRs" sees this problem? You all have AWs that big that you don't care about filling in RIPE forms anyways and have payed managers to paint network diagrams all day? *hint* :) > >Further, the term "peer" is used in a very unclear way in the ASN > >request form and the supporting notes. > > > >Formerly, one uplink and one peer (commercial term) were enough to > >justify an ASN, as this constitutes a "unique routing policy". The > >ASN request form allows this interpretation of "peering partners" > >with "peering" in the technical sense. BUT the supporting notes > >specifically mention the requirement for two peers to "ensure that the > >organisation is multihomed". For me, multihoming means to have at least > >two _upstreams_. This would be a more stricter policy than before. > >What was the real intention behind these phrases? These documents > >should be very specific in the usage of "peer". It might be interpreted > >technically or commercially, each implying different constraints. > >I suggest changing the wording from "peer" to "upstream" in order to > >avoid ambiguities. > > Again this is a good point. However I don't think that either term is > appropriate for all situations. When writing these documents we used > the word peer as we wanted to emphasise it was the routing policy which > was important. So, the policy didn't change to "you have to have two _upstreams_ to get an ASN" but it's only a language-confusion here? P.S.: I think this discussion belongs to the address-policy-wg, not ncc-services-wg? Sorry for crossposting, remove the latter in any replies if i'm right. -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz(a)baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================

4 7

Re: [address-policy-wg] WG Charter
by Hans Petter Holen 01 Sep '03

01 Sep '03

> Hans Petter, > > I would also mention the role of the working group in > - co-ordinating policies with other RIRs > - address policy issues that have to do with IANA/ICANN What about: The Address Policy WG develops policies relating to the management and registration of Internet resources (currently IPv4, IPv6 and AS Numbers) by the RIPE NCC and its LIRs within the RIPE NCC service region. It also co-ordinates policies with the other RIR communities and liaises with the IANA and ICANN on address policy issues. The Address Policy WG meets three times a year at RIPE meetings and has an open (publicly archived) mailing list. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. -hph

4 4

Fwd: selling ip:s? (kf)
by Katri 28 Aug '03

28 Aug '03

>Hello, I would like rise the question about selling ip-addresses... > >Let me present two exampled: >1. ISP A has offeres adls that includes static 1 ip-address, but if the >customer needs more ip:s > they will apply for this and pay a sum of X krona per ip-adress they > receive. > ISP B also offeres adsl that inclued 1 ip-address, and when the > customer needs more ip:s > they will have to change the service in order to receive more ip:s, > since the adsl service is > only offered with 1 ip-address and approved from RIPE NCC to be done > in this way. > How should ISP B compare and offer the same amount of ip-addresses > without "getting > into trouble"? > >2. ISP A has a customer who has received /24 from which they share out >addresses > and their customers can receive more addresses for a sum of X krona. > > I understand that we are not allowed to sel our ip-addresses but what > about > our customers customer? Is there anything preventing this from > happening and > is there something documented? > >Regards Katri >Tele2/Swipnet IP Registry >Local Internet Registry >__________________________________________________________ > >Tele2/SWIPnet Tel: 08 5626 40 08 >Box 62 Fax: 08 5626 42 10 >164 94 Kista Email: ip(a)swip.net >SWIP-RIPE SWIPNET-LIR-MNT >__________________________________________________________

2 1

Re: [address-policy-wg] Summary of the PI Task Force's recent discussions
by Wilfried Woeber, UniVie/ACOnet 26 Aug '03

26 Aug '03

>Hay, > >On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: >> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: >> > Below is a summary of the recent discussions on the PI TF mailing list. >> >> As the pi-tf mailing list seems to have been closed (at least I'm unable >> to subscribe - pi-tf-request(a)ripe.net bounces as unknown), I guess >> further discussion should take place here (which makes some sense). > >Closed, yes. I don't think so, pls. see below. Wilfried. ______________________________________________________________________ From: Mally Mclane <mally(a)ripe.net> To: pi-tf(a)ripe.net Subject: [pi-tf] This list has moved to mailman Date: Tue, 26 Aug 2003 09:26:26 +0200 Dear Colleagues, We have moved this list to mailman, in an attempt to cut down on the spam that was entering it. The list will function exactly as before, and the archives will still be available in the same space. You can edit your personal options at: http://www.ripe.net/mailman/listinfo/pi-tf If you notice any oddities, please contact <ops(a)ripe.net>. Regards, Mally Mclane RIPE NCC - Operations --------------------------------------------------------------------------------

4 3

Summary of the PI Task Force's recent discussions
by leo vegoda 26 Aug '03

26 Aug '03

Dear Colleagues, Below is a summary of the recent discussions on the PI TF mailing list. The policy for portable address space is on the draft agenda for the Address Policy WG's session at RIPE 46 on 3 September. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager A summary of the PI TF's initial discussions was agreed and posted to the <lir-wg(a)ripe.net> mailing list on 6 May 2003. It can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/2003/msg00265.html Gert Döring presented on the discussion at the RIPE 45 LIR WG session. His slides can be found at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pi-tf. pdf At RIPE 45 there was an agreement that the Task Force should continue its work. There was also an agreement that the PI policy is tied to the qualifying criteria for an initial IPv4 allocation. Discussion focused around a straw-man proposal to make four related policy changes. The proposed changes are outlines below along with a summary of comments received on them. 1. Reduce the minimum allocation size from /20 to /21 - There was some support for this point. There were requests for /21 allocations to come from a new and separately identified address blocks. 2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case) - There was no objection to this point. It was pointed out that with a lower barrier to entry the overhead of checking each requester is ready to use 512 IP addresses straight away would be unlikely to be equal to the value of the work. 3. No longer assign PI (Portable) address space to End Users - There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. 4. End Users requiring a portable address block could become an LIR and receive a /21 allocation. - There was some support for this point. The costs of operating an LIR were raised as an issue. It was also noted that everyone may become an LIR. There is no barrier to membership of the RIPE NCC. There was a suggestion for a one-time service fee. There were also some additional comments: It was noted that if the policy allows for address allocations based on other criteria than prior demonstrated need some providers may filter those allocations. It was also noted that the RIPE NCC cannot provide any guarantee as to whether address space will or will not be routed of filtered by network operators. Some statistics were requested and provided for the first half of 2003: ASN assignments: 599 Allocation: 377 PI Assignments: 408 Number of /20s allocated per month for the same period: 200301 7 200302 20 200303 14 200304 16 200305 35 200306 24 Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.

9 14

Re: [address-policy-wg] Transferring InterNIC space from ARIN Database to other RIR datab ases
by Niall O'Reilly 20 Aug '03

20 Aug '03

On Wednesday, Jul 30, 2003, at 22:42 Europe/Dublin, Hans Petter Holen wrote: > Hmm, we did form a special task force for this matter to work with the > RIPE NCC with the process etc. (References in Leos message) > > As chair of this working group I would really like to know what more we > can do to interact more closesly with the community - please feel free > to > suggest to the list or approach me personally with suggestions ! Hans Petter, Thanks for your encouraging words. I've been away for a couple of weeks and am still mining the e-mail mountain. During second half of July, I've had some off-list exchange with Leo, and found him really eager to be helpful. I still have some sense of the "blind man and elephant" problem, in both directions. As I'm not involved in a LIR, I missed the formation of the task force. In addition, I couldn't travel to Barcelona. In any case, a TF involving LIR-WG and RIPE-NCC is likely (as seems FWIS to be actually the case) to focus on managing the production line rather than on managing customer expectations. It's worth bearing in mind that ERX customers are likely, for the same historical reasons by which they have become ERX customers, to be involved directly with the RIR rather than via their ISP as LIR. [ Hmm, the emergence of the Address Policy WG seems to be just what I needed. ] It seems to me that a useful view of the ERX project and its progress would be a set of graphs derived from a table like the one below; needless to say, my numbers can't be related to reality except by co-incidence. Reporting Period (Month or Qtr) 2003.01 2003.02 ... Estimated work (contact count) 8000 8251 ... (estimate may evolve) Estimated work (network count) 215 216 ... Completed work (contact count) 0 57 ... Completed work (network count) 0 16 ... The graphic would show clearly, for two different measures of the work involved, both the estimated and (cumulative) completed work at each reporting instant. The gap between the estimated and completed work would show how much was left to be done. Hopefully, the curves would converge! I haven't been able to find such a simple overview in the material I've located on the web, or in the nice Member Update which Leo has kindly had sent to me. I think presentation of this kind of information would help customers anticipate ERX progress in the foreseeable, rather than indefinite, future. It would also be useful to know in what order the different /8 blocks are to be dealt with, what criteria have led to choosing this order, and how soon each /8 is expected to be finished, at least as planned at present. I expect that the plan may evolve in the light of experience, and that some blocks of space will prove more troublesome than others. There may be scope for taking advantage of the usual 80/20 result/effort ratio. I expect that the information I would like to see presented must already be in use to manage the project, and so should not require significant extra effort to prepare. It's probably a good idea for me to say that I'm just looking for information, not trying to paint anyone into a corner. [ As you can probably guess, I'm really only interested in 137.43/16, 8-) ] I hope these suggestions help. I expect to come to Amsterdam for the first week in September, and look forward to seeing some nice graphs! Best regards, Niall O'Reilly PS. FWIS: From where I sit.

2 1

Re: [address-policy-wg] IP Addressing policy on personal contact info (kf)
by Michael.Dillon＠radianz.com 20 Aug '03

20 Aug '03

>and I would like to discuss on how we should do with personal contact >information in the RIPE db. The db should only contain the contact information of people who are ready, willing and able to communicate regarding network issues and who are able to act on that communication. This means that much of the existing contact information in the db would disappear and LIRs would formally have the responsibility of relaying communications to their downstream networks. Some of these downstream networks MAY still be in the db but the network contacts MUST agree to be listed and MUST agree to be ready, willing and able to communicate regarding network issue and MUST be able to act on that communication. This would clean most of the useless garbage out of the db, solve the privacy issues, and focus the LIR's attention on the true purpose of the db. The RIPE db is not a general purpose telephone book, it is a contact directory for a specific purpose which is required by TCP/IP internetworking activity. There is no point in including contact data for people who are not ready, willing and able to communicate or who are not able to take any action. RIPE has a direct relationship with LIRs so there is the possibility to force them to have someone who is ready, willing and able to communicate and able to take action. Some LIRs may choose to force their customers to also provide such a contact person, but there is nothing wrong if an LIR chooses to be the direct contact for all of their customers. --Michael Dillon

6 6

Draft agenda Address Policy Working Group RIPE 46
by Hans Petter Holen 20 Aug '03

20 Aug '03

Dear WG; Here are some items for a draft agenda, please send me comments as soon as possible; - wg-charter - policy process - PI policy - initial IPv4 allocation size - RIR- IANA relationship and procedures - RIPE-152 Charging by local registries - Final revised IPv4 policy

5 9

Re: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ......
by Bovio＠aol.com 19 Aug '03

19 Aug '03

In a message dated 11/08/03 17:51:19 W. Europe Daylight Time, daniel.karrenberg(a)ripe.net writes: > I have not stopped listening to concrete ideas about improving the RIPE > NCC. > > I am still here at the RIPE NCC working and listening. Of course the > bureaucratic developments you sneer at *do* happen to some degree. This > is inevitable and both you and I know it. The ability of individuals > like you and me to influence things immediately and directly is reduced. > Of course I personally I do not agree with all things the RIRs do and > more often I do not agree with *how* things are done. > > What seems to divide us is that I still work to improve the 'least of > all evils' structure and you sneer at it providing no alternative. > I would hope that more people will chose the former instead of the latter. > I also hope that people still see the relative mertis and the > differences in legitimacy that exist between the various organisations. > Sneering at the RIPE NCC without suggesting either alternatives or > improvements does not help. > I stand 100% with Daniel here. I can't speak for the others RIRs but I strongly believe the RIPE-NCC has made significant efforts in the recent past to listen to its membership, streamline procedures, and positively react to constructive criticism. There is more work to do, no doubt about it, but I can't see how flaming on mailing lists helps. Whomever has concrete ideas: I propose we move this discussion to the ncc-services-wg list/group, that was created exactly for this purpose. Daniele

8 15

Web archive of PI Task Force now available
by RIPE NCC WebMaster 18 Aug '03

18 Aug '03

Dear Colleagues, As requested, the RIPE NCC has made the discussions of the PI Task Force available as a web archive. You can find the archive at: http://www.ripe.net/ripe/mail-archives/pi-tf/ The PI Task Force was established by the LIR WG at RIPE 44. Its purpose is to review the policy for Provider Independent (PI) address space. Regards, RIPE NCC Webmaster www.ripe.net ==================

1 0

Draft: "status:" re-evaluation
by Shane Kerr 15 Aug '03

15 Aug '03

All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC

6 9

Policy making process
by Hans Petter Holen 15 Aug '03

15 Aug '03

Dear working group, In the beginning there was no documented process of making policy. At some point I started outlining the process in http://www.ripe.net/ripe/wg/lir/howto_develop.html The experience since then is that a couple of elements should be added to this - not necessarily to make a biger or more complicated process, but with the incentive to make the process more open and more transparent. * Proposals should be circulated in writing to the mailinglist in advance of the meetings. Currently we have started calling for contributions and requestion proposals. * There should be detailed technical discussion on the mailinglist before a proposal can be adapted * All policies should be published as RIPE documents * All RIPE documents setting new policies should be published as drafts before becoming final -hph

1 1

IP Addressing policy on personal contact info (kf)
by Katri 14 Aug '03

14 Aug '03

Hello, I saw at RIPE 44 LIR WG Session regarding IP Addressing policy for always-on (residential broadband) Leo said the following: L.V : This should be registered in the database. If it's a residential user, their personal contact information cannot be registered in most countries due to the Data Protection laws. The Database object could then point to contact data at the ISP without identifying customer by name. This should be discussed by the WG if anyone is concerned by this. and I would like to discuss on how we should do with personal contact information in the RIPE db. I don´t only mean residential braodband services but all kind of services that might be available to customers. Should we or should we not register personal contact information that might conflict with Data Protection laws in some countries? How has it been solved earlier? What sort of criterias/ rules should we as an ISP have for the contact data? Regards Katri Forsberg Tele2/Swipnet IP Registry Local Internet Registry __________________________________________________________ Tele2/SWIPnet Tel: 08 5626 40 08 Box 62 Fax: 08 5626 42 10 164 94 Kista Email: ip(a)swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________

1 0

Interesting APNIC proposal
by Joao Luis Silva Damas 14 Aug '03

14 Aug '03

I have just noticed this quite interesting and well prepared policy proposal from APNIC regarding a different way of calculating address utilisation ratios. It seems of particular relevance in the cases of multiple levels of sub-allocation, a situation that has been the subject of debate in the RIPE region as well, therefore I believe it deserves consideration also in this region. The changes in address consumption derived from the proposal are addressed in section 5.2 The original posting on APNIC's mailing lists is available at http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/ msg00000.html Joao Damas ------------------------------------------------------------------------ Discussion Document Application of the HD-Ratio to IPv4 Prepared by: Paul Wilson, APNIC Secretariat Version: 1.0 Date: 7 August 2003 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 components and customer networks. Within each level of allocation or assignment some address space is generally reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced into any address space, the overall efficiency of utilisation of that space (in terms of the total number of individual addresses actually used) will inevitably decrease. The HD Ratio (Host-Density Ratio) has been proposed as a practical 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 overall address management efficiency which is described above. The HD Ratio is currently used as the utilisation metric for IPv6 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 effectively 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 explores the possible 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. 2 Background and problem The current management framework for IPv4 address space relies on policies developed within each RIR community [ipv4- address-policy]. These policies dictate, effectively, that a given block of IPv4 addresses should be considered "utilised" when at least 80% of the addresses within the block have been allocated or assigned. This measure is applied equally for address blocks held by small or large LIRs, regardless of their size. In any case, it is deemed that once 80% of the space held by an LIR has been allocated or assigned, that LIR may request more address space from its appropriate RIR. 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 address management within an organisation's own 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 may be justifiable 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 attempt to impose a uniform degree of management overhead, rather than penalising the holders of large address blocks. This may be 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 A 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, referred to as the AD Ratio. 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 site addresses (/48s) which are utilised. In order to calculate the HD-Ratio for a given IPv6 block, it is necessary to know the size of that block, and number of host addresses which are in use. The current IPv6 policies allow for this by requiring registration of address assignments to the /48 level, however this degree of registration is not appropriate under IPv4 management policies. 3.2 Definition - the AD Ratio IPv4 address space utilisation is measured in terms of the number of allocations or assignments which have been made from a given address block, rather than the number of host addresses which are in use within the block. We therefore use the term "Allocation Density" for the measure of address space utilisation within an IPv4 block, rather than the term "Host Density" which represents host-address utilisation in IPv6. Consequently, we refer propose a new utilisation metric for IPv4, to be known as the "AD Ratio" (for Allocation or Assignment Density Ratio). The AD Ratio measures the number of addresses allocated or assigned from a given block of address space, as follows: AD = log(A)/log(S) Where: S is the size of the of the address block, and A is the number of addresses allocated or assigned from that block. 3.3 Selection of AD Ratio value The appropriate AD Ratio value for the purposes of this proposal 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. We then assume that at each level of this assumed hierarchy, the currently accepted 80% utilisation requirement is achieved, in order for the entire address space to be considered as fully utilised. The following table proposes a set of assumed hierarchical depths which may be reasonably expected within hierarchically-managed address spaces of certain sizes. At each delegation level an allocation density of 80% is assumed, so that within a hierarchy of "n" levels, the overall address space utilisation is calculated as 0.80 to the power of "n". Size range Depth Util AD 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 Note: the above AD Ratio values are derived directly from the formula above. For instance, a /20 block contains 4096 addresses, and 80% utilisation corresponds to 3276.8 addresses; therefore the corresponding AD Ratio is calculated as log(3276.8)/log(4096) = 0.973 The depths of address hierarchy listed above are notional approximations only, based on general assumptions about the likely size and structure of LIRs holding address blocks in the respective size ranges. From the table, a rational common AD ratio value may be determined as 0.966 (chosen as the most conservative value which is common to all of the listed ranges). For this value, the following table gives the percentage utilisation requirement for the full range of IPv4 address blocks (this is also derived directly from the AD ratio formula shown above). IPv4 Addresses Addresses Util% Prefix Total Utilised 32 1 1 100.00% 31 2 2 97.67% 30 4 4 95.40% 29 8 7 93.17% 28 16 15 91.00% 27 32 28 88.88% 26 64 56 86.81% 25 128 109 84.79% 24 256 212 82.82% 23 512 414 80.89% 22 1024 809 79.00% 21 2048 1580 77.16% 20 4096 3087 75.37% 19 8192 6030 73.61% 18 16384 11780 71.90% 17 32768 23010 70.22% 16 65536 44949 68.59% 15 131072 87804 66.99% 14 262144 171518 65.43% 13 524288 335046 63.90% 12 1048576 654485 62.42% 11 2097152 1278482 60.96% 10 4194304 2497408 59.54% 9 8388608 4878479 58.16% 8 16777216 9529704 56.80% 7 33554432 18615487 55.48% 6 67108864 36363809 54.19% 5 134217728 71033685 52.92% 4 268435456 138758413 51.69% 3 536870912 271053050 50.49% 2 1073741824 529479652 49.31% 1 2147483648 1034294583 48.16% 0 4294967296 2020408681 47.04% 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 If implemented at any particular level in the IP address delegation chain, this proposal would have a number of impacts on administrative processes at that level. It is not currently proposed to apply this proposal to the relationship between RIRs and IANA, therefore the implementation of the proposal at the RIR-LIR level is discussed there. 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.966 AD 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 68.59% of that space; while an LIR holding a /9 would be able to receive more space when they had allocated or assigned 58.16% of their address space. For blocks smaller than /22, it is proposed that the current 80% requirement be used, in order that this new policy does not impose tighter utilisation requirements than were previously imposed. The AD-Ratio calculation is trivial, but certainly more complex and less intuitive than the existing 80% calculation. Some APNIC members may in some circumstances require extra assistance, however for those using the MyAPNIC service, the calculation would be automatic and therefore no additional effort would be involved. 4.2 Assignment procedures In order to support consistent calculation of an LIR's AD Ratio, it would be preferable for each LIR to register infrastructure assignments in the same way as customer assignments. This could be done by whois update via email, or via the MyAPNIC service. It would not be necessary to register individual hardware components or subnets, but rather only the independent infrastructure blocks which are designated by the LIR, and which can be justified on the same basis as customer assignments. Such registrations would be publicly visible as normal whois records, unless database changes were implemented to specifically hide them. 4.3 Implementation timeline If implemented, this policy could be effective within 3 months of the implementation date. 5 Impacts 5.1 Administrative Impact The primary administrative impact of this proposal is to ease the administrative address management burden experienced by LIRs, especially those with large address space holdings. The proposal recognises the need to manage address space hierarchically within an LIR service infrastructure, and makes allowance for it through the use of the AD ratio for assessment of address utilisation. This proposal would impose a small administrative cost on LIRs. In the first place, an LIR's internal systems (manual or automated) would need to incorporate a new method of calculating address space utilisation (and especially when determining the point at which the LIR may request more space from APNIC). In the second place, an LIR would need to register infrastructure assignments in the same way as customer assignments, which would impose additional administrative cost. In both cases, LIRs using the MyAPNIC service would experience a small extra cost because these changes can be automated within that system. The administrative impact on internal systems of the APNIC Secretariat is also relatively small. APNIC hostmaster processes can be tailored easily to accommodate a changed method of calculating address space utilisation; and the whois database can certainly accommodate an increased number of registrations. 5.2 Address Space Consumption Because this proposal lowers the utilisation requirement for IPv4 address blocks, it would certainly increase the rate of deployment of IP addresses. In analysing this impact, we can identify two separate factors contributing to increased consumption: firstly, an initial impact resulting from increased "wastage" of deployed address space; and secondly, on ongoing impact as utilisation requirements continue to fall for individual LIRs' growing address holdings. 5.2.1 Initial impact The initial impact on address consumption can be estimated by calculating for each APNIC LIR the difference between the current 80% utilisation, and the AD-ratio-determined utilisation requirement. This calculation will indicate the amount of extra "wasted" address space which would result from the proposed policy change. Total LIRs in sample 788 Total address space held 4.17 (/8 blocks) Utilised addresses (80%) 3.32 Utilised addresses (AD 0.966) 2.53* Extra "wasted" space 0.81 Extra "wastage" as % of total 19% * This figure is calculated from the sample of 788 LIRs, according to actual address space holdings These figures show that by reducing the address space utilisation requirement from 80% to AD 0.966, an additional 0.81 blocks are consumed out of a total 4.17 blocks allocated. This corresponds to an additional of 19% of the total allocated address space. It should be noted that this assessment indicates a theoretical impact in terms of increased address consumption, assuming all deployed address space is actually utilised. The actual impact will be less than this due to underutilisation of address space; and furthermore the impact will not take place at one time, but progressively as part of ongoing address space allocations. 5.2.2 Ongoing impact The ongoing impact on address consumption can be estimated by distributing additional address space to the same set of LIRs, in proportion to their existing address space holdings. For the purposes of this analysis, an additional /8 block is distributed to the same set of 788 LIRs, in proportion to their existing address holdings. Initial address space held 4.17 (/8 blocks) Additional space allocated 1.00 Total address space now held 5.17 Utilised addresses (AD 0.966) 3.11* Additional addresses utilised 0.58* Utilised addresses (80%) 0.80 Extra "wasted" space 0.22 Extra "wastage" as % of allocation 22% * These figures are calculated from the same sample of 788 LIRs, assuming a proportional distribution of an additional /8 block These figures show that after an additional /8 block is distributed and utilised, 58% of that block would actually be utilised, rather than 80%. Therefore up to 22% of that block would be "wasted" by the use of AD 0.966 in place of 80% as the utilisation measure, resulting potentially in an increased consumption rate of up to 22%. Again, this calculation is theoretical only, and assumes that all address space which has been distributed will be utilised. 5.2.3 Conclusions on address consumption The above analysis indicates that the adoption of this proposal would cause an initial additional consumption of up to 19% of address space allocated. In APNIC's case, a total of 8.07 /8 blocks have been allocated (as of 1 July 2003), so up to an additional 1.53 blocks would eventually be consumed as a result of the change. The analysis also indicates that this proposal would cause an overall 22% increase in the rate of address consumption. In APNIC's case, a total of 1.90 /8 blocks per year are currently being allocated (in the 12 months to 1 July 2003), and this rate would therefore rise to 2.32 blocks per year. The assumptions on which the above analysis is made include: firstly, that the 788 LIRs in the sample are representative of all LIRs in the region; and secondly, that a consistent rate of growth will be experienced by all LIRs in the region. 6 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/ipv6-address-policy.html) [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)

1 0

RIPE NCC Services
by Chris Hallam 13 Aug '03

13 Aug '03

Stephen Burley wrote: All of which the NCC do well and should be commended, anything else is surplus to requirement there is one other thing the NCC has never done and never fully justified and that is a help desk you can talk to. Other RIR's do it. I think it helps cut away the sterile faceless image and lets you see what you are getting for your money - discuss === I think the inclusion of a telephone help desk service would benefit a lot of members. I imagine it would be difficult to implement due to the number of bilingual staff that would be required. This would therefore require substantial funding which would probably affect member fees. In addition, most of the actual processes would have to remain based on the email system. Even so, if the operational scope was clearly defined it would be useful for help, advice, and a reliable point of contact. Chris ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. **********************************************************************

1 0

English Language (was: Summary of the PI Task Force's recent discussions)
by Michael.Dillon＠radianz.com 12 Aug '03

12 Aug '03

>People are requesting *multiple* PI blocks because they can't get a PA >allocation, and that seems to be just wrong to me. Something strange is happening to the English language here. Whenever I read PI and PA, I have a mental concept of independent blocks that I can announce, and borrowed blocks that I get from my provider's aggregate. In this set of mental concepts, a provider gets a PI block from an RIR and then allocates PA blocks to their customers. But after stumbling through this thread, I checked the RIPE website and discovered that the IPv4 policies state: LIRs are allocated Provider Aggregatable address space that they assign to their End Users and announced as one prefix. The problem is that the word "aggretable" means something that is capable of being aggregated. The block that a customer receives from the LIR is a part of a larger aggregate and is therefore "aggregatable". But the block that the LIR receives from the RIR is not necessarily aggregatable because there is no guarantee that the RIR will reserve adjacent blocks for the LIR. I know that the practice is to reserve the adjacent blocks for some period of time, but there are a lot of LIRs which have multiple non-aggregatable blocks from the RIRs. This is important because if we are not clear and consistent in our use of the language, then we create confusion and misunderstandings. For instance, in the ARIN world, PA stands for Provider Assigned in order to make it clear that the RIR gives providers PI space and the providers cut it up into PA blocks for their customers. It's like lending and borrowing. If I lend you a bicycle then you are borrowing it from me. Then you can lend the borrowed bicycle to your friend so that you are both a borrower and a lender of the bicycle. It seems to me that the distinction needs to be made between network-independent address blocks and network-dependent or network-attached ones. NI Network-Independent address blocks are allocated to an organization by the RIR and can be announced in whole or in part by any network with which the organization has a relationship. NA Network-Attached address blocks are assigned to an organization by an LIR and can only be used with the network(s) operated by that LIR. Then we could drop the acronyms and start talking about independent address blocks and attached network blocks. Personally, I don't believe that all 5 RIRs should have the same policies but I do believe that all 5 RIRs should use the same terminology and language to talk about addressing as long as the talking is done in English. --Michael Dillon

2 1

AW: [address-policy-wg] Summary of the PI Task Force's recent dis cussions
by Marcus.Ruchti＠colt.de 11 Aug '03

11 Aug '03

so how should we connect multihomed customers?? a majority of the ISP's won't announce PA space of another AS. rgds, Marcus Ruchti COLT Telecom GmbH -----Ursprüngliche Nachricht----- Von: Joao Luis Silva Damas [mailto:joao@psg.com] Gesendet am: Montag, 11. August 2003 11:48 An: Address Policy WG Betreff: Re: [address-policy-wg] Summary of the PI Task Force's recent discussions I have one question, trying to understand the main goal of the exercise: * Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name? Joao On Monday, August 11, 2003, at 10:29 AM, Stephane Bortzmeyer wrote: > On Mon, Aug 11, 2003 at 08:19:46AM +0200, > leo vegoda <leo(a)ripe.net> wrote > a message of 91 lines which said: > >> 3. No longer assign PI (Portable) address space to End Users >> >> - There some support for to this point. The issue of Root DNS >> Servers was raised but it was noted that all Root DNS Servers >> operating in this region already have address assignments. > > And what about ccTLD name servers? > >

1 0

Re: [address-policy-wg] Summary of the PI Task Force's recent discussions
by Joao Luis Silva Damas 11 Aug '03

11 Aug '03

Gert, On Monday, August 11, 2003, at 11:50 AM, Gert Doering wrote: > Hi, > > On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote: >> I have one question, trying to understand the main goal of the >> exercise: >> >> * Is the aim of the a new PI policy to adjust the policy to the >> requests and needs of the industry or is it a way of getting a >> "special >> allocation" policy by another name? > > My aim is to adjust the policy (actually both PA and PI policy) to > match > observed need. > That is good. > People are requesting *multiple* PI blocks because they can't get a PA > allocation, and that seems to be just wrong to me. > Just to spell it out clearly: - Is it people who do not meet the minimum allocation size for PA? I guess these ones would ask for a single PI assignment? - Is it people who find it to be so much hassle to get an allocation that they end up requesting multiple PI blocks with the same amount of addresses? - People who have multiple sites and if they get a normal PA block will need to split it and end up with a bunch of non-routable sites? Other? Just trying to understand. One last thing. There is something that makes it unusually attractive to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) where you don't have to bother with anyone filtering you if you have at least a /24 (damn easy to justify). Joao

1 0

Updated 'RIR Comparative Policy Overview' - Version 2.1
by leo vegoda 07 Aug '03

07 Aug '03

Dear Colleagues, Version 2.0 of the 'RIR Comparative Policy Overview', found at: <http://www.ripe.net/rs/rir-comp-matrix-rev.html> has been updated to correct an error in the information for LACNIC in Section 2.4.1. "Assignments by RIRs (Independent/Portable)" To be eligible for an independent/portable assignment from LACNIC, the corrected text now reads: "Show need for at least a /21, based on demonstrated need, according to the criteria listed above." the old text read: "Need to be multihomed and show need for at least a /21. Based on demonstrated need, according to the criteria listed above." Please accept our apologies for any confusion or inconvenience caused. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Re: [Fwd: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46]
by leo vegoda 07 Aug '03

07 Aug '03

Hi, Shane Kerr <shane(a)ripe.net> wrote: >Did we want "status:" added? It sort of comes under the policy as it is specified there, too. Regards, -leo >-----Original message----- >Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 >To: address-policy-wg(a)ripe.net >From: Hans Petter Holen <hpholen(a)tiscali.no> >Date: Thu, 7 Aug 2003 01:39:45 -0100 > >Dear WG; > >Here are some items for a draft agenda, please send me comments as soon as >possible; > > >- wg-charter >- policy process >- PI policy >- initial IPv4 allocation size >- RIR- IANA relationship and procedures >- RIPE-152 Charging by local registries >- Final revised IPv4 policy > > > >-----End of original message from Hans Petter Holen----- -- leo vegoda RIPE NCC Registration Services Manager

1 0