Gert, On Tue, Dec 06, 2005 at 09:56:04AM +0100, Gert Doering wrote:
The basic policy issue seems to me:
- who can get a (globally routeable [1]) IPv6 prefix
it might affect the policy "who can get an AS number".
It seems a really bad idea to connect this to AS number assignments. Currently, the policy for getting AS # assignments is quite clear (one has to multihome to get an AS #!) I don't believe it is smart to change IP number allocation policies in such a way that people are going to multihome (or lie that they are multihoming) so that they can get an AS # (that they don't need) and a PI address allocation. These things are two separate things and should stay separate.
The basic technical issue seems to be:
- is "IPv4-style" BGP multihoming the correct way to do in IPv6
No. The RIPE policies should not make any assumptions on what is "correct" or not. Operators run the Internet and they will decide how to do multihoming. It does not matter whether anybody thinks it is correct or not, it matters whether operators decide to honor your route announcement. Multihoming has in fact very little to do with this whole PI discussion. One can multihome with PI or PA space. However, the most important underlying reason for PI address space allocations is number independance of one's provider. In fact the so called PA blocks are exactly the same: how many ISPs who have a PA block want to be dependant on their transit providers IPs ? Basically, all blocks that a RIR gives out are PI. It is only the customers of the LIRs who get PA address space. I believe that it is much better to drop this whole discussion on PI. The discussion should focus on who can get an IP address space allocation from the RIR and how large. As somebody else mentioned, the Internet is a collection of connected networks and it does not matter whether one is a business, non-profit or ISP. As an example, I don't believe we can justify that a very large entity has (perceived) difficulties in obtaining ipv6 addresses while a tiny ISP that has plans for 200 customers but doesn't quite have that many customers yet and in total has less users than the large entity will get a /32 without any problem. Basically, we don't need additional policies, we need a modification of the current policy to make sure that users of address space of similar size will get and can get similar sized blocks of address space. David Kessens ---