This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6
- Previous message (by thread): [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6
- Next message (by thread): [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Tue Dec 6 00:32:44 CET 2005
Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2005 at 06:13:03PM +0100, Bonness, Olaf wrote: >>> "Every LIR gets a /32 (upon request), no questions asked" is a concept >>> that I'm also happy with - as I have said before. For those that are >>> afraid of the landrush: limit that policy to 5.000 LIRs per region. >> Not sure if that works. Kind of "First come - first serve" thing. > > Yes, so what shall we do instead? > > "Nobody gets addresses, no mistakes made"? 2000::/3 is only 1/8th of the total IPv6 address space, we can make mistakes 8 times :) But the problem then is that we will have 8 swamps of crappy managed address space which most likely nobody will return. For that matter, there is not much force to get folks to return address space but having the parties they want to talk with filter it out. I wonder what would happen if eg Google would ask (access) ISP's to start paying for traffic 'or else' :) > The whole point of this discussion is that there are two fractions: > > - one side is so afraid of doing the wrong thing that they want to > delay everything until the perfect solution is found > > - the other side wants to get things rolling, and is willing to risk > a few thousand entries in the global BGP table (whatever that is). > > and I don't think we'll ever reach consensus between those groups. Especially as there are no proper argumented proposals being made by the second group, except that the current one is not to their liking and that things that get proposed doesn't fit their bill. My view on all of this is the following (hinting group #2 :) : - reserve a global, thus all the RIR's in one slot and split that up under the RIR's, block for 'multihoming purposes' (3ffe::/16 seems very appropriate as it is already swamp) - give people who want to multihome a /48(*) out of this block. - let them pay an annual fee for it that makes it a real incentive to maintain it and use it. - let them sign a document that when proper multihoming (eg SHIM6) comes that they will start using that and after X time stop announcing their /48 more specific. Also let other people filter at wish. (Add lawyer style wording in the above ;) * = or other appropriate size, maybe per /40 is better so that each multihomer could have 256 sites behind them, though then they are at the 200-rule which they seem to be bothered with already... :) This gives them PI address space, when SHIM6 or a similar method gets realized the swamp gets cleaned. Of course the swamp will only be cleansed when everybody cooperates and I don't see that happening. One advantage of the "multihoming block" is that it will be very easy to filter out. Of course such multihoming blocks can have private peerings and people that don't filter them won't see them. But HEY isn't that exactly what is already happening now? Check GRH* to see how many /48's from separate ASN's can already be seen (~60 at the moment). I guess that 6bone space will be a perfect example on what happens with swamp space that is supposed to be returned. The big issue in the above is that many people will not like SHIM6 or other methods because it is not what they have now and they will claim that they don't have proper control over the route announcements of that block. I am then inclined to ask them how much control they have over their route announcements when it leaves their ASN... ;) Greets, Jeroen * = http://www.sixxs.net/tools/grh/lg/?show=endsite&find=::/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/address-policy-wg/attachments/20051206/1886081f/attachment.sig>
- Previous message (by thread): [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6
- Next message (by thread): [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]