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

[Brian E Carpenter <brian@hursley.ibm.com>]

RFC 3056 forbids announcing prefixes longer than 2002::/16, 
and instructs ISPs to filter them, to avoid polluting the 
IPv6 DFZ with IPv4 specifics.

   Brian

Jeroen Massar wrote:
> 
> Pekka Savola [mailto:pekkas@netcore.fi] wrote:
> 
> > On Fri, 22 Nov 2002, Brian E Carpenter 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?
> > >
> > > Wrong question. The question is, does *any* 2002::/16 announcement
> > > reach dead:beef's ISP? If yes, whichever relay is the origin of
> > > that announcement will relay the traffic. The 2nd question
> > is whether
> > > that particular relay is trusted by 0103:0405's 6to4 router.
> >
> > Exactly.  In Jeroen's model, I believe, the particular relay would
> > particully never be trusted.
> 
> That is exactly what I mean.
> 
> >
> > Any such model model is broken.
> 
> Eek :)
> 
> > 6to4 routers do not have any ways of knowing where traffic
> > will be coming
> > from, so discarding packets because they didn't come from your two
> > favourite relays is *wrong*.
> 
> Thats indeed true, fortunatly in the setup depicted below one
> knows where packets should be coming from.
> 
> > Propagating more specific routes etc. avoids this problem as
> > you have only one "home" relay.
> 
> Which where my thoughts exactly.
> Indeed the origin 6to4 relay's ISP will announce the prefixes it
> is willing to relay for, so the others can now where this relay
> is located and send all the return traffic directly there.
> That 6to4 relay can then send the traffic directly to the 6to4 node.
> 
> One thing is that "local" traffic will go over that same relay too
> even if it's in the same subnet. Maybe a check for "local subnet"
> could be devised to overcome this problem.
> 
> Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly
> connected
> and should send the 6to4 packets directly too each other.
> But when box-C has 192.168.1.2 this should go over the relay.
> Basically it comes down to:
> 
> 10.100.2.5/24
> [6to4 node A] <---+
>                   |        10.100.1.1
>                   +-----> [6to4 relay] <------> [IPv6 Internet]
> 10.100.2.6/24     |
> [6to4 node B] <---+
> 
> The relay announces 2002:0A64::/32 (10.100.0.0/16)
> - Any node on the internet knows how to reach it.
> - It only serves 10.100.0.0/16.
> - "6to4 Transit" goes over native (or configured tunnels) IPv6.
> - "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay
> trusts.
> - 6to4 Anycast route is only available inside the ISP, or the ISPs it
> trusts.
> - Local traffic (6to4 node A <-> 6to4 node B) travels locally only.
>   This should save some traffic on the relay though it is not 100%
> required.
> 
> Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are
> examples.
> 
> One could also see this approach as aggregating 6to4 traffic.
> Eg I imagine a 6to4 relay one hop more to the right of the above picture
> which carries for instance 10.0.0.0/8 which it announces to the
> internet.
> 
> Hope this clears it up a bit :)
> 
> Greets,
>  Jeroen