[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



You understand that the model you suggest will:
- not scale because it basically requires advertizing /32 in IPv4 BGP tables...
- will not enable an automatic deployment model a la Microsoft
where any host in the Internet can automatically be turned into a 6to4 router.

- Alain.


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