Interested in input on tunnels as an IPv6 transition technology

Mark Andrews marka at isc.org
Mon May 16 04:57:52 UTC 2011


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 at isc.org




More information about the NANOG mailing list