From hpholen at tiscali.no Fri Jul 1 00:19:11 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 01 Jul 2005 00:19:11 +0200 Subject: [address-policy-wg] Policy Proposal: #Zeta Adding Regional Boundaries to policy documents In-Reply-To: <4260BB29.1040606@tiscali.no> References: <4260BB29.1040606@tiscali.no> Message-ID: <42C46FDF.3010801@tiscali.no> Dear all, After some thinking I have deceided to withdraw this proposal for two reasons. i) I am not able to find a wording that properly reflects the inention ii) There would be a conflict of interest if I were to declare consensus on a proposal authored by myself. others are of course welcome to reword and submit another proposal. best regards, Hans Petter Holen > Dear Address Policy WG, > This policy proposal is nothing more than an editorial change - but we > still feel it is fair to run it trough the PDP. > As I do not expect much discussion I propose the discussion phase to > end by May 1st. > > While I am voicing this proposal the suggestion actualy comes from our > excellent RIPE NCC staff. Thanks leo for pointing this out. > > Best Regards > Hans Petter Holen > Address Policy > > 1. Number Zeta > > 2. Policy Proposal Name: Adding Regional Boundaries to policy > documents > > 3. Author > > a. name: Hans Petter Holen > > b. e-mail: hpholen at tiscali.no > > c. telephone: +47 45066054 > > d. organisation: Visma IT AS > > 4. Proposal Version: > > > > 5. Submission Date: 16/4-2005 > > > > 6. Suggested WG for discussion and publication > > Address policy type > > > > 7. Proposal type: > > a. modify > > > > 8. Policy term: > > a. permanent > > > > 9. Summary of proposal > > > > Our AS assignment policy has the following statement in it: > > > > "The RIPE NCC assigns AS Numbers for Autonomous Systems > located in the RIPE NCC service region" > > > > Neither the IPv4 nor the IPv6 policy documents have such a > clear statement in them. It might be a good idea to add a > similar statement to those documents when they are updated. > > > > 10. Policy text > > a. Current (if modify): > > b. New: > > > > 11. Rationale: > > a. Arguments supporting the proposal > > Clearification of the scope of the documents > > > b. Arguments opposing the proposal > > n/a > From hpholen at tiscali.no Fri Jul 1 00:37:28 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 01 Jul 2005 00:37:28 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal In-Reply-To: <4228C7CE.2070706@tiscali.no> References: <89E8CBF169FE82408CBC2892EF204394322469@PUEXCBA0.nanterre.francetelecom.fr> <4228C7CE.2070706@tiscali.no> Message-ID: <42C47428.4030408@tiscali.no> 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 at 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 >> >> >> From hpholen at tiscali.no Fri Jul 1 00:44:00 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 01 Jul 2005 00:44:00 +0200 Subject: [address-policy-wg] last Call: Policy Proposal: #epsilon Policy text modifications to take account of,ICANN recognition of AfriNIC as a fully functioning RIR. In-Reply-To: <4260B8D5.4090308@tiscali.no> References: <4260B8D5.4090308@tiscali.no> Message-ID: <42C475B0.8000201@tiscali.no> Following the discussion on the mailinglist and at the RIPE meeting 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 call will end at July 15th. Best Regards Hans Petter Holen WG Chair Hans Petter Holen wrote: > Dear All, > With the formal recognition of AfriNIC as a fully functioning RIR > there is no need to still have special policy provisions for the > AfriNIC region in the RIPE NCC region. > http://www.nro.net/archive/news/20050411-afrinic-final-recognition.html > > As I do not expect much discussion on this Item I propose to end the > discussion period by May 1st. > > > 1.Number (assigned by the RIPE NCC) #epsilon > > 2.Policy Proposal Name: Policy text modifications to take account of > ICANN recognition of AfriNIC as a fully functioning RIR. > > 3.Author > a.name: Adiel Akplogan > b.e-mail: adiel at afrinic.net > c.telephone:+230 259 2409 > d.organisation: AfriNIC > > 4.Proposal Version: 1.0 > > 5.Submission Date: > > 6.Suggested WG for discussion and publication > Address Policy Working Group > > 7.Proposal type: modify > a.new, modify, or delete. > > 8.Policy term: renewable > a.temporary, permanent, or renewable. > > 9.Summary of proposal > To modify the policy document text to reflect full > recognition of AfriNIC as a functioning RIR. > > 10. Policy text > a.Current (if modify): > > "1.0 Introduction > > The RIPE NCC is an independent association and serves as one of four > Regional Internet Registries (RIRs). Its service region > incorporates Europe, the Middle East, Central Asia and African > countries located north of the equator." > > b.New: > > "1.0 Introduction > > The RIPE NCC is an independent association and serves as > one of /five/ Regional Internet Registries (RIRs). Its service region > incorporates Europe, the Middle East, and Central Asia." > > a.Current (if modify): > > "5.1 First Allocation > > The RIPE NCC's minimum allocation size is /21. > > The minimum allocation size for countries in Africa is /22." > > b.New: > > "5.1 First Allocation > > The RIPE NCC's minimum allocation size is /21." > > 11. Rationale: > a.Arguments supporting the proposal > With the recognition of AfriNIC as a fully functioning and > independant RIR there is a need to modify this document > reflecting this change. > > b.Arguments opposing the proposal > None. From filiz at ripe.net Tue Jul 5 14:14:14 2005 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 5 Jul 2005 14:14:14 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to the RIPE NCC Message-ID: <20050705121414.GH2051@x13.ripe.net> Dear Colleagues, The RIPE NCC received the IPv4 address ranges 89.0.0.0/8, 90.0.0.0/8 and 91.0.0.0/8 from the IANA in June 2005. We will begin allocating from these ranges in the near future. The longest prefixes to be allocated and assigned from these /8s are as follows: IPv4 Range Longest Prefix 89/8 /21 90/8 /21 91/8 /29 You may wish to adjust any filters you have in place accordingly. You can find more information on the IP space administered by the RIPE NCC on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Kind regards, -- Filiz Yilmaz RIPE NCC From Karsten.Koepp at lambdanet.net Thu Jul 7 12:33:33 2005 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 7 Jul 2005 12:33:33 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal Message-ID: <39F27E3F569FD4119EF200508BAF85B9067A66DB@CCGNT30> 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 at tiscali.no] > Sent: Friday, July 01, 2005 12:37 AM > Cc: address-policy-wg at 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 at 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 > >> > >> > >> > > From hpholen at tiscali.no Sun Jul 10 13:07:37 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sun, 10 Jul 2005 13:07:37 +0200 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site Message-ID: <42D10179.3060704@tiscali.no> 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 at 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 ..... From hpholen at tiscali.no Sun Jul 10 15:10:43 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sun, 10 Jul 2005 15:10:43 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal In-Reply-To: <39F27E3F569FD4119EF200508BAF85B9067A66DB@CCGNT30> References: <39F27E3F569FD4119EF200508BAF85B9067A66DB@CCGNT30> Message-ID: <42D11E53.6050605@tiscali.no> Hi Karsten, The responses I have seen to the list in favour of the HD ratio to the address-policy mailinglist arefrom * alain.bidron at francetelecom.com * kelaidi at ote.gr * EricS at t-com.net * groeskens at bluewin.ch * debecker at etno.be (on behalf or ETNO in September 2004) From re-reading the entire discussion I see that there has been some discussion on elements that could be interpreted as beeing oppsoed to the proposal as you state - could I ask for clearification from all involved during last call on this so I do not have to interpret language amd make wrong judgement of statements to the list ? As to the procedural point you are quite right that in order to stop this proposal - you need to state - as you did - that you do not support this policy an preferably why. Best Regards, Hans Petter Holen Address Policy WG Chair >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 at tiscali.no] >>Sent: Friday, July 01, 2005 12:37 AM >>Cc: address-policy-wg at 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 at 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 >>>> >>>> >>>> >>>> >>>> >> >> From hpholen at tiscali.no Sun Jul 10 15:11:26 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sun, 10 Jul 2005 15:11:26 +0200 Subject: [address-policy-wg] Minutes from Address Policy WG at RIPE 50 Message-ID: <42D11E7E.6000907@tiscali.no> Dear WG members, The Minutes from the last Address Policy Working Group has been available on the RIPE Web Site for a while: http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html Please let me know if you want to have corrections of amendments made to the minutes. Best Regards, Hans Petter Holen Address Policy Working Group Chair From dogwallah at gmail.com Sun Jul 10 15:40:55 2005 From: dogwallah at gmail.com (McTim) Date: Sun, 10 Jul 2005 08:40:55 -0500 Subject: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal In-Reply-To: <42D11E53.6050605@tiscali.no> References: <39F27E3F569FD4119EF200508BAF85B9067A66DB@CCGNT30> <42D11E53.6050605@tiscali.no> Message-ID: Hi Hans, I agree with karsten, and do NOT support this policy change. Why: Conservation of v4 space is a greater priority for me than potentially easing V. large registries adminstrative overhead. In fact, I have never been convinced about this being a "problem" in the first place. In terms of hierarchy, as long as your v4 sub-allocation or assignment is in the RIPE Db, it is considered in use and counts as part of the 80%. -- Cheers, McTim nic-hdl: TMCG From jeroen at unfix.org Sun Jul 10 19:08:59 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 10 Jul 2005 19:08:59 +0200 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <42D10179.3060704@tiscali.no> References: <42D10179.3060704@tiscali.no> Message-ID: <1121015339.3196.4.camel@firenze.zurich.ibm.com> On Sun, 2005-07-10 at 13:07 +0200, Hans Petter Holen wrote: > 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 This line already describes a site. > 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 These three specify a site using the upstream, which might not be necessary. There are actually sites on this planet (and maybe others ;) that need address space and are never going to connected to the Internet. These last three sentences cause that those sites can't get address space. What should they do, use some random number? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Sun Jul 10 20:38:48 2005 From: randy at psg.com (Randy Bush) Date: Sun, 10 Jul 2005 08:38:48 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> Message-ID: <17105.27448.765860.657230@roam.psg.com> > These three specify a site using the upstream, which might not be > necessary. There are actually sites on this planet (and maybe others ;) > that need address space and are never going to connected to the > Internet. classically, if they have no plan to be connected, they don't get address space. randy From randy at psg.com Mon Jul 11 00:38:51 2005 From: randy at psg.com (Randy Bush) Date: Sun, 10 Jul 2005 12:38:51 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com.> Message-ID: <17105.41851.247530.275951@roam.psg.com> >> classically, if they have no plan to be connected, they don't get >> address space. > may have been true when the only network was ARPAnet. > with the advent of Internet, if you could demonstrate runing IP > you could get addresses (mostly true) > remember the "connected/unconnected" database? nope. sri internet days, netsol address days, ... even today, it says if you will be connecting to the network. it even makes sense. if you're not going to be on the internet, why the heck do you need an internet address? randy From bmanning at vacation.karoshi.com Mon Jul 11 00:24:51 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 10 Jul 2005 22:24:51 +0000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17105.27448.765860.657230@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> Message-ID: <20050710222451.GA25281@vacation.karoshi.com.> On Sun, Jul 10, 2005 at 08:38:48AM -1000, Randy Bush wrote: > > These three specify a site using the upstream, which might not be > > necessary. There are actually sites on this planet (and maybe others ;) > > that need address space and are never going to connected to the > > Internet. > > classically, if they have no plan to be connected, they don't get > address space. > > randy may have been true when the only network was ARPAnet. with the advent of Internet, if you could demonstrate runing IP you could get addresses (mostly true) remember the "connected/unconnected" database? --bill From bmanning at vacation.karoshi.com Mon Jul 11 06:04:23 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 11 Jul 2005 04:04:23 +0000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17105.41851.247530.275951@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com.> <17105.41851.247530.275951@roam.psg.com> Message-ID: <20050711040423.GA697@vacation.karoshi.com.> On Sun, Jul 10, 2005 at 12:38:51PM -1000, Randy Bush wrote: > >> classically, if they have no plan to be connected, they don't get > >> address space. > > may have been true when the only network was ARPAnet. > > with the advent of Internet, if you could demonstrate runing IP > > you could get addresses (mostly true) > > remember the "connected/unconnected" database? > > nope. sri internet days, netsol address days, ... even today, it > says if you will be connecting to the network. true... but the "network" has changed over time. this i know becuase the commercial US defense contractor that i worked for was not able to join the ARPAnet directly (AUP issues) - we were assigned numbers from the "unconnected" database for oour global network - then the AUP changed and we were connected ... and found that the connected/unconnected databases overlapped ... my task was to renumber 134 sites. Others had similar history. > it even makes sense. if you're not going to be on the internet, > why the heck do you need an internet address? because I'm running IP-based infrastructure.... and (presuming the IPv6-enabled world) there is zero reason to treat addresses as an artifically scarce resource. Routing ... thats something else. Raw addresses - not a scarce resource. > > randy From randy at psg.com Mon Jul 11 09:26:32 2005 From: randy at psg.com (Randy Bush) Date: Sun, 10 Jul 2005 21:26:32 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com.> <17105.41851.247530.275951@roam.psg.com> <20050711040423.GA697@vacation.karoshi.com.> Message-ID: <17106.7976.943184.251184@roam.psg.com> >>>> classically, if they have no plan to be connected, they don't get >>>> address space. >>> may have been true when the only network was ARPAnet. >>> with the advent of Internet, if you could demonstrate runing IP >>> you could get addresses (mostly true) >>> remember the "connected/unconnected" database? >> nope. sri internet days, netsol address days, ... even today, it >> says if you will be connecting to the network. > true... but the "network" has changed over time. so, what you actually mean is that you don't like the way things are and would like to change the status quo. that's discussable. randy From Niall.oReilly at ucd.ie Mon Jul 11 11:11:42 2005 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 11 Jul 2005 10:11:42 +0100 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17105.41851.247530.275951@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com> <17105.41851.247530.275951@roam.psg.com> Message-ID: <26ed60f98eb219b3db6092064e60fa2f@ucd.ie> On 10 Jul 2005, at 23:38, Randy Bush wrote: > it even makes sense. if you're not going to be on the internet, > why the heck do you need an internet address? RFC1918 presents credible reasons for needing an internet address, even without a plan to connect to the Internet, and defines a number of ranges of "site-local" IPv4 addresses which may be used. RFC3879 deprecates "site-local" addresses for IPv6. I'm told that the thinking is that sites should fence off a part of their globally-routable IPv6 assignment for any "enterprise-local" requirements they may have. This leads to a significant difficulty if obtaining an address assignment is precluded by policy. As Jeroen says, > What should they do, use some random number? 2002:0a00/24 anyone? I am AGAINST this policy change until the issue of "site-local" or "enterprise-local" addressing is satisfactorily resolved. /Niall From woeber at cc.univie.ac.at Mon Jul 11 11:38:27 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 11 Jul 2005 09:38:27 +0000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17105.27448.765860.657230@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> Message-ID: <42D23E13.5090606@cc.univie.ac.at> Randy Bush wrote: >>These three specify a site using the upstream, which might not be >>necessary. There are actually sites on this planet (and maybe others ;) >>that need address space and are never going to connected to the >>Internet. > > > classically, if they have no plan to be connected, they don't get > address space. ...and do you think this is how it should be? > randy Wilfried From hpholen at tiscali.no Mon Jul 11 12:21:40 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Jul 2005 12:21:40 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <4260B892.2050901@tiscali.no> References: <4228B939.2020509@tiscali.no> <4260B892.2050901@tiscali.no> Message-ID: <42D24834.5060608@tiscali.no> Dear all, I find it hard to see a clear consensus on this proposal and will ask the RIPE NCC to summarize the concerns in the process and asssist the author to reformulate the proposal to take theese concerns into account. We vill then reopen the discussion phase as soon as there is a revised version of the proposal. Best Regards, Hans Petter Holen Address Policy Chair ------------------------------------------------------------------------ > Dear all, > After concideration and consultation with mu co-chairs I propose to > exted the discussion period to May 6th so we still have oportunity to > discuss this at the RIPE meeting. > > Best Regards, > Hans Petter Holen > Address Policy Chair > > Hans Petter Holen wrote: > >> 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 at 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.pdf >> >> 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. >> >> >> From hpholen at tiscali.no Mon Jul 11 12:36:54 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Jul 2005 12:36:54 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <4250C946.5020502@tiscali.no> References: <4250C946.5020502@tiscali.no> Message-ID: <42D24BC6.9000306@tiscali.no> Dear WG, I find it dfficult to see a clear consensus on this proposal. While I do sense some consensus for a change, there is no clear consensus to completely remove the 200 customer requirement. I will ask the RIPE NCC to assist the author to take into accounts the concerns raised in the discussion and see if the proposal can me adjusted to take this into account. I will further point to the summary made by Filiz Yilmaz http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2004/msg00427.html on the changes that has been made in other regions. In addition I would like to point the author to the ARIN policy where being an exisiting LIR and an existing IPv4 customer base and infrastructure can be used to qualify for v6 space as one possible way forward. We will restart the discussion when thee is a revised proposal. Best Regards, Hans Petter Holen Address Policy Chair > 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 at 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. > > --------------------------------------------------------------------------- > From hpholen at tiscali.no Mon Jul 11 12:56:11 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Jul 2005 12:56:11 +0200 Subject: [address-policy-wg] policy proposal status Message-ID: <42D2504B.6000200@tiscali.no> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Jul 11 18:49:59 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 06:49:59 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com.> <17105.41851.247530.275951@roam.psg.com> <20050711040423.GA697@vacation.karoshi.com.> <17106.7976.943184.251184@roam.psg.com> <20050711073227.GA2322@vacation.karoshi.com.> Message-ID: <17106.41783.933866.344248@roam.psg.com> > 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? From randy at psg.com Mon Jul 11 19:05:40 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 07:05:40 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> Message-ID: <17106.42724.429772.421162@roam.psg.com> >> classically, if they have no plan to be connected, they don't get >> address space. > ...and do you think this is how it should be? in ipv4, yes. in ipv6, i am ambivalent. i don't believe v6 space is effectively so vast it can be wasted, especially with magic boundaries at /64 and /48. i also don't believe in site-local routing. though it was called site local _addressing_. the ivtf keeps confusing addressing and routing and neglecting the interactions and the implications. but i have no problem with an rfc 1918 equivalent in ipv6. on the other hand, it's can be fun to ask the question this way. since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet. randy From dr at cluenet.de Mon Jul 11 19:16:14 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 11 Jul 2005 19:16:14 +0200 Subject: [address-policy-wg] Re: Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17106.42724.429772.421162@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> Message-ID: <20050711171614.GA3782@srv01.cluenet.de> On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote: > on the other hand, it's can be fun to ask the question this way. > since you will never be connected to the internet, why not just > use whatever address space comes to mind? oh, you're worried > about collisions? with whom? you said you were not connecting to > the internet. "extranets"... Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Mon Jul 11 19:47:08 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 07:47:08 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <20050710222451.GA25281@vacation.karoshi.com> <17105.41851.247530.275951@roam.psg.com> <26ed60f98eb219b3db6092064e60fa2f@ucd.ie> Message-ID: <17106.45212.541513.50852@roam.psg.com> > RFC3879 deprecates "site-local" addresses for IPv6. I'm told > that the thinking is that sites should fence off a part of their > globally-routable IPv6 assignment for any "enterprise-local" > requirements they may have. the thinking at the time of killing site-local addresses was that, as they were specified, they had very complex and ill-thought-out routing implications (somewhat typical of the ivtf's ipv6 effort). >> What should they do, use some random number? > 2002:0a00/24 anyone? if they are really not connecting, why do we or they care? if they might be connecting, then we have to make some decisions. randy From randy at psg.com Mon Jul 11 21:54:17 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 09:54:17 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> <20050711194114.GA5754@vacation.karoshi.com.> Message-ID: <17106.52841.771520.334698@roam.psg.com> > Never is such a long time.... that's deep. i'll have to think about it over a second cup of morning coffee. it's not ours to judge why someone says they will never connect. but my trick question >> on the other hand, it's can be fun to ask the question this way. >> since you will never be connected to the internet, why not just >> use whatever address space comes to mind? oh, you're worried >> about collisions? with whom? you said you were not connecting to >> the internet. was designed to make them think about it about as much as we politely can. randy From hpholen at tiscali.no Tue Jul 12 09:04:14 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Tue, 12 Jul 2005 09:04:14 +0200 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17106.42724.429772.421162@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> Message-ID: <42D36B6E.1060509@tiscali.no> Randy Bush wrote: > on the other hand, it's can be fun to ask the question this way. > >since you will never be connected to the internet, why not just >use whatever address space comes to mind? oh, you're worried >about collisions? with whom? you said you were not connecting to >the internet. > > As I have in the past been involved in a couple of such requests in the past I can add the arguments as I remember they were used then: - we are going to connect to networks who are connected to other networks and some of them may be connected to the inthernet - thus the need for globaly unique adresses - we may at some future point be connected to the internet. In other works I think the definitions of "never" and of "the Internet" are important here. Maybe its better to ask are you prepared to renumber your network when you connect to another network ? -hph From marc.van.selm at nc3a.nato.int Tue Jul 12 09:18:45 2005 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Tue, 12 Jul 2005 09:18:45 +0200 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <42D36B6E.1060509@tiscali.no> References: <17106.42724.429772.421162@roam.psg.com> <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> Message-ID: <4.3.2.7.2.20050712090823.00be5c30@wheresmymailserver.com> At 09:04 12/07/05, Hans Petter Holen wrote: >Randy Bush wrote: > >>on the other hand, it's can be fun to ask the question this way. >> >>since you will never be connected to the internet, why not just >>use whatever address space comes to mind? oh, you're worried >>about collisions? with whom? you said you were not connecting to >>the internet. >> >As I have in the past been involved in a couple of such requests in the >past I can add the arguments as I remember they were used then: >- we are going to connect to networks who are connected to other networks >and some of them may be connected to the inthernet - thus the need for >globaly unique adresses >- we may at some future point be connected to the internet. > >In other works I think the definitions of "never" and of "the Internet" >are important here. > >Maybe its better to ask are you prepared to renumber your network when you >connect to another network ? It is also useful to look at this from the perspective of convergency. If we put that to the extreme (and who knows if that is realism or not but a policy is valid for quite a while), there might in the future only be one IP network. Closed islands will then be carefully encrypted, use high grade end-to-end encryption) and advanced fire walling will do the rest (whatever). At the same time other portions are the Internet as we know it. So if we look at a potential for an extremely converged future, what does not connected mean? Today, yes, in 30 years from now, who knows? In my view it is best to do away with "private" address space concepts and plan for permanently fully de-conflicted networks. Connected or not. In my work, I see the consequences in NATO and national defence networks. I can imagine that these consequences of not using public IP space are the same if one merges 2 large cooperations and tries to integrate the infrastructures. Cheers, Marc >-hph --------------------------------------------------------- Marc van Selm NATO C3 Agency, CISD ********************************************************* ** -- This mail is personal -- ** ** All statements in this mail are made from my own ** ** personal perspective and do not necessarily reflect ** ** my employer's opinions or policies. ** ********************************************************* From randy at psg.com Tue Jul 12 09:23:01 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 21:23:01 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> <42D36B6E.1060509@tiscali.no> Message-ID: <17107.28629.190622.896927@roam.psg.com> >> since you will never be connected to the internet, why not just >> use whatever address space comes to mind? oh, you're worried >> about collisions? with whom? you said you were not connecting to >> the internet. > > As I have in the past been involved in a couple of such requests in the > past I can add the arguments as I remember they were used then: > - we are going to connect to networks who are connected to other > networks and some of them may be connected to the inthernet - thus the > need for globaly unique adresses > - we may at some future point be connected to the internet. yep. expected. so please go to your nearest rir and get real address space. > Maybe its better to ask are you prepared to renumber your network when > you connect to another network ? the answer to that will always be "yes" as you did not scope 'when' randy From bmanning at vacation.karoshi.com Mon Jul 11 21:41:14 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 11 Jul 2005 19:41:14 +0000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17106.42724.429772.421162@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> Message-ID: <20050711194114.GA5754@vacation.karoshi.com.> On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote: > >> classically, if they have no plan to be connected, they don't get > >> address space. > > ...and do you think this is how it should be? > > in ipv4, yes. > > in ipv6, i am ambivalent. i don't believe v6 space is effectively > so vast it can be wasted, especially with magic boundaries at /64 > and /48. i also don't believe in site-local routing. though it > was called site local _addressing_. the ivtf keeps confusing > addressing and routing and neglecting the interactions and the > implications. but i have no problem with an rfc 1918 equivalent > in ipv6. > > on the other hand, it's can be fun to ask the question this way. > since you will never be connected to the internet, why not just > use whatever address space comes to mind? oh, you're worried > about collisions? with whom? you said you were not connecting to > the internet. > > randy Never is such a long time.... --bill From randy at psg.com Tue Jul 12 09:26:17 2005 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2005 21:26:17 -1000 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site References: <17106.42724.429772.421162@roam.psg.com> <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <4.3.2.7.2.20050712090823.00be5c30@wheresmymailserver.com> Message-ID: <17107.28825.377257.92523@roam.psg.com> actually, the american national offense network is notable for disconnecting from the internet. randy From alain.bidron at francetelecom.com Tue Jul 12 10:18:41 2005 From: alain.bidron at francetelecom.com (BIDRON Alain ROSI/DAS) Date: Tue, 12 Jul 2005 10:18:41 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Message-ID: <89E8CBF169FE82408CBC2892EF2043948935D1@PUEXCBA0.nanterre.francetelecom.fr> 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 at ripe.net [mailto:address-policy-wg-admin at ripe.net]De la part de Koepp, Karsten Envoy? : jeudi 7 juillet 2005 12:34 ? : 'Hans Petter Holen' Cc : address-policy-wg at 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 at tiscali.no] > Sent: Friday, July 01, 2005 12:37 AM > Cc: address-policy-wg at 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 at 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 > >> > >> > >> > > From Karsten.Koepp at lambdanet.net Tue Jul 12 12:20:02 2005 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Tue, 12 Jul 2005 12:20:02 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD rati o policy proposal Message-ID: <39F27E3F569FD4119EF200508BAF85B9067A6703@CCGNT30> 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 at francetelecom.com] > Sent: Tuesday, July 12, 2005 10:19 AM > To: Koepp, Karsten; Hans Petter Holen > Cc: address-policy-wg at 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 at ripe.net > [mailto:address-policy-wg-admin at ripe.net]De la part de Koepp, Karsten > Envoy? : jeudi 7 juillet 2005 12:34 > ? : 'Hans Petter Holen' > Cc : address-policy-wg at 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 at tiscali.no] > > Sent: Friday, July 01, 2005 12:37 AM > > Cc: address-policy-wg at 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 at 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 > > >> > > >> > > >> > > > > > From Michael.Dillon at btradianz.com Tue Jul 12 13:23:12 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 12 Jul 2005 12:23:12 +0100 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17105.41851.247530.275951@roam.psg.com> Message-ID: > it even makes sense. if you're not going to be on the internet, > why the heck do you need an internet address? Because you are building an internetwork using the Internet Protocol. Perhaps you are connecting together several networks, some of which might also be connected to the Internet and as a result, you need globally unique addresses. If you can't imagine a "network which might be connected to the Internet" then consider a company like DeutscheBank. They have hundreds of locations connected together and one would expect that some of the sub-networks within their corporate network are rather secure because they handle millions of euros in financial transactions every day. At the same time, hundreds of DeutscheBank employees need access to the Internet through some other sub-networks. Now imagine that the financial transaction side of the business needs to connect to an IP internetwork in order to transact business with other banks and financial institutions but that this IP internetwork is not the Internet and is not connected to the Internet. There was a time when we could visualize the Internet as a nice cloud which everyone connected to. Nowadays, the picture is rather less clear as because there are many, many international IP internetworks that are not the public Internet. If you go back to that cloud picture, imagine that the millions of sites connected to the cloud form a kind of fur that surrounds the cloud. Then imagine that there are some very thin membranes that touch the tips of the fur but do not touch the cloud itself. According to RFC 2050, these membranes deserve to get registered IP addresses because they are NOT private networks. They are internetworks. --Michael Dillon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.rastas at teliasonera.com Wed Jul 13 12:50:33 2005 From: kristian.rastas at teliasonera.com (Kristian Rastas) Date: Wed, 13 Jul 2005 13:50:33 +0300 Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal In-Reply-To: <89E8CBF169FE82408CBC2892EF2043948935D1@PUEXCBA0.nanterre.francetelecom.fr> References: <89E8CBF169FE82408CBC2892EF2043948935D1@PUEXCBA0.nanterre.francetelecom.fr> Message-ID: <42D4F1F9.9070804@teliasonera.com> Hello all, BIDRON Alain ROSI/DAS wrote: > 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. Just a comment, at least our registry fi.sonera doesn't support this proposal, and we have never posted a supporting message as a registry to ETNO as far as I remember. Second thing, as an XL-registry, at least we haven't encountered any problems with the old policy and I personally think it shouldn't be changed. IPv4 and IPv6 are different species regarding address space and many good comments have already been posted here, so I will not repeat them. Best regards, Kristian Rastas fi.sonera From gert at space.net Wed Jul 13 23:41:10 2005 From: gert at space.net (Gert Doering) Date: Wed, 13 Jul 2005 23:41:10 +0200 Subject: [address-policy-wg] Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site In-Reply-To: <17106.42724.429772.421162@roam.psg.com> References: <42D10179.3060704@tiscali.no> <1121015339.3196.4.camel@firenze.zurich.ibm.com> <17105.27448.765860.657230@roam.psg.com> <42D23E13.5090606@cc.univie.ac.at> <17106.42724.429772.421162@roam.psg.com> Message-ID: <20050713214110.GF84850@Space.Net> Hi, On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote: > but i have no problem with an rfc 1918 equivalent in ipv6. The ULA approaches seem quite a nice approach to me... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From hpholen at tiscali.no Wed Jul 13 23:29:21 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 13 Jul 2005 23:29:21 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <200406152312.01778.ripe-lst@eirconnect.net> References: <20040615173628.0363a350.laura@ripe.net> <200406152312.01778.ripe-lst@eirconnect.net> Message-ID: <42D587B1.3020305@tiscali.no> Sascha Luck wrote: > >Again, this seems to exclude mobile operators who may only want to assign /64s >to their customers' handsets... > > I dont se how that assumption can be made. My mobile handset is connected to the public internet so that I can get updated exchange rates and read my email trough IMAP and so on. (and not trough NAT as my mobile operator has offered my the choice of not using NAT.) Iff this had been IPv6 and Iff Bluetooth had worked seemlessly on my other toys they could have had seemless access to the internet also. -hph From narten at us.ibm.com Thu Jul 14 10:17:47 2005 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 14 Jul 2005 10:17:47 +0200 Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt Message-ID: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> 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 To: global-v6 at 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-considerations-00.txt 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.txt 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 at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ------- End of Forwarded Message From alain.bidron at francetelecom.com Thu Jul 14 11:43:59 2005 From: alain.bidron at francetelecom.com (BIDRON Alain ROSI/DAS) Date: Thu, 14 Jul 2005 11:43:59 +0200 Subject: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Message-ID: <89E8CBF169FE82408CBC2892EF204394322526@PUEXCBA0.nanterre.francetelecom.fr> 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 at lambdanet.net] Envoy? : mardi 12 juillet 2005 12:20 ? : BIDRON Alain ROSI/DAS Cc : address-policy-wg at 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 at francetelecom.com] > Sent: Tuesday, July 12, 2005 10:19 AM > To: Koepp, Karsten; Hans Petter Holen > Cc: address-policy-wg at 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 at ripe.net > [mailto:address-policy-wg-admin at ripe.net]De la part de Koepp, Karsten > Envoy? : jeudi 7 juillet 2005 12:34 > ? : 'Hans Petter Holen' > Cc : address-policy-wg at 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 at tiscali.no] > > Sent: Friday, July 01, 2005 12:37 AM > > Cc: address-policy-wg at 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 at 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 > > >> > > >> > > >> > > > > > From niallm at enigma.ie Thu Jul 14 15:47:26 2005 From: niallm at enigma.ie (Niall Murphy) Date: Thu, 14 Jul 2005 14:47:26 +0100 Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt In-Reply-To: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> References: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> Message-ID: <1121348846.12787.182.camel@niall.desktop.amazon.com> 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-considerations-00.txt 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. Niall From bmanning at vacation.karoshi.com Thu Jul 14 16:41:58 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 14 Jul 2005 14:41:58 +0000 Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt In-Reply-To: <1121348846.12787.182.camel@niall.desktop.amazon.com> References: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> <1121348846.12787.182.camel@niall.desktop.amazon.com> Message-ID: <20050714144158.GA21978@vacation.karoshi.com.> On Thu, Jul 14, 2005 at 02:47:26PM +0100, Niall Murphy wrote: > 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-considerations-00.txt > > 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. an IPv4 /24 is 192.0.2.0-192.0.2.255 or 256 discreate numbers. subtract the all-ones and all-zeros.. 256-2 = 254... BUT ... wrap the /24 into a /22 and you -CAN- use the (apparent) zero & one nubmers are host assignments. the trick is in the mask and the placement of the "/24" in the overall announcement... you can't have an all-ones or all-zeros for the host. > > Niall --bill From president at ukraine.su Fri Jul 15 09:31:42 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 15 Jul 2005 11:31:42 +0400 Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt In-Reply-To: <1121348846.12787.182.camel@niall.desktop.amazon.com> References: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> <1121348846.12787.182.camel@niall.desktop.amazon.com> Message-ID: <200507151131.42726.president@ukraine.su> Hi! Why not? It CAN. You said about /24 bounded into one ethernet network. But for example I am giving my users real IP over VPN connection. As it is point-to-point connection, there is no network and broadcast addresses at all, and x.x.x.0, x.x.x.255 works. Same is for dial-up. But! Seldom I am experiencing some problems with that kind of addresses. There is a number misconfigured "antihackers" filters on the Net blocks .0 and .255 as they thinks it is always broadcasts. A bit soul-save discussion with such admins usually fixes the problem ;) > 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-considerat > >ions-00.txt > > 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. > > Niall -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Patrick.Guelat at imp.ch Fri Jul 15 10:29:25 2005 From: Patrick.Guelat at imp.ch (Patrick.Guelat at imp.ch) Date: Fri, 15 Jul 2005 10:29:25 +0200 (CEST) Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt In-Reply-To: <200507151131.42726.president@ukraine.su> References: <200507140817.j6E8HlPb014642@cichlid.raleigh.ibm.com> <1121348846.12787.182.camel@niall.desktop.amazon.com> <200507151131.42726.president@ukraine.su> Message-ID: <20050715102154.E1862@murphy.imp.ch> On Fri, 15 Jul 2005, Max Tulyev wrote: > But! Seldom I am experiencing some problems with that kind of addresses. There > is a number misconfigured "antihackers" filters on the Net blocks .0 and .255 > as they thinks it is always broadcasts. A bit soul-save discussion with such > admins usually fixes the problem ;) Unfortunately this is not the experience I have from the field. We're using superneted /20 blocks composed out of `class c'-ranges for cable-tv broadband customers. I had to change the DHCP-server to prevent the assignment of .0 and .255 since we've got a lot of problems with such misconfigured filters in the net and we didn't have the time for all those 'soul-save' discussions with admins not understanding the concept of classless ip-routing. Patrick From narten at us.ibm.com Fri Jul 15 14:30:53 2005 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 Jul 2005 14:30:53 +0200 Subject: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt In-Reply-To: Message from Niall Murphy of "Thu, 14 Jul 2005 14:47:26 BST." <1121348846.12787.182.camel@niall.desktop.amazon.com> Message-ID: <200507151230.j6FCUrAK005993@cichlid.raleigh.ibm.com> Niall Murphy 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-considerations-00.txt > 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 From hph at oslo.net Mon Jul 18 00:23:31 2005 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 18 Jul 2005 00:23:31 +0200 Subject: [address-policy-wg] Administrative: New chair email address In-Reply-To: References: Message-ID: <42DADA63.4040306@oslo.net> 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 at 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 at 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 at 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 at ripe.net (address-policy-wg-admin at 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. > > > ><> > > From gert at space.net Mon Jul 18 14:33:51 2005 From: gert at space.net (Gert Doering) Date: Mon, 18 Jul 2005 14:33:51 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <42D587B1.3020305@tiscali.no> References: <20040615173628.0363a350.laura@ripe.net> <200406152312.01778.ripe-lst@eirconnect.net> <42D587B1.3020305@tiscali.no> Message-ID: <20050718123351.GH84850@Space.Net> Hi, On Wed, Jul 13, 2005 at 11:29:21PM +0200, Hans Petter Holen wrote: > >Again, this seems to exclude mobile operators who may only want to assign > >/64s to their customers' handsets... > > I dont se how that assumption can be made. My mobile handset is > connected to the public internet so that I can get updated exchange > rates and read my email trough IMAP and so on. > > (and not trough NAT as my mobile operator has offered my the choice of > not using NAT.) > > Iff this had been IPv6 and Iff Bluetooth had worked seemlessly on my > other toys they could have had seemless access to the internet also. Which would work fine with a /64 - "one big LAN with enough IPs"... This yields two questions: - is it likely that we'll see mobile handsets that provide connectivity to *two* (or more) independent IPv6 LAN networks? Like "bluetooth and WLAN, and not bridged"? - would a /60 suffice? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From hph at oslo.net Tue Jul 19 08:37:38 2005 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 19 Jul 2005 08:37:38 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20050718123351.GH84850@Space.Net> References: <20040615173628.0363a350.laura@ripe.net> <200406152312.01778.ripe-lst@eirconnect.net> <42D587B1.3020305@tiscali.no> <20050718123351.GH84850@Space.Net> Message-ID: <42DC9FB2.20903@oslo.net> Gert Doering wrote: >Hi, > >On Wed, Jul 13, 2005 at 11:29:21PM +0200, Hans Petter Holen wrote: > > >>>Again, this seems to exclude mobile operators who may only want to assign >>>/64s to their customers' handsets... >>> >>> >>I dont se how that assumption can be made. My mobile handset is >>connected to the public internet so that I can get updated exchange >>rates and read my email trough IMAP and so on. >> >>(and not trough NAT as my mobile operator has offered my the choice of >>not using NAT.) >> >>Iff this had been IPv6 and Iff Bluetooth had worked seemlessly on my >>other toys they could have had seemless access to the internet also. >> >> > >Which would work fine with a /64 - "one big LAN with enough IPs"... > >This yields two questions: > > - is it likely that we'll see mobile handsets that provide connectivity > to *two* (or more) independent IPv6 LAN networks? > > Yes - as I mentioned during the last RIPE meeting we are now seeing "Mobile broadband" products based on UMTS or EDGE and priced like xDSL in Norway - so if you are in a city and out of DSL coverage you can go mobile. In other words I do not think you can make the desicion on how many networks you need based on the transport technology - but there need to be some other cirteria. > Like "bluetooth and WLAN, and not bridged"? > > - would a /60 suffice? > > My feeling today is that in most cases a /64 will be sufficient for any *personal* network and going to /63 or /62 for advanced homes - but if I am to look 100 years into the future it is harder to say. Hans Petter From leo at ripe.net Wed Jul 20 10:54:53 2005 From: leo at ripe.net (leo vegoda) Date: Wed, 20 Jul 2005 10:54:53 +0200 Subject: [address-policy-wg] New IPv6 Address Block Allocated to RIPE NCC Message-ID: <56EE9A3C-5CC8-403B-8B20-C86914F7305E@ripe.net> 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 From ncc at ripe.net Wed Jul 20 15:37:02 2005 From: ncc at ripe.net (Axel Pawlik) Date: Wed, 20 Jul 2005 15:37:02 +0200 Subject: [address-policy-wg] Presentation of the WGIG Report Message-ID: <5.2.1.1.2.20050720151956.02ed0da8@mailhost.ripe.net> 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 From hph at oslo.net Thu Jul 21 00:23:12 2005 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 21 Jul 2005 00:23:12 +0200 Subject: [address-policy-wg] The Register: ICANN prez delivers internet vision Message-ID: <42DECED0.4060206@oslo.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trpix.gif Type: image/gif Size: 43 bytes Desc: not available URL: From webmaster at ripe.net Wed Jul 27 15:44:27 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 27 Jul 2005 15:44:27 +0200 Subject: [address-policy-wg] New Document available: RIPE-349 Message-ID: <200507271344.j6RDiRmq024813@birch.ripe.net> 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