RE: 6to4 deployement issues - was 6to4 security questions

["Jeroen Massar" <jeroen@unfix.org>]

[Also answering Brian's comment below ]

Pekka Savola [mailto:pekkas@netcore.fi] wrote:

> On Thu, 21 Nov 2002, Jeroen Massar wrote:
> > > please think that to the end, it will not work without 
> > > re-specification _globally_. 
> > > We don't want to restrict 6to4 to ISPs' walled gardens.
> > 
> > One ISP can have a trust relation with another ISP and announce
> > the anycast prefix only to that other ISP so it can make 
> use of it too.
> > Source address verification should then ofcourse be extended by the
> > other ISP's. This could be seen as a 'transit' type 
> service, but then
> > between the v4 and v6 world ;)
> 
> How will you send traffic from 2001:dead:beef::1 to 
> 2002:0103:0405::1, if 
> 2001:dead:beef::/48 is not within the trust boundary?
> 
> If the answer if "no, you can't", this seems close to my "limited 
> distribution of more specific routes" solution, except being more 
> restrictive for deployment.

That's indeed something one doesn't want as it doesn't help a bit
indeed.
Cut&Paste from the big mail:

> One will have to announce all the 2002:<IP>:<v4>:: prefixes one has
and
> is serving too into the IPv6 routing cloud to make this work and make
> the paths shorter.

Ofcourse most of the bigger ISP's can fortunatly aggregate most of their
prefixes.
Probably a big disadvantage would be that sites employing this idea will
have
the same number of prefixes currently being announced into the IPv4
world also being
announced to the 6to4 (2002::/16) counterpart.

Mind you that many ISP's won't setup a 6to4 relays and hopefully will be
using
neighboring ISP's relays, maybe with a bit more aggregateble space.
People not having a 6to4 relay can ofcourse take '6to4 transit' from
other ISP's
though '6to4 transit' should go over native connections wherever
possible ofcourse.

Biggest advantage of announcing these multiple prefixes is also that the
IPv4 path
over which the 6to4 tunnel goes stays short. Reaching a IPv6 site thus
would mostly
take the same route as the IPv4 path which latency and stability-wise is
a good thing.

Brian wrote:
> The RFC 3056 model is to limit the visibility of a relay by BGP
> policy - that allows it to be wider (or narrower) than one ISP;
> As I said to Pekka Savola, you do that by scoping the
> advertisement of 2002::/16 using normal BGP policy mechanisms.

Which is what I meant also :)

> But that isn't the spoofing solution; for that you need a peer
> relationship of some kind between the 6to4 "customer" router
> and the set of trustworthy relays.

See the comment above about '6to4 transit' which, I think, could
solve this problem.

It will indeed create 6to4 islands hanging onto the RIR/6bone space as
leaf sites but that isn't much of a problem as it gives connectivity.
It should never be used for transit.

Greets,
 Jeroen