Lutz, On 2010-05-28 23:51, Lutz Donnerhacke wrote: > On Fri, May 28, 2010 at 10:29:17PM +1200, Brian E Carpenter wrote: >>> 6to4 prefixes more specific than 2002::/16 are allowed to be >>> propagated in native IPv6 routing, as long as the more specific >>> matchs exactly the mapped most aggregated IPv4 route originated by >>> the same AS. >> This is a really, really bad idea, for the reason given in RFC3056: >> >> 6to4 prefixes more specific than 2002::/16 must not be propagated >> in native IPv6 routing, to prevent pollution of the IPv6 routing >> table by elements of the IPv4 routing table. > > Did you notice, that this particual paragraph in RFC3056 is to be changed > by this draft? The whole draft is about why this change is necessary and how > can it be done.
And that is where I disagree profoundly. Encouraging longer 2002:: prefixes is absolutely the wrong thing to do for the reason stated in RFC3056. We don't want to see the IPv6 world filled up with junk from IPv4 (or to import v4 BGP filtering rules into v6 as a result). Also, the correct operation of 6to4 depends on universal visibility of 2002::/16, so that every native v6 host can send to every 6to4 router. Announcing specifics within that prefix is useless to native v6 hosts that need to send packets elsewhere, so you can't suppress the /16 even if you add more specifics. > In order to provide stable routing over their IPv4-only backbones > ISPs prefers to keep the 6to4 and Teredo traffic as long as possible > in the IPv6 network. I don't see why this has any relevance to v4 stability. Actually the best service to your users comes from doing the exact opposite: provide a local 6to4 relay which is the destination for 2002::/16, encapsulate in IPv4 as near the source as possible, and get rid of the v4 packets as soon as possible. > 6rd [I-D.ietf-softwire- > ipv6-6rd] with allows every ISP to assign it's own unicast prefix > similar to 2002::/16. This is a huge waste of address space. No it isn't. It's actually a trivial amount of space within any reasonable ISP v6 allocation. Also, the great advantage of 6rd is that it adds no BGP4 prefix. The right thing is to limit the scope of 2002::/16 announcements so that traffic sent to 6to4 destinations is encapsulated in IPv4 as near the source as possible. > > A proposed alternative is to hand out every ISP a separate /20-IPv6 block, > who want's to deploy more stable 6to4. So routing table size is clearly not > an issue: 6rd generate a lot of new long term routes while this draft > generates the same amount of (filterable) routes within a common prefix. You have clearly misunderstood 6rd. It doesn't generate a single new route in BGP. > >> That is a much more important issue than the fact that 6to4 doesn't work >> well for users whose ISPs haven't deployed a 6to4 relay (and >> announced 2002::/16 locally). > > Please do not joke this way. If the ISP announces 2002::/16 and does not run > the approbriate service for, there is something terribly wrong. The problem is when ISP A carries a route to 2002::/16 that they got from ISP B, but ISP B does not accept external traffic to their relay. In such a case both ISPs are wrong - B should not have announced in BGP, and A should have filtered the announcement. But as said above, you can't fix that by longer prefixes, because they break 6to4 anyway. Brian > >> ISPs do need to pay attention to filtering rules for 2002::/16 announcements. > > Of course. That's part of the draft. > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
