Subject: 6to4 security questions

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 19:32:23 +0200 (EET)

Hello,

The most important part (how to go forward) got cut-off at the meeting, so 
I'm hoping to be able to hear some thoughts on the 6to4 security issues.

* The most important thing:
 ==> document the existing problems and declare done or try to invent
bigger fixes for the problems?

* Draft has two parts
 - relay spoofing troubles
 - 6to4 usage analysis, guidelines for sec considerations 
implementation etc.
 ==> keep these separate or not? (the second are IMO ready)

* Is the relay problem (spoofing from 2001::/16) something we need to 
worry about?
 - after all, you probably can spoof the source addresses without 6to4 
too..
 ==> if yes, how much effort should we put into it?

* Should we analyze the DoS attacks (abusing relays) whether anything can 
be done against those in more detail?
 - already in the draft, maybe more

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jason Goldschmidt <[email-masked]>
Date: Wed, 20 Nov 2002 09:55:35 -0800

Pekka Savola wrote:
Hi Pekka,

Thank you for the presentation today, it was too bad we didn't have more 
time to discuss it.

>bigger fixes for the problems?
Documenting the problems is the first step (which your draft mostly 
does) and I believe these should remain in their own draft.  The larger, 
relay router related, problems I do not believe can or should be solved 
by this draft.  This draft should present the security concerns, the 
possible attacks and any known ways to protect a 6to4 site.  I also 
believe there needs text that speaks to the usefulness of a 6to4 relay 
router.  It should be made clear that a site should just block all 
traffic to/from relay routers if that site does not have a compelling 
reason to connect to the (Native) IPv6 Internet.  6to4 works great for 
connecting isolated clouds, but we can all see how connecting to the 
IPv6 Internet using 6to4 relay routers is flawed and dangerous.

> ==> keep these separate or not? (the second are IMO ready)

Keep it in one draft.  Any "solutions" for the relay router problems 
should be brought up in another draft.

> ==> if yes, how much effort should we put into it?
This is a very serious problem which can make 6to4 hosts into pawns for 
a DDoS attack.  It needs mentioning, but we might just have to accept 
that it is very difficult to prevent for the average case.  Certainly 
6to4 relay routers as an entity are not evil, only the potential abuse. 
 With proper considerations and limited usage, relay routers can be used 
safely.  A few people during the meeting mentioned using IPSec or some 
sort of three way handshake.  These approaches will not work for the 
average case, but can work for specific deployments of 6to4.  

thanks,

-Jason

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Nov 2002 19:18:19 +0100 (CET)

> IPv6 Internet using 6to4 relay routers is flawed and dangerous.

I think that would result in a separate "6to4 Internet" and "IPv6-native
Internet" which can't (reliably) communicate which would be a very bad idea -
so bad that we should deprecate 6to4 IMHO.

Instead it makes sense trying to find sound operational practises that can
be applied while allowing nodes/sites using 6to4 to communicate with
nodes/sites that do not use 6to4 without severe security issues.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 20:21:59 +0200 (EET)

Thanks for the comments, a reply to a comment below.

On Wed, 20 Nov 2002, Jason Goldschmidt wrote:
> [...] I also 

I'm not so sure about that -- if you just want to connect isolated 
islands, usually you could also use configured tunneling.  Global 
connectivity is an important factor, but those that don't want it seem to 
be just a corner case.

There are two special cases that I can think of:
 - people using 6to4 addresses merely because of their automatic features, 
as a replacement for automatic tunneling/ISATAP (e.g. to connect v6 edge 
routers over v4 MPLS core).
  ==> personally I'm not sure this is really a valid usage scenario but 
rather a hack.

 - people using 6to4 merely to be able to "optimize" (assuming v4 
tunneling is better than v6 native, which is currently true) 6to4 
connections in addition to their native v6 connections.  Then a relay is 
not needed.  But blocking may still be a bit problematic as it depends on 
proper source/destination address selection everywhere (depending a bit on 
wheter 6to4 address are published e.g. in DNS)

What do others feel?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2002 19:53:42 +0100

Pekka,

My fundamental question since the 6to4 spoofing issue was first 
raised is whether this exposure to spoofing is a *significant*
addition to the generic exposure. If you were a spoofer, would
you really bother spoofing 6to4 rather than just plain spoofing? So
my feeling is that we really need more general work on anti-v6-spoofing, 
with this viewed as once case among many. 

I am reluctant to see us publish an RFC containing specific
heuristics for the 6to4 case until we have really looked at
spoofing in general.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 21:05:51 +0200 (EET)

> with this viewed as once case among many. 

That depends on how you expect the spoofing protection to be implemented.

If we assume that v6 deployments have learned since v4 deployments, and 
are now also using ingress filtering -- v6 spoofing could be more 
difficult than v4.

But then again, v6 spoofing could be equally easy (or even easier, due to 
"experimental" nature).

Note that even if both v4 and v6 ingress filtering is deployed, this
attack is still usable (it's unlikely that the encapsulating source v4
address will be logged, and even if it were, it's probably just some
compromised box sitting behind some poor fools DSL line).

---

From: Alain Durand <[email-masked]>
Date: Wed, 20 Nov 2002 11:05:43 -0800

>>nodes/sites that do not use 6to4 without severe security issues.
Give the current open, asymetrical, relay architecture of 6to4, this is 
not possible.

The core of the problem is that when decapsulating packets, 6to4 routers
have currently no way to know if packets are comming from a legitimate 
relay or not.
Any IPv4 host can impersonate a 6to4 relay and send a packet to a candid
6to4 host with IPv6 src the address of  an IPv6 victim.
The associated 6to4 router will decapsulate (no way to apply any check),
pass it to the candid host that will reply to the IPv6 src, that is, the 
victim.
Multiply this by thousands of candid hosts and you have a very nice
anonymized distributed denial of service attack on the IPv6 victim.
This is nothing new and was presented at London IETF.

There are in my opinion 4 ways forward:

1- Revisit 6to4 architecture to have bi-directional communication
    between the 6to4 router and the 6to4 relay. That way the decapsulating
    6to4 router could apply some checks and make sure packets are comming
    from a legitimate 6to4 relay.

2- Declare the problem  unsolvable and try to mitigate the effect,
    investigate iTrace solutions to enable tracing back the source of 
DDOS attack.

3- The main security concern is that the open relay architecture enables 
an attacker
    to defeat IPv4 ingress filtering (if in place) to do perform DDOS on 
a IPv6 host.
    There are already many other ways to create DDOS, so we should not 
worry to much.

4- Declare the problem unsolvable and serious. This means deprecating 6to4.

IMHO, 1) is a major undertaking, 2)  is scarry at least, 3) is 
irresponsible and
            4)  has tremendous consequences.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2002 20:09:48 +0100

Jason Goldschmidt wrote:
...
>  ...It should be made clear that a site should just block all

Er, you're missing the main reason 6to4 was invented, i.e. allowing 
isolated IPv6 sites to connect to the IPv6 Internet using relay routers. 

The use of 6to4 encapsulation to source bogus traffic was in fact 
discussed very briefly in the security section of RFC 3056, but without
proposing a way to identify valid relay routers. If, after studying
spoofing in general, we still need a specific solution to the 6to4
spoofing risk, it will need to be a secure way of identifying valid
relays.

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 21:12:42 +0200 (EET)

>     from a legitimate 6to4 relay.

I believe the "Limited Distribution of More Specific Routes" approach in
the draft could perhaps be able to solve these problems.

This would only be very minor modifications for the 6to4 routers/nodes, so
this might yet be doable.

There are some caveats though..

---

From: Alain Durand <[email-masked]>
Date: Wed, 20 Nov 2002 11:15:52 -0800

Brian E Carpenter wrote:

>you really bother spoofing 6to4 rather than just plain spoofing? 
>
IPv4 ingress filtering is an answer to IPv4 spoofing.
IPv6 ingress filtering is an answer to IPv6 spoofing

The 6to4 relay architecture enable an IPv4 attacker to bypass
IPv4 and IPv6 ingress filtering to bring down an IPv6 host.

    - Alain.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 20 Nov 2002 20:48:45 +0100

[I removed the To's and CC's as they are all on the list anyways ;) ]

>     6to4 router could apply some checks and make sure packetsare
comming
> an attacker to defeat IPv4 ingress filtering (if in place) to do 
> perform DDOS on a IPv6 host.
>     There are already many other ways to create DDOS, so we 
> should not worry to much.

Currently in europe, at least, there are only a few 6to4 relays:
 - Switch
 - Cybernet
 - Funet

More at http://www.kfu.com/~nsayer/6to4/ (which bans IE browsers)
Of the above Switch attracts the most traffic.

Limiting the 6to4 relay to a certain scope using the 6to4 anycast.
Allows one to at least limit ddos attacks also to that scope.
Which could be only a couple of neighboring AS's. This will also
solve the problem of the "I route via switzerland" problem even
though one is in The Netherlands for example.

Afaik FUNET only announces it's relay to a couple of AS's and this
seems to work quite well. Ofcourse to be completely certain of this
you should query them if they had any problems.

IPng (www.ipng.nl) had a 6to4 relay for some time but we closed it
due to the many abuses it came along with it. Requiring users to at
least sign up to the service does impose a small step but apparently
seeing the numbers of configured tunnels provided by the many tunnel
broker services it apparently isn't a very big limitation for most
people.

Personally I don't like 6to4 because the routing in the 6to4 world is
far from perfect, or acceptable for most people.
Configured tunnels are clearer, easier to troubleshout and to trace
abuse from/to. Good thing ofcourse is that it helps out people wanting 
to do IPv6 to transition very quickly. Even though I would recommend
those people to get a configured tunnel from their closed upstream and
transition to native IPv6 where possible ofcourse.

Greets,
 Jeroen

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 21 Nov 2002 04:57:59 +0900

at IIJ, we had a long internal discussion whether we should provide
	6to4 relay router or not.  we of course are serious about IPv6, would
	like it to be deployed real soon, but we decided not to provide it due
	to the very problems outlined in pekka's draft.
	(actually, i've pointed it out before him in
	draft-itojun-ipv6-transition-abuse-01)

>abuse from/to. Good thing ofcourse is that it helps out people wanting=20

	i 100% agree with the above opinion.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2002 20:59:22 +0100

> IPv4 and IPv6 ingress filtering to bring down an IPv6 host.

I'm aware of all that, but you're not answering my question.
Is the risk significant?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2002 21:01:21 +0100

> There are some caveats though..

Nevertheless I do prefer this approach, or to be more precise,
I'd like to be able to answer the question "should I trust
this relay router?" 

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 22:04:11 +0200 (EET)

> I'd like to be able to answer the question "should I trust

Yep.

Some relays would never be able part of this "more specific 
2002::/16 routes mesh": then you can pick the policy; either discard the 
packet (if coming from a relay not part of the mesh) or accept it (should 
be trusted).

---

From: Jason Goldschmidt <[email-masked]>
Date: Wed, 20 Nov 2002 13:02:10 -0800

>isolated IPv6 sites to connect to the IPv6 Internet using relay routers. 
Understood, but the sparse deployment of 6to4 relay routers suggests 
people are not using 6to4 to connect to the IPv6 Internet.  And if they 
are, it isn't anything really that important.

-Jason

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Nov 2002 21:08:54 +0000

> Currently in europe, at least, there are only a few 6to4 relays:

There are others (e.g. three I know of in the UK).  How public they are
is another issue.

Just to put 6to4 in perspective for its current deployment, I am not aware
of any European NRENs that are using 6to4 to connect sites to their national
IPv6 deployments.  Everything is done by manually configured tunnels.

That's not to say 6to4 doesn't have a place (our students use it for access
from their home networks, and it will work behind a NAT with tunnel forwarding)
but it is perhaps more likely to be in large customer networks?

To play devil's advocate, who is using 6to4 in a notable deployment?

Tim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Nov 2002 22:16:12 +0100

A general remark: the reflexion DoS attack was extensively discussed
in the mobile-ip WG mailing list for the Home Agent Option which has
a similar problem...

[email-masked]

PS: Pekka, I supposed you have followed the discussion (or at least
you know where are the archives). IMHO a summary of proposed solutions
(with pros & cons in the 6to4 context) should be a nice thing.

PPS: I have another concern about 6to4: the business model for running
6to4 relays seems to be flawed (for example there are a very small number
of available 6to4 relays today and *no* ISP guy I asked why he didn't run
one gave an answer different than a loud no). I am afraid that if 6to4
is deployed we'll get two distinct IPv6 Internets: the 6to4 one and
the native one...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2002 22:32:46 +0100

> are, it isn't anything really that important.

Let's be clear why 6to4 was invented. It was intended to be a disruptive
technology for the case where a relatively sophisticated site's ISP
was unwilling to provide IPv6 service, and no upstream tunnel provider
was available. But I wouldn't expect to see widespread deployment until
there is widespread demand for IPv6 access, by which time we need to have
fixed the spoofing risk.

    Brian

---

From: Jason Goldschmidt <[email-masked]>
Date: Wed, 20 Nov 2002 13:33:02 -0800

>To play devil's advocate, who is using 6to4 in a notable deployment?
At Sun we are using 6to4, as an early transition mechanism, for our 
deployment.  For the past few years we have had a few (read 3) 
engineering sites connected by configured tunnels.  We found deployment 
scalability problems with this approach, so we decided to go with 6to4. 
 Why?  In these tough economic times, were it is near impossible to 
convince cost constrained IT departments to upgrade their core routers, 
6to4 becomes the poor man's solution.  We are in the process of creating 
10-15 6to4 sites which will consist of engineering and labs groups. 
 Unlike configured tunnels, new 6to4 sites can be added at will, instead 
of having to dig a new configured tunnel for each site.  When Alain and 
I explained how configured tunnels might work, the IT folks turned green 
remembering deploying multicast.  :)

At Sun we have the, possibly not so unique, situation of not "owning" 
parts of our network.  A few years back, Sun outsourced mostly all of 
its network.  There is an interface for upgrading routers and such, but 
this brings up back to the cost problem.  Also, our IT department 
requires that emerging technologies go through a Trial phase (described 
below) and thus are unwilling to simply "turn-on" native IPv6 routing.

Our plan for deployment has four phases.  Proof-of-concept - Trial - 
Pilot - Full Deployment.  The Proof-of-concept phase is complete, IPv6, 
using configured tunnels and local IPv6 routing, has been running for 
the last few years.  The Trial phase is starting now, it will start with 
6to4 and transition to using native IPv6 routing after the harder issues 
of DNS, applications and management tools are figured out (and thus we 
get more "buy-in").  The Pilot phase will appear much like the Trial 
phase, but with two key distinctions, it will be on a larger scale and 
owned by the IT department (not owned by a joint effort of engineering 
and an advanced development group from IT).  Full Deployment is the 
true, ubiquitous, deployment of IPv6 on our enterprise and edge networks.

-Jason

---

From: Laurent Dumont <[email-masked]>
Date: Wed, 20 Nov 2002 13:40:20 -0800

We're planning to offer 6to4 as an auto configured fallback for getting home
Mac users on IPv6. This of course if we don't get a RA and only in the case
we're the Mac is not behind a NAT... But that's another issue.

Laurent

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 20 Nov 2002 22:39:07 +0100

> with this viewed as once case among many.

I agree with Brian, however - how keen an attacker is to spoof 
something is ofcourse depending on what he can DoS or connect to.

Best regards,

- kurtis -

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Nov 2002 22:42:37 +0100

In your previous mail you wrote:

   I think that would result in a separate "6to4 Internet" and "IPv6-native
   Internet" which can't (reliably) communicate which would be a very
   bad idea - so bad that we should deprecate 6to4 IMHO.

=> I agree but even we solve the security issue IMHO we have to know
why ISPs don't want to run 6to4 relays, i.e., perhaps there is also
an operational issue to solve.
 I believe they are many ISP persons reading this list. Can you explain
why there is such a low number of available 6to4 relays today?

Thanks

PS (for David Kessens): this can be an item to add to the agenda
at the next RIPE meeting.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 23:57:28 +0200 (EET)

> why there is such a low number of available 6to4 relays today?

How do you know?  Perhaps they do have them, but aren't advertising them
to the internet -- certainly, they probably don't see it as their business
to provide relay service for *others*.  (However, when I've been roaming,
not too often though, I've never stumbled on a non-public relay)

P.S. We do advertise both 192.88.99.0/24 and 2002::/16 everywhere.  And
receive quite a bit of traffic, even afar.  Actually I have a few
gigabytes of logged data I've analyzed once or twice to see who is using
the service.  Not many of them were from our network.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 00:00:07 +0200 (EET)

> To play devil's advocate, who is using 6to4 in a notable deployment?

To me, it is clear that 6to4 is probably never the best solution except in
most SOHO/Home network solutions, or in testing (easy to get started, as 
there is no need to negotiate a tunnel).

But that is what it was designed for, I think.

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Nov 2002 22:08:38 +0000

> not too often though, I've never stumbled on a non-public relay)

Indeed.  There's one running like this on the UK academic network, but
noone's using 6to4.   The largest NREN deployment is probably in DFN
(Germany) with over 200 academic and commercial customers, all now
migrated to DFN's SubTLA I think, and all manual tunnels.
 
Tim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Nov 2002 23:16:10 +0100

=> the risk was considered enough significant for the home address
option in mobile IPv6 to kill triangular routing, i.e., to drop
packets with a HAO which can not be verified (no IPsec SA or
binding cache entry).
If you consider it is no significant, I'll ask to reopen the HAO
discussion in mobile IPv6.

Regards

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 20 Nov 2002 23:19:47 +0100

Laurent Dumont wrote:

> Mac users on IPv6. This of course if we don't get a RA and 
> only in the case we're the Mac is not behind a NAT... But that's
another issue.

I think that making that a default option will lead into _many_ helpdesk
phonecalls.
The actual upstream ISP will get phonecalls like:
 "www.example.org doesn't work"

Even though the upstream (ISP) can reach it quite well over IPv4.
Ofcourse one will have IPv6 -> IPv4 fallback. But the latency for
falling
back will be quite big. Also note that, unless 6to4 relays suddenly pop
out
of nowhere, the traffic of these users will go through a couple of
different
countries without the user probably wanting it.

It would be a good thing to do to 'force' upstreams to get IPv6 in their
networks.
But I really don't think it will scale and it will deliver a load of
headaches.
If you added this option as an option in the network settings with a big
help doc
alongside with it describing the problems which could arise this would
be great.
"Go to network config and hit that 'enable 6to4' button to enable it" or
something
similar. A warning on a non-responded RA could also be a good idea but
one has
to remember that most users will blindly click "Yes" on most forms they
don't understand.

People really wanting IPv6 will get it from their upstream or a
transitional method
and they can pick out of a lot: 6to4, configured using a tunnelbroker or
their upstream.
Note also that current tunnelbroker systems have quite intuitive
websites and for example
freenet6 delivers an automatic configuration tool.
At least then they will be begging their upstream to get it supported :)

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Nov 2002 22:24:31 +0000

> But that is what it was designed for, I think.

If you look at home user connectivity now, the most common method used is
a tunnel broker, witness 10K+(?) users of freenet6.  A TB can serve /48's
as well as just connecting hosts.  I doubt there's 10K users of 6to4?

I think people can probably handle having a "TB connect" icon on their
desktops if needed.  I know of many young gamers who were very adept at
keeping DirectX versions up to date to play Windows games not so long ago,
which is no more tricky.

The TB main weakness is tunnel topology - it doesn't optimise like 6to4.
I really don't want to use freenet6 from the UK, for example.  I also 
worry about scalability, but the TB web server can farm out tunnels
to a farm of TB servers (is this what freenet6 does?).   But a nice 
advantage is that you can use TSP and authentication.  

I take the point about 6to4 deployment in Sun.  It's certainly easier than
a mesh of tunnels in that respect (depending on the topology you want),
but you still need the same ISP support (ip tunnels allowed).

Tim

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 20 Nov 2002 14:25:28 -0800

> To play devil's advocate, who is using 6to4 in a notable deployment?

Define a notable deployment. Windows XP comes with IPv6 support. It 
isn't on by default, but with a few commands, IPv6 is on and 6to4 is 
up. Mac OS X 10.2 (a.k.a. Jaguar) ships with IPv6 on and listening for 
routing advertisements. With a command, 6to4 is on and the node has an 
IPv6 address.

These releases require people to manually enable 6to4. It won't be long 
before such technologies are enabled by default. Will the 6to4 relays 
melt down? Perhaps. Will there be any incentive for people to deploy 
6to4 relays or even maintain them if the traffic does pick up? At the 
very least, it will be a sign that there is demand for IPv6 
connectivity.

Is it reasonable to rely on ISPs supplying IPv6 to their customers? I 
don't imagine I'll live to see the day that SBC hands out IPv6 
addresses to DSL customers, and I'm only 25.

I see only one compelling reason to use IPv6 instead of IPv4, and 
that's end to end connectivity (no NATs). The problem is, developers 
are not going to deploy an IPv6 application if there are no clients 
that have IPv6 addresses. Until there are applications that support 
IPv6 and don't work over IPv4, there will be no demand for IPv6.

6to4 is a bootstrap technology that lets you get IPv6 out to a lot of 
people, people that have no hope of getting IPv6 addresses from 
shortsighted ISPs. With transition technologies like 6to4, developers 
can count on IPv6 and writing their applications. If the applications 
succeed and people are using IPv6, the demand may convince the ISPs to 
deploy IPv6.

Unfortunately, 6to4 will not work for everyone out there, especially 
those behind a NAT. Vendors of NAT boxes are not implementing 6to4, 
they don't see any demand. The shipworm/teredo draft is an interesting 
proposal for getting IPv6 connectivity to nodes behind a NAT. 
Unfortunately, the IETF seems to be totally uninterested.

If the transition to IPv6 relies on ISPs making a multi-billion dollar 
gamble that deploying IPv6 without any customer demand will pay off, 
IPv6 will never be widely deployed. Tunnel brokers don't scale, unless 
they charge. If they charge, only corporations and the few individuals 
that care enough will have IPv6 connectivity.

-josh

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Nov 2002 23:28:00 +0100

=> this is the solution for the home address option similar issue
(the option is checked against the binding cache, i.e., is validated
only when two-way communication is used).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 00:41:55 +0200 (EET)

> only when two-way communication is used).

The amount of harm one can do is similar, but the model seems otherwise a
bit different.

Mobile nodes _were able to_ (speaking about the old spec where unverified
HAO was still ok) communicate without HAO's.  Your regular honest 6to4
node can't as it's its only address; they have no care-of addresses for
bootstrapping, regular/no-frills operation, etc.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 00:51:09 +0200 (EET)

> as well as just connecting hosts.  I doubt there's 10K users of 6to4?

Really that many?  I wonder how many of them are actually being used?

To me, 6to4 seems far better mechanism to deploy v6 for organizations that 
_usually_ need tunnel broker (easy access, tunnel end-point far away).

Controlled tunnel brokering seems of course the better choice.  But it 
appears to me that that's _not_ what most of those tunnel sites are..
 
> but you still need the same ISP support (ip tunnels allowed).

That's wrong way to deploy 6to4, as it breaks the assumption about global 
reachability.

Instead, if configuring tunnels between the sites (the N^2 problem) is a 
real problem, Sun should use native addresses for infrastructure, and 6to4 
just for the "point-to-point links" betweent the sites  (think of BGP 
tunneling except replace BGP with 6to4).

---

From: Laurent Dumont <[email-masked]>
Date: Wed, 20 Nov 2002 14:56:15 -0800

> "www.example.org doesn't work"

That raises another issue which was briefly stated this morning in one of
the presentation about getaddrinfo and the address selection process.

Does it make sense at this point for a web browser sitting on a dual stack
implementation to try the AAAA address first, maybe wait 75 seconds to
timeout because the DNS the v6 host is declared in DNS but not reachable
along the path and then try the A record over v4? I don't think that's
really a good user experience, but I haven't seen anything that could
prevent this to happen right now.

> At least then they will be begging their upstream to get it supported :)

Maybe that's a way to get ISPs to move on and provide direct IPv6 support,
for us the clear identified reason to use IPv6 vs IPv4 is a restored peer to
peer connectivity, even if it has to go through something like 6to4. I think
everybody agrees that the best way would be native IPv6 support by the ISPs,
but I don't see the incentive for them to move until apps are deployed.

--Laurent

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 21 Nov 2002 00:10:01 +0100

> >> Currently in europe, at least, there are only a few 6to4 relays:

<SNIP>

> IPv6 and don't work over IPv4, there will be no demand for IPv6.

Microsoft will be releasing many tools, which currently use IPv4, with
IPv6 support.
At least that's what their program manager said :)

Application vs Network is ofcourse a very big chicken and egg problem
and one has to push it from both sides. Many freesoftware programmers
fortunatly realise this and are doing the right thing(tm).

One 'killer' program will certainly be a videoconferencing tool.
Say Netmeeting but then IPv6 capable. Another one will ofcourse be
a Peer to Peer application where people can transfer their files.

I am currently seeing a move to IPv6 support on news servers which is
a good thing as it is a huge amount of data every day. Xs4all even have
their big (2Tb or something) news server open for the public.
(news://newszilla6.xs4all.nl).

> If the transition to IPv6 relies on ISPs making a 
> multi-billion dollar gamble that deploying IPv6 without any customer
demand will pay off, 
> IPv6 will never be widely deployed. Tunnel brokers don't 
> scale, unless they charge. If they charge, only corporations and the
few 
> individuals that care enough will have IPv6 connectivity.

IMHO Tunnel brokers _will_ and can scale well of correctly built
ofcourse.
Both freenet6 (www.freenet6.net) and XS26 (www.xs26.net) have many
(10K+)
users who apparently are quite content with it.

<spam>
I personally can vouch for the system called SixXS built by Pim van Pelt
and myself which is an evolvement of the IPng (www.ipng.nl)
tunnelbroker.
See
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-i
pv6-ipng
for the presentation given at RIPE42 in short: The SixXS (www.sixxs.net)
system is a whitelabeled tunnelbroker, giving ISP's the opportunity to
setup a private (for ISP own use) or public POP managed by a console,
webinterface or using a custom interface which can very easily be
attached to the current system.

Currently this system is in use by 5 ISP's who have their own POP:
.nl: AMS-IX, Concepts, IPng
.de: Cybernet AG
.ie: HEAnet

The AMS-IX POP is currently providing tunnels to ISP's connected to
the AMS-IX to help them bootstrap into the IPv6 world, most of them
have requested an sTLA from RIPE since we launced it at the
AIAD (AMS-IX IPv6 Awareness Day) held last month.

An ISP thus can setup tunneling to clients very easily providing IPv6
where native IPv6 isn't possible yet. Check the website for more
information.
And ofcourse don't hesitate to contact [email-masked] ;)
</spam> 

Greets,
 Jeroen

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 20 Nov 2002 17:02:52 -0800

> (news://newszilla6.xs4all.nl).

So if something works over IPv4 and IPv6, and I've already got IPv4, 
why would I worry about getting IPv6 connectivity?

A game developer certainly has a compelling reason to use IPv6. Instead 
of supporting a massive server with a huge pipe, the developer could 
use a small server that allows gamers to find each other. All of the 
traffic could be sent directly between the peers with IPv6. A game 
developer can not deploy an application that relies on IPv6 because it 
isn't widely deployed. They could develop a protocol for communicating 
over IPv4 if IPv6 isn't present, but then IPv4 nodes couldn't play with 
IPv6 nodes. As a game developer, I would write only the IPv4 code. 
There is no incentive to develop an IPv6 only application.

This is a chicken and egg problem. That is why transition tools are 
important. Apple could develop and ship a system that implemented 6to4 
and shipworm/teredo to fall back on when IPv6 wasn't immediately 
available. Apple could also ship an application that made use of IPv6. 
Microsoft is in a similar position. Once that's done, third party 
developers can take advantage of that, assuming all of the transition 
mechanisms work. Shooting down 6to4 eliminates one transition 
mechanism. Not even acknowledging Teredo is another shot at transition.

Pointing us at configured tunnels as a solution to deploying IPv6 to 
our customers is not a reasonable solution. If Apple and Microsoft ship 
their next releases configured to automatically use one of the free 
tunnel brokers, overnight that service will be barraged with millions 
of requests and probably become unusable. The only reason those 
services are available for free and work is because the vast majority 
of people don't know about them or don't care.

> users who apparently are quite content with it.

Will it scale to millions? Who's going to pay for all that bandwidth? 
These solutions are only used by enthusiast. As long as that's the 
case, they will continue to work. These solutions will not work for a 
wide deployment of IPv6. Without a wide deployment, no applications, 
and no demand for IPv6. No solution to the chicken and egg problem.

-josh

P.S. I'd like to apologize to SBC, I know there are some smart people 
there that are interested in IPv6, I just don't think the company's 
management is likely to approve spending money on deploying IPv6.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Nov 2002 02:18:56 +0100

How do you know?

=> traceroute 192.88.99.x and traceroute6 2002:x:y:z:...

   Perhaps they do have them, but aren't advertising them
   to the internet

=> they don't advertise them to me so they are not available to me.
Something amazing is I got the same relay for 192.88.99.1 from here
(Atlanta) and from my office in France...

   P.S. We do advertise both 192.88.99.0/24 and 2002::/16 everywhere.

=> obviously they don't reach or Atlanta or Brittany...

Regards

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 03:41:25 +0200 (EET)

> => traceroute 192.88.99.x and traceroute6 2002:x:y:z:...

That's only one part of the answer: public relays, or relays in the 
network you're visiting.  There could be hundreds of relays out there.

The only way to measure that would be to run some logging on a 6to4 router 
-- check which addresses packets tunneled to come from 2001/3ffe come from 
(and take out the spoofs). 

> => obviously they don't reach or Atlanta or Brittany...

You're sitting in a wrong network :-).  Try e.g. from somewhere Abilene.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Nov 2002 02:53:58 +0100

=> I don't buy this argument: 6to4 is not the only transition technology.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 16:23:45 +0200 (EET)

> => I don't buy this argument: 6to4 is not the only transition technology.

Yes, it isn't -- but when 6to4 is used, there are no other, concurrently 
used transition technologies.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2002 15:58:54 +0100

As I keep having to remind people, 6to4 wasn't designed as
a mass market end-host solution, so if you use it for that
and have problems, well, I'm not too surprised.

  Brian

---

From: Laurent Dumont <[email-masked]>
Date: Thu, 21 Nov 2002 08:13:57 -0800

Brian, 

I know it's not the best solution, but it's the best tool we currently have
to give our end nodes sitting at home on a DSL or cable modem an IPv6
address. I'd much rather have the ISPs advertise or delegate a prefix, but
realistically it won't happen because they have no incentive to make it
happen. 

In order to boot strap the process and get a wide application deployment, we
need some user perceived advantage for IPv6, and peer to peer maybe the way.
To get peer to peer to work easily, IPv6 is a good tool, but to get an IPv6
address, 6to4/Teredo seem like the only possible route at this point for a
home Mac user.

I'm not sure that the relay model will collapse if many 6to4 users are using
it, because the reality is that a 6to4 node will most likely be talking to
another 6to4 peer and will really not go through any relay for most of its
traffic. Why? because there is nothing of interest for them on the 6bone, so
that won't change much to the current situation...

The alternative, the way I see it, is just to ignore IPv6 for now and wait
for providers to wake up one day and magically start giving out IPv6
prefixes. Is that what we want?

--Laurent

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 21 Nov 2002 17:19:28 +0100

> and have problems, well, I'm not too surprised.

Which is exactly what I wanted to point out to Laurent though
I did it probably with the wrong wordings ;)

I think that 6to4 could work if the upstream ISP delivered the relay.
Eg.. the client-machine tries to RA, if unsuccesfull it tries the
upstreams 6to4 using the anycast address.
The big assumption here is the fact that all upstreams need to either:
- have a 6to4 announced to their clients using the anycast address.
- block the route to the 6to4 anycast.
If neither of these two points are met one will fall back into the
scaling problems and will see people using IPv6 over a completely
different country. I don't see this as a viable solution though :(

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2002 16:07:47 +0100

> only when two-way communication is used).

Actually, what is wrong with the model in bullet 2.2 of section 5.2
of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4
router and the 6to4 relay routers it deals with? (OK, I can see some
reachability issues but 6to4 is not supposed to be the universal answer.)

As I said a moment ago, 6to4 wasn't designed for end hosts. I've
always felt the BGP4+ scenario was the best one. 

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 20:09:06 +0200 (EET)

> reachability issues but 6to4 is not supposed to be the universal answer.)

That, in itself, helps little.  Relay routers must also be connected using 
BGP4+ and advertising more specific routes.
 
> always felt the BGP4+ scenario was the best one. 

Well, the reasons 6to4 is used are usualy either/and:
 1) ease of taking into use
 2) takes dynamic v4 address into account

For SOHO/home use, both conditions are usually fulfilled.  Also, for 
bigger enterprise networks, which are usually able to run BGP etc., are 
only concerned about _at most_ 1).

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 21 Nov 2002 20:07:15 +0100

Laurent Dumont [mailto:[email-masked]] wrote:

This is more turning into a "How to push IPv6" thread ;)

> Brian, 
> 
> I know it's not the best solution, but it's the best tool we 
> currently have to give our end nodes sitting at home on a DSL or cable
modem an IPv6
> address. I'd much rather have the ISPs advertise or delegate 
> a prefix, but realistically it won't happen because they have no
incentive 
> to make it happen. 
> 
> In order to boot strap the process and get a wide application 
> deployment, we need some user perceived advantage for IPv6, and peer
to peer 
> maybe the way. To get peer to peer to work easily, IPv6 is a good
tool, but 
> to get an IPv6 address, 6to4/Teredo seem like the only possible route
at 
> this point for a home Mac user.

IMHO most users wanting too use IPv6 _now_ will sign up directly with a
tunnelbroker.
One will see that signing up using a webinterface is really not that
hard.
eg: MSN/ICQ/Yahoo/<fill in [instant messenger/kazaa/peer-to-peer]
service>/,
Most users will work it out quite easily if they know what they want.
Unfortunatly there are not many applications that currently support
IPv6.
And as you and I and some others already said it's a chicken and egg
problem ;)
Using tools such as provided by freenet6 gives quite a tremendous ease
of use.

One thing to note is that many commonly-used programs that don't really
depend on IPv6 features like security etc are not ported yet either.
Even though porting those applications is quite easy, one simply needs
to
run through Itojun's excelent doc
(http://www.kame.net/newsletter/19980604/)
And those applications (webbrowsers, email clients, mailservers) will be
IPv4 and IPv6 capable. At least this will give webhosters the
incentitive
to start providing an IPv6 google/altavista/* and more.

> I'm not sure that the relay model will collapse if many 6to4 
> users are using it, because the reality is that a 6to4 node will most
likely 
> be talking to another 6to4 peer and will really not go through any
relay 
> for most of its traffic. Why? because there is nothing of interest for
them 
> on the 6bone, so that won't change much to the current situation...

One should not look at the 6bone, end-user deployment is not
experimental
nor a test. These should happen in RIR space.

> The alternative, the way I see it, is just to ignore IPv6 for 
> now and wait for providers to wake up one day and magically start
giving out IPv6
> prefixes. Is that what we want?

No ofcourse not :)
Thats why we held the AMS-IX IPv6 Awareness Day to kick a little life
into those
ISP's, checking the assignment list* one will see that Luna, Cistron,
Trueserver,
Interned, TooFast, Demon and Hubris all got an allocation because of
that event.
Hubris even got it working on the same day!
RIPE/ARIN/APNIC could pro-actively "spam" their LIR's and push them into
the
right direction or by organizing IPv6 days like this. Notez bien that
the current
stats for allocations (see * also) is:

RIPE  : 132
ARIN  :  39
APNIC :  90

Now what really should happen is that the US wakes up :)
Where is a company like RoadRunner or many of the other very large US
ISP's?
Even _if_ there was an ability for people to use 6to4 relays
automatically
why should they use it if there isn't any content to connect too?
And with content I mean simple things which can be easily dual-stacked
like:
HTTP, SMTP, POP3/IMAP, NNTP, eg the basic services one uses.

* = http://www.ripe.net/ipv6/ipv6allocs.html

Btw:
$ host -t aaaa www.apple.com
www.apple.com           CNAME   www.apple.com.akadns.net
www.apple.com.akadns.net AAAA record currently not present
$ host -t aaaa www.ipv6.apple.com
www.ipv6.apple.com has no AAAA record (Authoritative answer)

You could give all those users a 6to4 by default, but then they can't
even
use the, imho, magnificent trailers part of the apple website over IPv6
;(

Greets,
 Jeroen

PS: before anyone speaks up, indeed unfix.org is v4 only too :(

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 11:17:03 -0800

>that won't change much to the current situation...
Either you leave the relay model or you remove it.
If you leave it as it is, you open serious security issues
If you remove relays from the architecture, you create
a partition of the Internet. Sure, today there is no content
reachable though native IPv6, but one day, there will.
That day, you do not want to prevent those gazilliions
6to4 users from reaching it.

The only wat forward is either to deprecate 6to4 alltogether
(and use another conncetivity for the masses approach until
IPv6 ISPs are generally available)
or to fix the security problem.

My take is go back to the white board and try to fix it.

    - Alain.

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 21 Nov 2002 20:49:40 +0100

[email-masked] [mailto:[email-masked]] wrote:

<SNIP>
> 6to4 users from reaching it.

6to4 is a good transition method that works, but as you say below
it needs some reworking so the abuse possibilities are limited
as far as possible.

> My take is go back to the white board and try to fix it.

Some of my thoughts about this:

* Limit 6to4 to 1 ISP.

This way an ISP could setup a 6to4 service for their clients
and provide it to the parts of their networks which are not
capable of native IPv6 at that moment.

I would implement that 'limit' by using carefull source address
filtering.
A ISP should know from which ranges clients could come which are not
capable of native IPv6.

For example the following network structure:

 IX-a --- brd -          6to4 relay       --- customer access
               \             |           /
 IX-b --- brd --- ISP core backbone --- * --- customer access
               /                         \
 IX-c --- brd -                           --- customer access
 { ISP }

Thus the 6to4 relay is just another router in the network of the ISP
Source address verification should be enabled on all incoming
connections
anyways if they are sane people and want to protect themselves against
DoS's.
Because of that the ISP can know that any traffic coming out of that
prefix
and which is on their network is from a client and that it is a valid
prefix.
Ofcourse a client could spoof inside the ranges on which the borders get
filtered.
But that is a local problem which can be found out.
As the 6to4 relay is inside the ISP's network it will only be reachable
for their
own clients.

This has the following advantages:
 - Spoofing is kept to the ISP level.
 - 

And ofcourse the disadvantages:
 - Every ISP needs to setup a 6to4 router or ask another ISP access to
theirs.

This setup could easily make use of the anycast address.
One should then restrict the announcement of this anycast address to the
ISP
or to the ISP's one trust to filter correctly on incoming connections.

Having no route to the 6to4 relay from the outside will makes this work
quite easily too :)

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.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 22:04:55 +0200 (EET)

please think that to the end, it will not want without re-specification 
_globally_.  We don't want to restrict 6to4 to ISPs' walled gardens.

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 21 Nov 2002 21:54:59 +0100

Pekka Savola wrote:
> Sent: Thursday, 21 November, 2002 21:05
> To: Jeroen Massar
> Cc: [email-masked]; [email-masked]
> Subject: RE: 6to4 deployement issues - was 6to4 security questions
> 
> 
> please think that to the end, it will not want 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 ;)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 23:03:22 +0200 (EET)

On Thu, 21 Nov 2002, Jeroen Massar wrote:
> > please think that to the end, it will not work without 

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.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 00:01:27 +0100

=> this is a heavy solution (6to4 is supposed to be automatic and
not require BGP4+ skills) which secures only one way.
The security issue is a rogue 6to4 relay which uses 6to4 boxes behind
6to4 routers to reflect traffic to poor IPv6 nodes. I am afraid
this is the other way (as Alain said, the problem is in the asymmetrical
routing between 6to4 and native IPv6 Internets).

=> of course, bullet 2.2 of section 5.2 is an option of a scenario...

Regards

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2002 23:04:04 +0100

Jeroen,

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.

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.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2002 23:03:13 +0100

> BGP4+ and advertising more specific routes.

No, the model is that they will advertise 2002::/16, but only inside a limited set
of AS's. That is mentioned in RFC 3056 - you use BGP policy to scope
which relay serves which part of the native IPv6 network. 

That in itself doesn't protect against spoofing however; for that you need
peering between the 6to4 router and a set of trustworthy relays.

> only concerned about _at most_ 1).

The third reason is 
  3) no IPv6 ISP offering configured tunnels near enough in the topology.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 01:25:13 +0200 (EET)

> which relay serves which part of the native IPv6 network. 

A very and heavy and unreliable (the unpredictable return routing) model.  
I don't believe there are any of these deployed.
 
> That in itself doesn't protect against spoofing however; 

Indeed.

> for that you need

You're creating a separate, rather small 6to4 internets using this model, 
unless the relay routers will relay more specific routes between them.

I can't regard that as an acceptable deployment scenario: this seems like 
creating semi-global addresses, and isolate yourself from the rest.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 00:47:47 +0100

> 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.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 00:51:54 +0100

Francis Dupont wrote:
> not require BGP4+ skills) 

This author of 6to4 *never* said that.

> which secures only one way.

Indeed. You need BGP peering on both sides of the relay.

> 6to4 routers to reflect traffic to poor IPv6 nodes. 

Exactly. So the 6to4 routers should only accept packets from
BGP peers. It may be heavyweight, but it is not mysterious.

   Brian

> I am afraid

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 01:55:05 +0200 (EET)

> 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.

Any such model model is broken.

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*.

Propagating more specific routes etc. avoids this problem as you have only 
one "home" relay.

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 22 Nov 2002 00:56:49 +0100

[Also answering Brian's comment below ]

> 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:

> 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.

> advertisement of 2002::/16 using normal BGP policy mechanisms.

Which is what I meant also :)

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 01:21:44 +0100

> creating semi-global addresses, and isolate yourself from the rest.

There are some balkanization  risks in the RFC 3056 BGP-based model.

There are spoofing/DDOS risks in the host-based anycast 6to4 model
that has been implemented but never fully specified.

Take your pick.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 02:34:13 +0200 (EET)

> that has been implemented but never fully specified.

Do not classify this as "host-based".  There is nothing particularly
host-based in this.

And you said you're not aware of anything in the spec that'd need 
modification. Right..

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 22 Nov 2002 01:35:21 +0100

> particully never be trusted.

That is exactly what I mean.

> Any such model model is broken.

Eek :)

> 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

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 17:10:45 -0800

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:

>>>>>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
>>    
>>
>>>>How will you send traffic from 2001:dead:beef::1 to 
>>>>        
>>>>
>>2002:0103:0405::1, if
>>    
>>
>>>that announcement will relay the traffic. The 2nd question 
>>>      
>>>
>>is whether
>>    
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 02:18:00 +0100

> Do not classify this as "host-based".  There is nothing particularly

Yes there is, because hosts don't generally support BGP4+

> And you said you're not aware of anything in the spec that'd need

My original preference was to *only* specify the BGP4+ model
for 6to4. I was talked out of it. 

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 03:22:27 +0200 (EET)

> Yes there is, because hosts don't generally support BGP4+

Wrong analogy.  Very small amount of routers use BGP4+, and even fewer 
(none?) use it in the 6to4 context.

> for 6to4. I was talked out of it. 

That would have been an *entirely* different 6to4. 

One that would have gone the way to the 6over4, most probably.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 02:22:23 +0100

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 03:28:07 +0200 (EET)

> IPv6 DFZ with IPv4 specifics.

Yes.

.. which is why I proposed a model where 6to4 relays are interconnected
using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone
would be happy :-).

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 22 Nov 2002 02:44:55 +0100

> - not scale because it basically requires advertizing /32 in IPv4 BGP 

For what do you want to advertise a /32 ?
The anycast address is local, so that doesn't cause any problems and is
already being deployed, except for the fact that they serve globally.

One will have to 'replicate' all IPv4 routes into the IPv6 routing
table,
which is as I mentioned in the other mails one of the disadvantages.

Fortunatly I expect, though ofcourse that has to be seen and time would
tell, that not many ISP's will setup a 6to4 router, especially if it
goes on like current events.

Note also that links that have native capability won't have to be
announced.

But this is indeed a serious disadvantage.

>    where any host in the Internet can automatically be turned into a 

No, it will as long as the upstream ISP works along, if they don't
one indeed can't use it. One could see this is an adminstrative policy
where an ISP doens't allow certain traffic etc. Unfortunatly this blocks
the spreading and use of IPv6 by using 6to4, but abuse-solutions usually
inhibits use of good technologies.

ISP's who really want to do IPv6 will need to have a upstream IPv6
connection.
Otherwise the 6to4 traffic would travel over several third party
networks anyways.
And seeing the current deployment of 6to4 relays that doesn't seem very
good.

I personally don't see another way to solve the problem at hand, being
the abuse.
This trick does have a couple of advantages but ofcourse those come
along with
disadvantages.

I also think that people who really want to use IPv6 can have the
incentive to
sign up at the various tunnelbrokering systems.
6to4 in this way though would be really nice for what Joshua described,
just plug it
in, no RA response, then try and reach a 6to4 router. At least when it's
'hosted' by
the ISP itself (or a neighbouring one) it will quite close.

Tunnelbrokering systems can ofcourse also be deployed this way. Freenet6
for example
can do it all automatically with their so called 'anonymous' tunnels and
a handy
tool which the user installs.

If anyone has a good idea yell it out, ofcourse this is just one of my
mind rumblings.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 17:45:58 -0800

>using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone
How does this help a 6to4 router to check if the packet is coming from
a legitimate 6to4 relay?

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 03:50:42 +0200 (EET)

> How does this help a 6to4 router to check if the packet is coming from

Read the draft.

Under this assumption, (most) packets from native internet are only 
tunneled from your home relay -- some IP address you've configured, some 
security association you've done etc.

This assumes enough relays take part in this more-specifics mesh, and
outright discarding packets could not be done in the startup phase.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 02:51:55 +0100

=> I know but many 6to4 supporters said exactly that.

   
=> I'd like to know how?

   
=> how you can archieve this:
  - a random native IPv6 source with a packet for a 6to4 node knows
   the 6to4 relay associated to the 6to4 destination. The obvious
   way to do this is to inject a part of the IPv4 routing into
   the 2002:: prefix, i.e., something we must not do.
  - same but between 6to4 relays (i.e., the pollution is constraint
   to the 6to4 relay set). It should work but it will become very
   hard to find ISPs which accept to run a 6to4 relay.
IMHO this relay problem makes 6to4 usable only to transit (?)
an IPv4 internet to IPv6 (all IPv6 islands will be 6to4, no need for relays)
(cf a comment from a Sun guy doing exactly this for the internal Sun internet)

Regards

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 18:28:48 -0800 (PST)

Alain,
   
> How does this help a 6to4 router to check if the packet is coming from

Tim Gleeson and I were just talking about the 6to4 open relay issue.
If router A sends traffic out thru relay B but gets return traffic
back thru relay C we have the open relay situation. Since everything
is just IPv6 over IPv4 as a link layer, can we possibly leverage
neighbor discovery to set up some sort of security association
along the forward and reverse paths?

I've been working on a scheme that can provide path mtu discovery based
on a "three way handshake" using neighbor discovery, and I've wondered
if/how a security association could be added to the negotiation.

Any thoughts on this?

Fred Templin
[email-masked] 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 03:41:22 +0100

Any thoughts on this?
   
=> have a look on opportunistic encryption?
(draft-richardson-ipsec-opportunistic-10.txt)

PS: there was a demo of a running implemetation of OE some days ago.

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 19:16:51 -0800 (PST)

Francis,

Thanks for this - I've pulled the draft. I'm wondering if it will be
light-weight enough for what I have in mind, however.

Fred Templin

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Nov 2002 18:35:32 +0100 (CET)

>     from a legitimate 6to4 relay.

But doesn't such a revisit result in the prefix needing to be
associated with the tunnel endpoint in order for routing to scale
i.e. this becomes just a variant of the tunnel broker?
(Not that this would necessarily be bad, I think the tunnel broker
is a much overlooked piece of work.)

But if #1 and #4 are essentially the same choice we only have 3 real
choices.

  Erik

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Nov 2002 14:35:44 -0800

> is a much overlooked piece of work.)
I take this as a compliment! :-)

>But if #1 and #4 are essentially the same choice we only have 3 real
Yes. The question is now to understand if we can live with this threat 
or not,
or in other words, does full automatic connection to IPv6 networks
from anywhere in IPv4 land outweight the security threat of what
is the logical equivalent of open relays.

Same question applies for NAT traversial solutions like Teredo.

The alternative is deploying virtual ISPs through tunnel brokers that 
also accept
IPv6 over UDP (or TCP, or PPP) over IPv4, at the cost of giving up
full automation and creating sub optimal topologies.

I think this is a fundamental question for the 'unmanaged environment'.

    - Alain.