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

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

Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site
by Hans Petter Holen 13 Jul '05

13 Jul '05

Dear Address Policy WG, Please find enclosed a policy proposal from Eric Schmidt. This proposal is entered into the discussion phase with a deadline of 4 weeks - August 10th. Best Regards, Hans Petter Holen AC Chair 1.Number: #Eta 2.Policy Proposal Name: IPv6 Address Allocation and Assignment Policy - definition for "End-Site" 3.Author a.name: Eric Schmidt b.e-mail: erics(a)t-com.net c.telephone: ++49 441 234 4592 d.organisation: Deutsche Telekom AG 4.Proposal Version: 5.Submission Date: 2005-05-13 6.Suggested WG for discussion and publication: address-policy-wg or ipv6-wg 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: permanent a.temporary, permanent, or renewable. 9.Summary of proposal There are various terms for "end-site" in the IPv6 allocation and assignment policy (ripe-267) and the RFC3177. We need to have a finally definition for "end-site" to establish clear internal assignment policies 10. Policy text a.Current (if modify): 2.9. End Site An End Site is defined as an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment b.New: 2.9 End Site End-Site defines a customer´s network with an own link to the ISP. The customer could run various networks on different locations (e.g. multiple branches). As long as the networks are all independent and have no internal connection, each network is defined as a single end-site. If the networks have internal connection and only one common link to the ISP, these networks are summarized to one end-site. 2.9a A customer is an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment 11. Rationale: a.Arguments supporting the proposal At last we will have a concrete definition for end-site. There are a lot of discussions even in different RIR regions and as far as i know non of this has reached an conclusion. The rfc3177 defines end site as single edge networks, this is pretty close to my proposal and i think it is easier to update a RIPE policy than an rfc. This question was discussed in the IPv6 maillist before and it looks like that this definition could get a majority approval In the IPv6 End User Site Assignment Request Form (ripe-308) the requester has to confirm that he read the policy document. It is hard for a customer to understand these improper terms. This proposal should not be combined with the /48 /56 discussion which is on at the moment. It´s just a matter of definition b.Arguments opposing the proposal i can´t see anything against this .....

8 12

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

13 Jul '05

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 > >> > >> > >> > >

2 1

RE: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal
by Koepp, Karsten 12 Jul '05

12 Jul '05

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

Re: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site
by Randy Bush 11 Jul '05

11 Jul '05

> change can be good. recognizing and supporting folks who > want to use IP, regardless of where/if they ever decide to > "connect" to me or my peers is a good thing. businesses > change, AUPs change, networks change. facilitating their > interconnection is highly desirable - even if they wont' > interconnect in the forseeable future. or am i missing something? rfc 1918?

1 0

policy proposal status
by Hans Petter Holen 11 Jul '05

11 Jul '05

For my own benefit I made a small table of the current proposals and their relevant status: Number Version proposal Author Proposed date Status Next date alpha 1 TLD Anycast Allocation Policy Andreas Baess 04.03.2005 Returned to author beta 1 IPv4-HD-Ratio Alain Bidron 02.02.2004 Last Call 15.jul gamma 1 IPv6 Initial Allocation Criteria Andy Furnell 04.04.2005 Returned to author delta epsilon 1 Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. Adiel Akplogan 16.04.2005 Last Call 15.jul zeta 1 Adding Regional Boundaries to policy documents Hans Petter Holen 16.04.2005 Withdrawn by author eta 1 IPv6 Address Allocation and Assignment Policy - definition for "End-Site" Eric Schmidt 10.07.2005 Discussion Phase 10.aug There are a couple more proposals in the pipeline: - IPv6 Global policy as prenseted at the last RIPE meeting - Global Policy process in this region (by using the same process as we do for regional policy proposals -hph

1 0

Policy proposal: #gamma IPv6 Initial Allocation Criteria
by Hans Petter Holen 11 Jul '05

11 Jul '05

Dear all, Please find enclosed a policy proposal from Andy Furnell. My proposal is to enter this proposal into the Discussion Phase with a time line of 4 weeks ending on May 9the allowing the discusssion to continue over the RIPE meeting. 1. Number #gamma 2. Policy Proposal Name: IPv6 Initial Allocation Criteria 3. Author a. name: Andy Furnell b. e-mail: andy(a)linx.net c. telephone: +44 (0) 20 7645 3519 d. organisation: London Internet Exchange (LINX) 4. Proposal Version: 1 5. Submission Date: 4/4-2005 6. Suggested WG for discussion and publication: Address Policy WG 7. Proposal type: modify a. new, modify, or delete 8. Policy term: renewable a. temporary, permanent, or renewable. 9. Summary of proposal: The proposal is to change the IPv6 Initial Allocation criteria outlined in the "IPv6 Address Allocation and Assignment Policy" (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed change is to remove "have a plan for making at least 200 /48 assignments to other organisations within two years" and to remove the reference to "/48s" as the assignment size. 10. Policy text a. Current (if modify): 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. b. New: 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to organisations and customers to which it will make assignments by advertising that connectivity through its single aggregated address allocation. 11. Rationale: a. Arguments supporting the proposal Many LIRs' networks do not have 200 customers to make assignments to but still maintain autonomous network and addressing policies. These require address space that is both aggregatable and independent from that of their peers. In addition, a /48 assignment is not always appropriate; ISPs might have different plans for the size of the assignments they will make and the policy should not stand as an obstacle for them. Such a change in the policy will also make IPv6 allocations more accessible and could result in the acceleration of IPv6 development. b. Arguments opposing the proposal With such a change in the policy, every LIR operating an autonomous network would be able to receive an IPv6 allocation. The worst case scenario would be a number of allocations equal to the number of LIRs in the RIPE region. ---------------------------------------------------------------------------

23 115

Policy proposal: #alpha: TLD Anycast Allocation Policy
by Hans Petter Holen 11 Jul '05

11 Jul '05

Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th. Best Regards, Hans Petter 1.Number (assigned by the RIPE NCC) alpha 2.Policy Proposal Name: TLD Anycast Allocation Policy 3.Author a.name: Andreas Baess b.e-mail: baess(a)denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G. 4.Proposal Version: 1 5.Submission Date: 6.Suggested WG for discussion and publication: Address Policy Working Group 7.Proposal type: new 8.Policy term: renewable 9.Summary of proposal To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services. 10. Policy text a.Current: N/A b.New: "If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer." 11. Rationale: PROS A. Acceptance of DNS for special treatment Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.… shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. B. Policy Harmonization Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers. D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks. E. IPv6 Support As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud. CONS F. Waste of Address Space Accepting a number of IPv4/24 and IPv6/32 allocations for critical network infrastructures does not align with the traditional address conservation efforts. With anycasting it is very likely that only a few addresses from the entire assignment would be used. 2. Root DNS are special, others are not RIPE document 233 dated from 24th May 2002 says: "Although it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed by the community that the particular need defined in this document is the only justifiable exception to that general principle." 3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices. Appendix I APNIC Policy (Following section is taken from http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) 11.3 Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; * IANA; * Regional Internet Registry (RIRs); and * National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The minimum assignment made under these terms is /24. Appendix II ARIN Policy (Following section taken from http://ww2.arin.net/policy/index.html#four4) 4.4. Micro-allocation - ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. Appendix III LACNIC (Following section is taken from http://lacnic.net/policy-en.pdf) 3.3.3 Micro Allocations Micro allocation is the name given to those allocations that imply blocks smaller than /20 but always larger than or equal to /24. LACNIC can grant this type of allocation in case of projects and infrastructure for networks that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others. In the case of IXPs or NAPs, in order to be able to apply for this type of allocation, organizations shall meet the following requirements: 1. Duly document the following aspects: 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The organization shall have at least three members and an open policy in relation to the association of new members. 1. 2Submit a company structure organizational diagram. 1. 3Document the numbering plan to be implemented. 2. Provide a usage plan for the following three and six months. The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project. Organizations receiving micro allocations are not authorized to suballocate these addresses.

8 12

RE: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal
by Koepp, Karsten 10 Jul '05

10 Jul '05

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 > >> > >> > >> > >

3 2