Hiya all, Here are some thoughts on IPv6 allocation policy. Hopefully the resulting discussion will be active and constructive, resulting in appropriate feedback, policy, IETF-drafts, RFCs, etc. If the text below gets corrupted then you should be able to view it at: http://www.djp.net/ipv6/proposal.html This concerns the LIR and IPv6 WG at RIPE and I4ve sent to both lists accordingly. I suggest all replies/discussion be carried out primarily on the IPv6 list. Cheers Dave Viag Interkom GmbH ----------------------------- Proposals on IPv6 Allocation policy Hierarchy versus Address Conservation The RIR allocation policies for IPv6 appear to be based on the assumption that IPv6 addresses are a scarce resource that are about to run out. This assumption is totally untrue. Instead RIR allocation policies need to be focussed 90% on aggregation and hierarchy, and optimising the global routing table. One of the worst mistakes an RIR can make is to allocate too few addresses to an LIR, resulting in later subsequent allocations and pollution of the global routing table. Classbased versus Convenience: What is appropriate for an "alpine village" ISP is not appropriate for a large global ISP. LIR should not therefore all receive the same "standard prefix" but receive sensible allocations based on reasonable long term expectations on use. We should aim so that only 10% or so of LIR need to come back to ask for a second allocation within 5 years. Dividing on strange bit boundaries (eg. /35) in combination with the format of writing IPv6 addresses makes notation and calculation very hard for most people and will result in many mistakes over time. In such a large address space the benefits of always making allocations on a 4 bit boundary are greater than the resulting inflexibility. This is seen in the original TLA /16 and NLA /24 proposals. Allocations should be at /16, /24 or /32 - possibly /20 /28. Sub allocations by LIR to their customer ISPs should similarly be /32 /40, or possibly /36 /44. Present Allocation sizes: Bit usage density should be allocated evenly over the addressing hierarchy. I could use rfc1715's h-ratio here but refuse to use a measurement unit where everything is squashed between 0 and 0.301. At present a "site" has 80 bits (fixed at /48). Of these the average usage is likely to be 10 to 100 nodes (ranging from 10k for a medium corporation to 1-5 for the far more predominant home user). The usage density is therefore approx: 2^80/100 or well over 1 in 10^20 !!! can be certain there will not be more than around 100,000 top level routes. Accordingly the usage density is 2^35/100,000 or approx 1 in 350,000. An LIR with a present /35 and only a single customer (/48) has already reached a density of 1 in 8192 !!! Does anyone know why the service provider is treated differently ? The need for hierarchy within an LIR: In practise an LIR must introduce hierarchy to prevent excessive routes. Global LIRs must do this at multiple levels. Typically a Global LIR might have about 10 regions and about 10 areas per region - although hopefully these would not all be fixed in size. This hierarchy must be set at the outset, although a fraction (say up to 2/3) could be reserved to provide additional resources to areas/regions that grow faster than originally expected. In each of these approx. 100 areas, the larger LIRs (national or global) will have predominantly X customers who are small and/or medium size ISP's. The smallest of these would typically expect to have enough addresses to serve 256 customers - /40. Accordingly a minimum allocation for such an LIR forseeable at the outset is at least a /24. Minimal initial allocation based on registered IPv4 usage We must not allocate too few addresses to an LIR since this will cause problems for us all, and especially him and his customers now and in the future. Since addresses are not in short supply, and one of the worst mistakes an RIR can make is to allocate too few addresses, a minimum first allocation could be based on the customers current REGISTERED IPv4 usage. In fitting with the above sections a possible simple yet flexible approach would be to adopt the following table: Small - /40 Medium - /32 Large/National - /24 International - /16 These categories also fit extremely well with the present RIPE membership categories which could help reduce administrative checking of claims to be Large/National, etc. Until Multihoming issues are sorted (see also below) we must adopt a similar approach to corporate LIRs. With the category used calculated as if they were not a corporate LIR. A side effect of this rule is that it will encourage owners of historical non-registered allocations to register them with one of the RIRs (if they want an appropriate IPv6 allocation). These are minimum initial allocations. Larger initial allocations can be requested if appropriately justified. For example a new 3G UMTS consortium operating in a major european country but which has no LIR background would typically qualify for the same prefix as a large/national LIR Usage requirements for additional allocations: IPv4 addresses are in short supply, appropriately there is therefore a rule stating that 80% of addresses at each level must be "used" before additional addresses are "provided". In IPv6 this rule is not only invalid, it just does not make sense. Even more crazily, RFC2450 states 90% !!! In order to prevent stupid wastage and bad network design, this rule should not be relaxed below about 10% (I am reminded of a network I came across using RFC1916 addresses where a /16 was assigned to each of 100 sites - which varied from 5 to 10,000 nodes). In contrast 80% or 90% is unnecessary and unreachable in IPv6 where addresses are not a scarce resource. Multihoming and allocations to non-service providers: At the time of writing no fully satisfactory multihoming technique is available. We must therefore provide current owners of globably routed IPv4 address space with a TLA with an appropriate mask. Failure to do this will actively discourage organisations considering a move to IPv6. We must be pragmatic, and at the same time encourage IPv6 use.