In message <03a401cc1197$0ceec410$26cc4c30$@net>, "Tony Hain" writes:
6rd designed as a derivative of 6to4 to explicitly remove the /16 = restriction in IPv6 BGP advertisements because changing that one line = would have taken longer to get agreement on than an entirely new design, = implementation, and deployment sequence (note that this will result in = just as many IPv6 prefix announcements into BGP as fragmenting 2002:: = would have, so the arguments about modifying 3056 are moot). Requires = that each provider have a large enough allocation to embed the uniquely = identifying parts of their IPv4 space into each 6rd address block, which = is a challenge with existing IPv6 allocation policies. It does align the = tunnel endpoints with the access infrastructure that is being overlaid, = at least at the organizational level. Does require CPE capable of = sorting out which set of IPv4 address bits should be concatenated with = the IPv6 pop prefix to create the ultimate IPv6 prefix for that CPE.=20
6rd doesn't have to add any extra routes to the global routing table. As for adding more specific routes to 2002::/16, a operator would need a route for each IPv4 cidr netblock they offer 6to4 on to avoid the use of 3rd party relays. That being said ther routes should only be there between the time the operator brings up the 6to4 relays as a initial transition service and the time they deploy IPv6 natively. After that they would most probably still run reverse path relay covering all of 2002::/16. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org