On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote:
ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost.
Wrong. It's lost if your link to the aggregate provider is down at that time, or this network having BGP/IGP problems. The more-specific multihoming idea works only if noone filters, and then you lose the only advantage that scheme has: the ability to filter. Doesn't work, next try... ;)
Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat.
Not only then, but also for things like IRR and DNS reverse delegations. Again, only a half-solution.
Then again if RIPE disappears, what then? :)
Then we have other problems, as has each and every LIR.
WARNING: Also note that there are a number of places where there is quite some strict filtering happening. This might result that your small /48 gets filtered out by fast/good "transits", but accepted by slow/bad "transits", thus causing you to be pretty unreachable over those ASN's.
Luckily this situation is actually changing, and the good networks nowadays tend to ACCEPT /48s and the bad networks still try to keep some weird classful filtering concepts alive. Not the prefix length makes an announcement valid or not... the prefix length can only be some kind of heuristic for that. In IPv4 /24 is the common stop-gap for IBGP leaks, for IPv6 it should be /48.
This has already been seen a couple of times in IPv6 routing tables!
Yep, but times are a-a-changing. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0