| | | | | | | | |
|
|
|
You're here: Home |
On 2007-01-17 02:20, Jeroen Massar wrote:
Uchenna N Ibekwe wrote:
...
As for 6to4, that is a huge problem. Mostly because there are only a limited amount of anycast relays. One will thus be thrown at the mercy of those anycasts to function. Also debugging a 6to4 problem is unfeasible because of anycast and a lot of misconceptions on how to properly configure a 6to4 setup.- Routing tables as a result will be kept within a manageable size.No, the IPv6 routing table will include the IPv6 routing table.
Actually that was one of the main concerns when we designed 6to4 -
that if badly deployed, it would import the whole IPv4 swamp
(a.k.a. PI space) into the IPv6 routing table. That's why RFC 3056
explicitly forbids it:
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. Therefore, a 6to4 site which
also has a native IPv6 connection MUST NOT advertise its 2002::/48
routing prefix on that connection, and all native IPv6 network
operators MUST filter out and discard any 2002:: routing prefix
advertisements longer than /16.
Brian