- address-policy-wg - mailman.ripe.net

Fwd: Re: [AA] Aanvraag IPv6 adressen
by Aad van der Zanden 25 Aug '05

25 Aug '05

Dear Sir/Madam IPv6 is one of the key research areas within NC3A and we have come across an issue on addressing. I have presented my questions to SURFnet ( which you can find below ) Since Surfnet has not yet presented their views yet I continued my search. I came acros the ECP IPv6 portal and a presentation by Rumy Kanis from RIPE NCC. http://www.ecp.nl/ipv6/docs/Rumy_Kanis_27apr05#1 which refers to IPv6 plicy and this seems relevant to our problem. I am wondering if you can lead me to the right channel for some more guidance on the issue of global IPv6 addres assignments for large geographical distributed organisations like NATO , We are also curious in which database tools are used by RIRs ? Could you help me in finding the right sources or people to get more clearness on this issue so we can further expand our IPv6 work. Regards Aad van der Zanden. >Date: Fri, 05 Aug 2005 09:34:43 +0200 >To: Jasper Distelbrink <jasper.distelbrink(a)surfnet.nl>,Rogier Spoor ><rogier.spoor(a)surfnet.nl> >From: Aad van der Zanden <Aad.van.der.Zanden(a)nc3a.nato.int> >Subject: Re: [AA] Aanvraag IPv6 adressen >Cc: >selm,jan-willem.smaal@nc3a.nato.int,levente.janovszki@nc3a.nato.int,goode,martin.gerritsen@nc3a.nato.int > > >Dear Jasper /Rogier > >In March '05 our first official IPv6 block has been assigned to us; >2001:0610:0B20::/48. As it turns out, the policy is that even any home >user gets a /48 assigned as a minimum. One starts wondering whether a /48 >is then a proper size if one is allocating v6 addresses to an organisation >that has currently approx 500 people as well as numerous pilot networks >spread over several locations. > >So after a review on the IPv6 address assignment ( and tryiing to sqeeuze >all in the /48 ) we have come across a much broader view on assignment of >IPv6 address space. Our Agency takes part or iniitated numerous networking >initiatives that are ( or becoming ) pilots to larger scale >implementations. These network can have external connectivity ( sometimes >exceeding international borders as well). Next to this these network may >have several security classifications levels/layers. > >As an example: >We have a network called NGCS. It now simulates only 5-7 Headquarter >locations; the network is built upon two or more security levels/layers. >So every "Headquarter" has at least these layers. > - An "open layer" that is still a closed IP environment but may > be using the internet as bearer one day - still it needs IPv6 capability now > - a closed encrypted ( by means of IP crypto ) layer of networks > - still it requires IPv6 capability now > - some closed usergroups built on top by means of firewalls - > also requires IPv6 capability to be studied >This pilot network is the first phase to the generic NATO IPv4/IPv6 >provisioning network so will scale to be a very large network in the end. > >How should we approach the IPv6 address assignment for this network in >your view? >Could we currently apply for a larger IPv6 address space for the pilot for >the open layer too from SURFnet? And what about the closed IP layer in the >pilot? >What if the deployment becomes a fact - who will provide the NATO IPv6 >addresses if some of those Headquarters are not directly ISP connected >Who is going to provide the closed layer IPv6 addresses? Since there is no >private IPv6 address space, where should this address block come from ? ( >so in the early pilot stage and in the "operational" stage?) > >Other networks exist which are built upon (NC3A private ) infrastructure >which crosses international borders to regional offices. So if we plan to >deploy IPv6 on these networks too. How do we go about implementing IPv6 >addressing here? > >It would help if you could outline the SURFnet approach to these >interesting issues. >For now - can we apply for more IPv6 address space ( or a larger block ) >to cover all these pilot networks ? > >Regards > Aad

2 1

New Document available: RIPE-349
by RIPE NCC Document Announcement Service 27 Jul '05

27 Jul '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-349 Title: Address Space Managed by the RIPE NCC Author: Leo Vegoda RIPE NCC Date: 27 July 2005 Format: PDF=31257 TXT=2986 Obsoletes: ripe-348 Short content description ------------------------- This document details the address space managed by the RIPE NCC and the longest prefixes allocated or assigned from different address ranges. The new version was needed to correct errors in the previous document. Accessing the RIPE Document store --------------------------------- You can access this RIPE Documents in HTML format at: http://www.ripe.net/docs/ripe-349.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-349.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-349.txt plain text version

1 0

The Register: ICANN prez delivers internet vision
by Hans Petter Holen 21 Jul '05

21 Jul '05

1 0

Presentation of the WGIG Report
by Axel Pawlik 20 Jul '05

20 Jul '05

Dear Colleagues, The WGIG Report was presented in Geneva on 18 July at a meeting open to all stakeholders. The Report of the Working Group on Internet Governance was previously transmitted on 14 July by United Nations Secretary-General Kofi A. Annan to the President of the Preparatory Committee of the World Summit on the Information Society, Ambassador Janis Karklins, and the WSIS Secretary-General, Mr Yoshio Utsumi. The document is available from the WGIG web site in all UN languages at: http://www.wgig.org/WGIG-Report.html More details on the meeting and the transcripts from the morning and afternoon session proceedings are also available at: http://www.wgig.org/index.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 20 Jul '05

20 Jul '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A01:0000::/23 from the IANA in July 2005. We will begin making allocations from this block in the near future. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html This document has been updated to to provide extra information about the IPv6 address space we manage, following some requests we received. I hope people find the new format useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Administrative: New chair email address
by Hans Petter Holen 18 Jul '05

18 Jul '05

Dear all, Following my change of jobs last year from Tiscali to Visma, and as a consequence of Tiscali having sold its Nowegian operations to the former incumbent Telenor, its Swedish opreations to Spray-Lycos and its Danish operations to Tele2; I am changing my personal email address from my private Tiscali subscription to hph(a)oslo.net This will also remove the technical difficulties of delayed email and unsolicited virus scan messages my former employee has imposed on me. The tiscali.no address will still work for some time - but maybe not for more than a year into the future. The Oslo.net domain is however mine to keep - the only remaining memory of the first Norwegian comercial consumer ISP Oslonett - for norwegian readers there are some historic material at the web site. Best Regards Hans Petter Holen Private email: hph(a)oslo.net PS: Appologies for the followin messages to the list: this is most likely due to some new anti-virus software imposed upon me. Antigen_EXFE01HI(a)smarthost3.tiscali.dk wrote: >The entire message "RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal", originally sent to you by address-policy-wg-admin(a)ripe.net (address-policy-wg-admin(a)ripe.net) has been forwarded to you from the Antigen Quarantine area. >This message may have been re-scanned by Antigen and handled according to the appropriate scan job's settings. > > > ><<Entire Message.eml>> > >

1 0

Re: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

Niall Murphy <niallm(a)enigma.ie> writes: > Thomas, all, > > I'd welcome discussion/feedback on it, and this list seems as good a > > place as any. > > > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… > This is nit-picking, but for the sake of clarity: > 2.7. Utilization > In IPv4, the utilization of a chunk of address space is defined as > the ratio of the actual number of host assignments to the theoretical > maximum number of host assignments. For example, a /24 in IPv4 can > number 256 hosts [...] > A /24 can't number 256 hosts; it can number 254. Well, for the purposes of this draft, it's probably best to understand how the RIRs themselves measure utilization. Surely, they just count the raw numbers and don't try to exclude broadcast addresses and such. Thomas

1 0

FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

FYI. The global-v6 list appears to still be active, and perhaps we can revive the list to talk about things that really cross the entire RIR community. Thomas ------- Forwarded Message From: Thomas Narten <narten(a)us.ibm.com> To: global-v6(a)lists.apnic.net Date: Thu, 14 Jul 2005 09:40:34 +0200 Subject: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt I think/hope the global-v6 is still in operation, so this is a bit of a test... I've written a document that attempts to give background and describe the bigger picture w.r.t. IPv6 address space management and the various issues that are now being discussed (e.g., hd ratio, /48 boundary, etc.). This document is intended to provide information and explain the broader landscape, rather than propose specific changes, etc. I'd welcome discussion/feedback on it, and this list seems as good a place as any. http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… Likewise, there is another document that will be discussed at the upcoming Paris IETF meeting. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00… That document will be discussed in the IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html mailing list: https://www1.ietf.org/mailman/listinfo/ipv6 Finally, significant discussion on the general topic has already place (and continues) in the ARIN and RIPE regions. Folk may want to review/follow some of the discussions that have taken place there: http://www.ripe.net/mailman/listinfo/address-policy-wg http://lists.arin.net/mailman/listinfo/ppml (I believe the pointers to the ARIN/RIPE discussions have been sent to APNIC lists, but I don't believe a lot of discussion has taken place there - yet). Thomas _______________________________________________ global-v6 mailing list global-v6(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ------- End of Forwarded Message

5 4

RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal
by BIDRON Alain ROSI/DAS 14 Jul '05

14 Jul '05

According to the proposal documented in the APNIC region, http://www.apnic.net/docs/policy/discussions/prop-020-v001.txt the proposal is based on the HD value 0.96. I think it is better to have the same value for all RIRs. Best regards. Alain -----Message d'origine----- De : Koepp, Karsten [mailto:Karsten.Koepp@lambdanet.net] Envoyé : mardi 12 juillet 2005 12:20 À : BIDRON Alain ROSI/DAS Cc : address-policy-wg(a)ripe.net; Hans Petter Holen Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Bonjour Alain, thanks for your reply. Why have you changed the HD value recommended by APNIC and ETNO from 0.966 to 0.96? Using HD of 0.966 APNIC was projecting an increased IPv4 address consumption of 22%. In case of fr.telecom the lower value drives the required address consumption from 58% to 53%. Please explain this change. For others: APNIC: https://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio. pdf ETNO: http://www.etno.be/pp/EC064%20-%20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf I am personally still not convinced but I have no experience in running such networks as Alain does. regards Karsten > -----Original Message----- > From: BIDRON Alain ROSI/DAS [mailto:alain.bidron@francetelecom.com] > Sent: Tuesday, July 12, 2005 10:19 AM > To: Koepp, Karsten; Hans Petter Holen > Cc: address-policy-wg(a)ripe.net > Subject: RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Dear Karsten, > When you manage an X-large registry you have several levels > of management. > In such a situation, meeting the 80% criteria is much more > difficult (if possible) than with a small registry with only > one level. > The proposal is clearly not to advantage or to disadvantage > some registries but simply to take into account in fair way > different situations in order to have enough flexibility for > a better management. > > Regarding the support from the community, I have to mention > that this proposal was considered by ETNO, whose members > representing are a large part of X large registries in the > RIPE region, and unanimously supported. > > You can find this expression for support at > www.etno.be Document EC064. > > Leo Debecker posted this contribution from ETNO to the mailing list. > Be aware that this support comes from the following ETNO members. > This is not one voice but 41. > · Auna Telecomunicaciones > · Belgacom > · BH Telecom (Bosnia and Herzegovina) > · BT (British Telecom) > · BTC (Bulgarian Telecommunications Company) > · Cesky Telecom > · Community of Yugoslav PTT > · Croatian Telecom > · Cyprus Telecommunications Authority > · Deutsche Telekom > · Eircom > · Elion Enterprises Ltd > · Elisa Communications Corporation > · Entreprise des Postes et Télécommunications Luxembourg > · Finnet Group > · France Telecom > · Invitel > · Koninklijke KPN > · Lattelekom > · Makedonski telekomunikacii > · Maltacom > · Matáv Hungarian Telecommunications Company > · Netia S.A. > · OTE > · Portugal Telecom > · Rom Telecom > · Síminn (Iceland Telecom Ltd.) > · Slovak Telecom > · Societatea Nationala de Radiocomunicatii (SNR) > · Swisscom > · TDC > · Tele 2 > · Telecom Italia > · Telefonica > · Telekom Austria > · Telekom Slovenije > · Telekomunikacja Polska > · Telenor > · TeliaSonera > · Türk Telekomünikasyon > · VIPnet > Regards > > -----Message d'origine----- > De : address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net]De la part de Koepp, Karsten > Envoyé : jeudi 7 juillet 2005 12:34 > À : 'Hans Petter Holen' > Cc : address-policy-wg(a)ripe.net > Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Hello Hans Petter and al, > > I am AGAINST the proposal. > > I would like Alain to better explain his need for better IP > address management. He is the only voice I have seen *for* > the proposal. Nobody is supporting Alain, instead Iljitsch > has brought profound comments *against*, and there were some > cynic comments - also *against*. > > From my point of view, I would like to see the current policy > remain in place, because with IPv4 we much more have a conservation > than an aggregation goal (or an internal aggregation need) > Large LIRs already receive /10s and I cannot see the proposal > will have "some limited impact" on address consumption. If > giant LIRs will only be mandated to occupy 52% instead of 80% of > their v4-IPs (I have done this calculation for DTAG and FT), this > is in my view going to cut our resources significantly. > > So, does the new PDP request a counter proposal to maintain > current policy, I guess no, just enough people have to say > no. Also, people in support of the proposal please raise your > hands. > > regards Karsten > eu.lambdanet > > > -----Original Message----- > > From: Hans Petter Holen [mailto:hpholen@tiscali.no] > > Sent: Friday, July 01, 2005 12:37 AM > > Cc: address-policy-wg(a)ripe.net > > Subject: [address-policy-wg] last Call: Policy proposal > #beta HD ratio > > policy proposal > > > > > > Hans Petter Holen wrote: > > Following the discussion on the mailinglist prior to and > > after posting > > the formal proposal I have seen no proposals to modify the > > proposal and > > would like to move the proposal into the conclustion phase in > > the policy > > development process > http://www.ripe.net/ripe/draft-documents/pdp.html > > > > Last cal will end at July 15th. > > > > Best Regards > > > > Hans Petter Holen > > WG Chair > > > > > Thanks Alain, > > > I'll as the new PDP is not in operation yet, I'll add this > > to my list > > > as #beta v1 > > > > > > I propose that we enter into the Discussion phase for 4 > weeks from > > > date until April 4. > > > > > > -hph > > > > > > BIDRON Alain ROSI/DAS wrote: > > > > > >> Dear Colleagues > > >> Referring to the minutes of the last RIPE Policy Working Group > > >> meeting and to the action list as updated during that > > meeting, I have > > >> to make a formal proposal on use of HD ratio for IPV4. > > >> Here is this policy proposal. > > >> In order to be consistent with the PDP Draft proposal > > coming from Rob > > >> Blokzijl I have used the template provided in the new > PDP proposal. > > >> Best regards. > > >> Alain > > >> > > >> > > >> _________________________________________________________ > > >> 1. Policy Proposal Name: IPv4-HD-Ratio > > >> 2. Author > > >> a. name: Alain Bidron > > >> b. e-mail: alain.bidron(a)francetelecom.com > > >> c. telephone: +33 1 44 44 27 75 > > >> d. organisation: France Telecom > > >> 3. Proposal Version: V0 > > >> 4. Submission Date: 02/02/2005 > > >> 5. Suggested WG for discussion and publication: Address Policy WG > > >> 6. Proposal type: modify > > >> 7. Policy term: permanent > > >> 8. Summary of proposal: Internet address space is managed > > >> hierarchically: > > >> - IANA allocates space to Regional Internet Registries (RIRs). > > >> - RIRs allocate space to Local Internet Registries (LIRs). > > >> - LIRs assign space to End Users. > > >> > > >> At each level, some address space may be reserved for future > > >> expansion and/or efficient aggregation. As more > > hierarchical levels > > >> are introduced, the overall efficiency of the address > space usage > > >> decreases. > > >> > > >> The HD ratio (Host-Density ratio) is a way to measure > > address space > > >> usage [RFC 3194]. The HD ratio value can relate to a > percentage of > > >> usage, which decreases as the amount of address space > grows. This > > >> allows for the decreasing efficiency that occurs with more > > >> hierarchical levels. > > >> > > >> The HD ratio is currently used to measure IPv6 address > space usage > > >> [ipv6-address-policy]. The IPv6 Address Allocation and > Assignment > > >> Policy considers a block of IPv6 address space to be > > 'used' when its > > >> HD ratio reaches 0.80. This is a manageable figure > > ("values of 80% or > > >> less correspond to comfortable trade-offs between pain and > > >> efficiency" [RFC 3194]). > > >> > > >> This document proposes using the HD ratio to measure IPv4 > > usage. The > > >> proposed value of the HD ratio for IPv4 is 0.96. > > >> > > >> 9. Policy text: > > >> a. Current: "An LIR may receive an additional allocation > > when about > > >> eighty percent (80%) of all the address space currently > > allocated to > > >> it is used in valid assignments or sub-allocations." > > >> b. New: "An LIR may receive an additional allocation when > > its total > > >> allocated address space usage meets the HD-Ratio value of 0.96." > > >> > > >> 10. Rationale: > > >> > > >> a. Background > > >> The current document, "IPv4 Address Allocation and Assignment > > >> Policies for the RIPE NCC Service Region" [ipv4-address-policy], > > >> considers a block of IPv4 addresses to be 'used' when 80% of the > > >> addresses within the block have been sub-allocated or > > assigned. This > > >> is applied to all address blocks, regardless of size. > > >> Current policies assume a hierarchical system of address space > > >> delegation. However, they do not make any 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 > > >> Points of Presence (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 not > > >> recognised by the current policy framework and are highly > > restricted > > >> by the "80% rule". As a result, managing large blocks is often > > >> 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. However, address management > > policies must also > > >> be practical in terms of how much management overhead > they cause. > > >> When large amounts of address space are involved, the "80% > > rule" can > > >> result in more work for an LIR. > > >> > > >> Basing usage on the HD ratio should lead to equal levels of > > >> management overhead across the board, rather than penalising the > > >> holders of large address blocks. > > >> > > >> b.Impact > > >> To see a rough estimation of the immediate impact of this > > proposal, > > >> an HD Ratio value of 0.96 was applied to the average amount of > > >> address space held by an LIR in the RIPE NCC Service > Region. This > > >> showed that on average, LIRs would qualify for an additional > > >> allocation block when they have assigned or sub-allocated > > about 59% > > >> of their allocated address space. > > >> > > >> c.Arguments supporting the proposal. > > >> This proposal fairly takes into account addressing > > hierarchies used > > >> in large and extra-large registries and introduces a > > useful level of > > >> flexibility for those registries > > >> The local Internet registries using the 80% criteria may > > continue to > > >> do so and will not be impacted by the new policy. > > >> The RIPE NCC will provide support to minimise complicated > > >> calculations or administrative burden to LIRs. > > >> > > >> d. Arguments opposing the proposal. > > >> This proposal will have some limited impact on IPV4 > > address consumption. > > >> > > >> > > >> > > >> > > >> Appendix A. The HD ratio > > >> > > >> The HD ratio is calculated as follows [RFC 3194]: > > >> > > >> HD = log(U)/log(S) > > >> > > >> Where: > > >> > > >> S is the size of the address block concerned, and > > U is > > >> the number of addresses used. > > >> > > >> Note: The current IPv4 policy considers addresses to be > > 'used' once > > >> they are assigned or sub-allocated by the LIR. > > >> Appendix B. Selection of HD ratio value > > >> > > >> We should decide an appropriate HD ratio value on a > > rational basis. > > >> To do this, we make certain assumptions about the number > > of "hidden" > > >> hierarchical levels involved in managing address blocks > of various > > >> sizes. If we assume there is 80% usage at each level, we > > can easily > > >> calculate the overall usage. > > >> > > >> The following table proposes a set of hierarchical > levels which we > > >> can reasonably expect within different amounts of address > > space. If a > > >> usage of 80% is achieved at each hierarchical level, then > > the overall > > >> usage will be (0.80 to the power of "n"). It is then possible to > > >> calculate HD ratio values from this value. > > >> > > >> Size range Level 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 levels of hierarchy listed above are based on > assumptions > > >> about the likely size and structure of LIRs holding > > address blocks of > > >> these sizes. A reasonable HD ratio value may be 0.96 (a > > round figure > > >> which occurs within most of these ranges) from the table > > above. The > > >> following table gives the usage requirements for IPv4 > > address blocks > > >> from /24 to /8 for this value. > > >> > > >> IPv4 Addresses Addresses > > Util% > > >> prefix total used > > >> 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, but the same > > >> calculations can be made for non-CIDR blocks. > > >> > > >> As an example, an LIR holding a total amount of address > > space equal > > >> to a /16 would be able to receive more address space > when they had > > >> sub-allocated or assigned 64.17% of that space; while an > > LIR holding > > >> a /9 would be able to receive more space when they had > > sub-allocated > > >> or assigned 52.85% of their address space. > > >> > > >> Appendix C. 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] RIPE NCC document: "IPv6 Address > > Allocation and > > >> Assignment Policy" > > http://www.ripe.net/ripe/docs/ipv6policy.html > > >> [ipv4-address-policy] RIPE NCC document: "IPv4 Address > > Allocation and > > >> Assignment Policies for the RIPE NCC Service Region" > > >> http://www.ripe.net/ripe/docs/ipv4-policies.html > > >> > > >> > > >> > > > > >

1 0