+1 Do you really want to take the risk to import the full IPv4 routing table in IPv6 and multiply the memory size required in the RIB/FIB by 5? 6to4 is broken, the real fix is 6rd.
- Alain. On May 28, 2010, at 9:43 AM, Lee, Yiu wrote: > I agree with Brian. If a SP wants to provide a managed 6to4 service, 6rd is > the way to go. SPs shouldn't try to solve the broken 6to4 problem by > injecting v4 information to the global v6 routing table. > > Yiu > > On 5/28/10 6:29 AM, "Brian E Carpenter" <[email protected]> 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. >> >> 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). ISPs do need to pay attention to filtering rules for 2002::/16 >> announcements. >> >> Brian >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > <smime.p7s><ATT00001..txt> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
