new IPv6 policy framework
Dear LIRs, Following the discussions at the RIPE 39 meeting and on the mailing lists in all the RIR communities, please find below the latest developments concerning IPv6 address allocation policies. This proposal is based on requirements expressed by the RIPE community as well as those of the other RIR communities. Please note that the text below is not a replacement of the current policy document, but rather a summary of the new IPv6 address allocation framework. Therefore this proposal is intended as input for further discussion in the RIPE community. When formulating this framework, we were specifically taking the following feedback into account: - The allocation criteria should be such that it is easy to obtain IPv6 address space. - The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites. This results in the following changes to previously discussed IPv6 allocation criteria: 1. to recognise existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks. 2. to apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure 3. to reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown) 4. to measure the utilisation rate with the HD ratio rather than percentages 5. to make subsequent allocations when the HD ratio is reached Kind Regards, Mirjam Kuehne RIPE NCC ---------------- 1. Abstract This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks. 2. Overview Under the current system of management of global IP address space, Regional Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions. In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised. It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process. This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here. 3. Address Space Requirement for Initial Allocation It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks. In assessing a request for an initial allocation, there are 3 possible cases to consider: 3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation 3.2. the requesting organisation has an existing IPv6 network 3.3. the requesting organisation has no network at all 3.1. Case 1 - Existing IPv4 services Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6. Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future. 3.2. Case 2 - Existing IPv6 services Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database). Where existing address space is no longer used, it must be returned. 3.3. Case 3 - No existing IPv4 or IPv6 services Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately. 4. Size of Initial Allocation The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network. For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited. 5. Qualification for Subsequent Allocation An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space. An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation. 6. Address Space Requirement for Subsequent Allocation For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development. In general, the RIR should provide address space for a fixed time period of 2 years. The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made. 7. IPv6 Utilisation Metric: the HD-Ratio In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held. For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715). Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks. More details about the HD ratio can be found in Appendix A. Appendix A: In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows: log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects) Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned): log(A) log(A) In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1%
Though this is a good document it does not cater for the needs of Multinational Registries, i specifily asked for the MIR proposal to be included in this discussion. This document caters for the single LIR not mutiple LIR's in one very large pan EMEA network, which is still growing. I would like to see this included in the draft, or reasons why the community (not the NCC) are opposed to the MIR proposal for IPV6 (and ipv4 also). To date there has been no negative comments on the porposal which is why i am puzzled it is not included. Regards, Stephen Burley UUNET EMEA Hostmaster SB855-RIPE
Dear LIRs,
Following the discussions at the RIPE 39 meeting and on the mailing lists in all the RIR communities, please find below the latest developments concerning IPv6 address allocation policies. This proposal is based on requirements expressed by the RIPE community as well as those of the other RIR communities.
Please note that the text below is not a replacement of the current policy document, but rather a summary of the new IPv6 address allocation framework. Therefore this proposal is intended as input for further discussion in the RIPE community.
When formulating this framework, we were specifically taking the following feedback into account:
- The allocation criteria should be such that it is easy to obtain IPv6 address space.
- The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites.
This results in the following changes to previously discussed IPv6 allocation criteria:
1. to recognise existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks.
2. to apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure
3. to reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown)
4. to measure the utilisation rate with the HD ratio rather than percentages
5. to make subsequent allocations when the HD ratio is reached
Kind Regards, Mirjam Kuehne RIPE NCC ----------------
1. Abstract
This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks.
2. Overview
Under the current system of management of global IP address space,
Regional
Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions.
In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised.
It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process.
This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here.
3. Address Space Requirement for Initial Allocation
It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks.
In assessing a request for an initial allocation, there are 3 possible cases to consider:
3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation
3.2. the requesting organisation has an existing IPv6 network
3.3. the requesting organisation has no network at all
3.1. Case 1 - Existing IPv4 services
Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6.
Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future.
3.2. Case 2 - Existing IPv6 services
Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database).
Where existing address space is no longer used, it must be returned.
3.3. Case 3 - No existing IPv4 or IPv6 services
Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately.
4. Size of Initial Allocation
The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network.
For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited.
5. Qualification for Subsequent Allocation
An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space.
An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation.
6. Address Space Requirement for Subsequent Allocation
For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development.
In general, the RIR should provide address space for a fixed time period of 2 years.
The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made.
7. IPv6 Utilisation Metric: the HD-Ratio
In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held.
For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715).
Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks.
More details about the HD ratio can be found in Appendix A.
Appendix A:
In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows:
log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects)
Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned):
log(A) log(A)
In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as:
((48-P)*HD) T = 2
In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations.
The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8
P 48-P Total /48s Threshold Util%
48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1%
On Tue, Sep 25, 2001 at 09:11:17AM +0000, Mirjam Kuehne wrote: Hi Mir et al, Please below find my preliminary thoughts/comments on this document. [Aspirations preserved, so we can remember them later]
- The allocation criteria should be such that it is easy to obtain IPv6 address space.
- The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites.
1. to recognise existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks.
2. to apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure
3. to reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown)
4. to measure the utilisation rate with the HD ratio rather than percentages
5. to make subsequent allocations when the HD ratio is reached
3.1. Case 1 - Existing IPv4 services
Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future.
Am I alone in wondering exactly what the scope of these additional policies may be? My concern is based on the fact that although existing v4 networks may well acquire v6 space, they are likely to need their v4 space for quite some years to come, and hence it would be unrealistic to require the return of all v4 address space. (Or maybe I misunderstand...)
4. Size of Initial Allocation
For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited.
These v6 allocations are made from the RIR (ex TLA) space, correct? So, are we abandoning the model where only the biggest networks go to the RIRs for space, and everyone else goes to them? Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/
Niall, Niall Richard Murphy <niallm-ripe@enigma.ie> writes: * On Tue, Sep 25, 2001 at 09:11:17AM +0000, Mirjam Kuehne wrote: * * Hi Mir et al, * * Please below find my preliminary thoughts/comments on this document. * * [Aspirations preserved, so we can remember them later] * > - The allocation criteria should be such that it is easy to obtain * > IPv6 address space. * * > - The size of the initial allocation should be large enough to allow * > flexibility in addressing infrastructure and customer sites. * * > 1. to recognise existing infrastructure (both IPv4 and IPv6) where it * > exists and calculate IPv6 address needs based on existing networks. * * > 2. to apply the slow start mechanism only for 'IPv6 only' networks * > without existing IPv4 infrastructure * * > 3. to reduce the minimum allocation size for those IPv6 only networks * > (unless larger requirements are shown) * * > 4. to measure the utilisation rate with the HD ratio rather than * > percentages * * > 5. to make subsequent allocations when the HD ratio is reached * * > 3.1. Case 1 - Existing IPv4 services * * > Additional policies may require the return of IPv4 address space to * > the RIR or upstream ISP, in the case the existing network is * > renumbered to the new IPv6 space in future. * * Am I alone in wondering exactly what the scope of these additional policies * may be? My concern is based on the fact that although existing v4 networks * may well acquire v6 space, they are likely to need their v4 space for quite * some years to come, and hence it would be unrealistic to require the * return of all v4 address space. I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore. * * (Or maybe I misunderstand...) * * > 4. Size of Initial Allocation * * > For new networks without existing infrastructure, it is proposed to * > establish a minimum allocation for IPv6 address space. It is suggested * > to keep the size of the initial allocation relatively small (a /35 or * > smaller) and to determine the size of subsequent allocations based on * > the utilisation rate of the initial allocation (this is called slow * > start mechanism). This will allow easy access to IPv6 allocations for * > newcomers. At the same time possible wastage of address space and * > routing table growth will be limited. * * These v6 allocations are made from the RIR (ex TLA) space, correct? * yes. * So, are we abandoning the model where only the biggest networks go to * the RIRs for space, and everyone else goes to them? We learned that the old TLA/NLA/SLA boundaries were no technical requirements in the address format. In addition to that we know from experience that it is very difficult to define and verify what a transit ISP is. Therefore we propose to use a policy that treats all organisations equally. The RIRs cannot decide who is allowed to have a top level IPv6 allocation. The ISPs themselves have much better mechanisms to address routing table growth. Mirjam
On Tue, 25 Sep 2001, Mirjam Kuehne wrote:
I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore.
An ISP is quite likely to continue offering IPv4 services for many, many years to come even after launching an IPv6 service. Unless IPv4-only customers are getting renumbered as the ISP's IPv4 space is compacted to enable chunks to be handed back, this won't happen. And renumbering is of course problematic. The most natural course is to not have any precondition on handing back IPv4 space, but of course to allow it if the ISP chooses. There seems to be little need to make such declarations now? tim
Hi, I don't see anyone asking anyone else to hand back IPv4 space. What is said is that since, eventually, one day, the Internet will be IPv6, taking the current user base of an ISP as a clear needed head count for IPv6 addresses is something useful. In other words, an IPv4 ISP should get at least their current user base worth of /48s if they ask for IPv6 addresses. Hope this adds clarity Joao Damas RIPE NCC At 13:57 +0100 25/9/01, Tim Chown wrote:
On Tue, 25 Sep 2001, Mirjam Kuehne wrote:
I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore.
An ISP is quite likely to continue offering IPv4 services for many, many years to come even after launching an IPv6 service. Unless IPv4-only customers are getting renumbered as the ISP's IPv4 space is compacted to enable chunks to be handed back, this won't happen. And renumbering is of course problematic. The most natural course is to not have any precondition on handing back IPv4 space, but of course to allow it if the ISP chooses. There seems to be little need to make such declarations now?
tim
--
On Tue, Sep 25, 2001 at 12:49:46PM +0000, Mirjam Kuehne wrote: Hey Mir,
I agree with you that there will probably be a long transition period. The assumption however is that a network will at some stage be fully migrated to IPv6 and the IPv4 addresses will not be needed anymore.
Sure. No-one disputes this. I suspect that it was only the lack of a timeframe which had me worried. (But that is what community discussion will provide, hopefully...)
Therefore we propose to use a policy that treats all organisations equally. The RIRs cannot decide who is allowed to have a top level IPv6 allocation. The ISPs themselves have much better mechanisms to address routing table growth.
Ok. Sounds good to me! Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/
Dear LIRs,
snip
Kind Regards, Mirjam Kuehne RIPE NCC ----------------
snip
2. Overview
snip
This document does not attempt to provide details of policy
implementation,
procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here.
As stated above it says that this document does not attempt to document requirements for management of address space which is allocated. I feel that the community needs to understand how the RIR will manage the address space, for the following reasons. 1. If a initial allocation of /35 or smaller is allocated as described in section 4. Is it still the case that the /29 will be reserved? 2. If a IPv6 allocation is made say based on existing IPv4 services, and later the provider asks for a addition allocation because they have reached the threshold for their initial allocation. will the additional allocation be contiguous or not? What I'm basically saying is under the old policy if you where allocated a /35 you knew that the /29 was reserved for you so when you required additional address their would be from the say IPv6 prefix e.g 2001:618::/35 run out of address space and need more Ripe would change the allocation to 2001:618::/29 and no additional routes would be created in the DFZ. Under the new policy I do not understand how the RIR are going to manage the address space, and this document clearly states it does not document it. I know the above section does say that "These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here." So I might be jumping ahead here, but I think these issues also need discussing in addition to the new policy. So my question to the RIR's is do they have an idea of how they propose to managed the address space based on this new policy? I think the new policy is great in clearing up who can apply and what you can apply for. However if we don't know how the RIR's are going to manage the address space we won't understand how this policy will affect the DFZ, and for providers to understand what their next allocation is going to be? Best Regards, Stuart
participants (6)
-
Joao Luis Silva Damas -
Mirjam Kuehne -
Niall Richard Murphy -
Stephen Burley -
Stuart Prevost -
Tim Chown