Subject: An alternative to 6to4 and teredo

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jan 2003 20:32:28 +0100 (CET)

A long time ago Joshua wrote:

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

I argue that using tunnel broker and extending it to support UDP tunneling
across NATs is much better than 6to4 and Teredo when considering the space
of temporary solutions until the ISPs provide native IPv6.

I think tunnel brokered tunnels provide better incentives for deployment
than 6to4 relays because they are visible to the user - the provider
can throw in some content and adds as part of the web page you visit,
and the can claim "we have x,000 users". A 6to4 relay provider can not
do this. The "connect to IPv6" icon on the desktop also helps drive
IPv6 awareness - folks will see that enabling that allows them to run
their IPv6 peer to peer games even across an IPv4 NAT box, thus they
are more likely to ask their ISP for native IPv6 than if this is
completely automatic as is envisioned for Teredo.

The only downside of the tunnel broker schemes is potentially less efficient
routing. But if the services are popular this might be a self-correcting
problem. And if they are not popular it is either because there is sufficient
native IPv6 access or that IPv6 is not being widely used.

The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP
over  TCP over NATs for those so inclined) in addition to the incentives above
is that it avoids the security issues around 6to4 and Teredo, and is
operationally much much simpler to trouble-shoot.
And there isn't any risk of creating separate IPv6 native and 6to4
universes since it is all IPv6 native addresses with regular IPv6 routing.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Jan 2003 19:26:47 +0200 (EET)

> of temporary solutions until the ISPs provide native IPv6.

I agree, to some extent.  Definitely so for Teredo (complexity).
 
> native IPv6 access or that IPv6 is not being widely used.

That's not all.  6to4/Teredo offer an automatic configuration using 
anycast addresses.  Much easier than trying to figure out the closest 
tunnel broker, configuring to use that etc.
 
> operationally much much simpler to trouble-shoot.

I agree, but there is a cost to a tunnel broker model, that is, not so 
simple configuration..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jan 2003 20:44:52 +0100

I've never argued against tunnel brokers for isolated hosts. Please 
remember that 6to4 was actually designed for whole sites with no 
IPv6 ISP, not for isolated hosts. The fact that a well-known operating 
system ships 6to4 for isolated hosts doesn't change the original design 
point.

    Brian

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 17 Jan 2003 21:04:08 +0100

> On Thu, 16 Jan 2003, Erik Nordmark wrote:

<LONG SNIP>

> I agree, but there is a cost to a tunnel broker model, that 
> is, not so simple configuration..

There is at least Tunnel Setup Protocol (TSP*) which does automatic
configuration and it'salso quite extendable. On debian for instance
it's "apt-get install freenet6" and you are going. The only 'problem'
is that the Freenet6 broker system is located in the US thus european
hosts have some (80ms+) additional latency. A "POP" per ISP would be
better which is something we are pursuing for SixXS. The TSP protocol
can handle this fortunatly. A POP per ISP would at least mean that
clients can get near-native IPv6.

TSP: http://www.freenet6.net/draft-tsp.shtml
It is marked "Expires: November 30, 2001" though, what happened
that it didn't get pushed through?

Good example is xs4all who first had a IPng.nl based tunnelbroker
and modified it for their needs with which they are now providing
IPv6 to their clients who can't get it natively. The IPv6-in-IPv4
thus only is carried in their network untill their tunnelbox,
for xdsl clients this is thus max 3 hops and a latency of about
only <~3ms added when they would have native connectivity.
See the "Deployment at XS4all" presentation to be found at:
http://www.ams-ix.net/aiad/presentations.html for more info.

My point is that ISP's should be pushed to have something like
that or that at least they should deploy a 'close' relay, may
this be 6to4 or a tunnelbased system. As long as their clients
can connect as 'locally' as possible.

I've partially developped an alternative to this scheme with some
big differences to what Freenet6 does with their TSP protocol.
Some other things are in line first though. But it will be a
system I want to have deployed at least before march for the
SixXS system which we fortunatly abstracted with an API so that
things like these can be implemented quite easily.
Small example is port 42006 on our noc.sixxs.net box which
basically replaces the website and can be easily accessed by
any program capable of sending data over a tcp/ip socket.

As I also probably wrote before, people do also sign up for
things like MSN and hotmail etc, so an IPv6 tunnel via a
webinterface shouldn't be that hard either.
The only thing is making them think that having it is useful!
(Which is one part I have on the 'other things to do first' :)

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Sat, 18 Jan 2003 00:34:07 +0200 (EET)

> that it didn't get pushed through?

Folks probably lost hope.
 
> http://www.ams-ix.net/aiad/presentations.html for more info.
[...]
> any program capable of sending data over a tcp/ip socket.

Above you show one of the main points here: there are dozens of
tunnelbrokers, and each have their own interface (pretty much).  It's just
too much work that way.

(btw, I think tunnel brokering would get off a bit if a client+server code
using some agreed protocol would happen to be publicized under a liberal
license like BSD.)
 
> (Which is one part I have on the 'other things to do first' :)

Hotmail etc. have been around for ages.  Tunnel brokers come and go.  The 
configuration may require some installation in your computer.  Sure, many 
folks still do it, but there's a big difference.

But of course, some kind of "tunnel broker discovery" or catalogues could
be coined up too...

[moved this from above]
> can connect as 'locally' as possible.

This is not all.

We provide 6to4 relay service to everybody in the world.  There is no way
we would offer any tunnel brokering (_using our addresses_) outside our
customers.  6to4 is much more provider-neutral on this aspect, which could 
also be considered as a good thing!

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 21:01:47 -0500

On Fri, 17 Jan 2003 20:44:52 +0100

> system ships 6to4 for isolated hosts doesn't change the original design 

for that matter, 6to4 works great for isolated hosts that need to talk to
other hosts running 6to4. tunnel broker is *much* less efficient.

OTOH, I think tunnel broker is a good way to provide default route for a 6to4
site.

Keith

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 18 Jan 2003 13:42:41 +0100

> Folks probably lost hope.

I rather think it never got completely finished seeing that
Appendix A mentions "A DTD should be placed here for the protocol."
etc...
I added Marc to the CC list he can probably best comment on
what happened and/or what is going on.

> Hotmail etc. have been around for ages.  Tunnel brokers come 
> and go.  The configuration may require some installation in your
computer. 
>  Sure, many folks still do it, but there's a big difference.
>
> But of course, some kind of "tunnel broker discovery" or 
> catalogues could be coined up too...

I had quite a big list of tunnelbrokers in the dmoz.org directory
but apparently some of the big mofo's there found that the IPv6
index wasn't good enough and changed it around. Fortunatly google
mirrors it to their directory.google.com* and thus it still exists,
it isn't on dmoz any more so it's unmaintained unfortunatly.

* =
http://directory.google.com/Top/Computers/Internet/Protocols/IP/IPng/IPv
6_Access_Providers/?il=1

Checking the top 10 I see some very stable TB's. And I think that
the google ranking also is quite a good indication of the use of
the TB's. HE + Freenet6 are quite large, though I never heared
of any numbers from them. For SixXS/IPng (IPng is using the SixXS code)
the listing is at http://www.sixxs.net/misc/statistics/ , this is
Pim and my project so I won't go bragging around with it I do have
to say that all the tunnels noted there (500+) are actively used.
We then also got quite a strict policy for who gets a tunnel and
who gets to keep it for at least the public POP's. Each one of
them can have their own policies as they are mostly ISP bound and
thus those users are (paying) customers of that ISP if they do
something that ISP will deal with it.

Having a central server serve a list of available tunnelbrokers
is actually the idea I am taking up for the SixXS project and
mind you is also the thing that Freenet6 is doing already succesfully
for quite some time now.

> We provide 6to4 relay service to everybody in the world.  
> There is no way we would offer any tunnel brokering (_using our
addresses_) 
> outside our customers.  6to4 is much more provider-neutral on this 
> aspect, which could also be considered as a good thing!

Ah indeed the neutral political problem. This is indeed something
to look at unfortunatly. In SixXS we solved this with the fact
that a POP has a list of policies and based upon those a user can
choose that POP or not or force him to use only that POP.
Eg. the HeaNet POP simply only allows tunnels to prefixes which
are directly peered with HeaNet, thus most of Ireland.

I know also that many ISP's let non-customers use 6bone space and
keep the RIR space for their paying customers. In their respect
RIR space is 'better' IPv6 space then 6bone space and they can
justify this to their paying clients as "they are testing if
it's going to work for you".

As said we hope to finish up the automatic configuration programs asap.
The programs, code and protocol will become public at release.
The reason why we are not using TSP is because it misses quite a couple
of things which we require for the operation of our style of system.
For example automatic dynamic tunnels are not supported easily without
traffic being sent to an unsuspecting dailup user with ZoneAlarm running
You really don't want to know what kind of odd abuse messages alongside
of the threats you get then ;)

Greets,
 Jeroen

---

From: Francis Dupont <[email-masked]>
Date: Sun, 19 Jan 2003 16:39:49 +0100

In your previous mail you wrote:

=> congratulations on a such courageous public opinion...
BTW teredo comes from an old discussion about what to standardize
for UDP tunneling across NATs (tunnel server ports for instance).

=> this is my main concern about 6to4.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 19 Jan 2003 16:43:53 +0100

=> many ISPs are very reluctant to run a 6to4 relay so I am not
convinced of the provider-neutral aspect of 6to4... I have no objection
to be a TB-provider customer BTW.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 18:54:06 +0100 (CET)

> tunnel broker, configuring to use that etc.

If somebody wants to provide a good tunnel broker service they can
automate this without any changes in the clients. Just have multiple tunnel
servers at different places in the topology and have the tunnel broker
meaure or estimate the location of the client before handing it
off to a tunnel server.

Thus if example.net wants to capture IPv6 "customers" that they don't
have as IPv4 customers they could do this relatively easily.

> I agree, but there is a cost to a tunnel broker model, that is, not so 

Yes, but see above. A single icon on the desktop might be sufficient.
And it has the advantage of lower operational complexity resulting in
a higher probability that it actually works. And should it not work the icon
allows you turn turn it off.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Jan 2003 20:19:46 +0200 (EET)

On Sun, 19 Jan 2003, Erik Nordmark wrote:
> automate this without any changes in the clients. 

.. assuming that the protocol TB uses is specified and implemented widely
enough.  Being able to ship it by default in OS's helps.

> Just have multiple tunnel

.. possibly even requiring specification or at least publication of this 
measument mechanism.

Note: I believe you also need a way to get the list of "tunnel brokers
close to me" -- manually adding them doesn't seem like an option.
 
> have as IPv4 customers they could do this relatively easily.

Assuming above.
 
> allows you turn turn it off.

Well.. I don't think you can get it much easier than 'echo IPV6TO4INIT=yes
>> /etc/sysconfig/network-scripts/ifcfg-eth0' or the like; that's all you
need to enable 6to4 using the anycast address on certain operating
systems.  No software needed, no nothing: IPv6 in 5 seconds.

Of course "actually works" is relative.

Perhaps, to focus, we should ask ourselves: do we want to provide a
mechanism that provides easy use for the case where:
 1) Joe User wants to use his closest Tunnel Broker that allows him to use
the service (not knowing where this closest TB even is!), or
 2) Joe User digs out the tunnel broker address/hostname of his ISP or 
someone close by and starts to use the service

From my observation point, 6to4 is ultimately superior at 1), at least in
locations where you have some deployment of 6to4 relays (here in Finland,
there are at least two advertising 192.88.99.0/24 and 2002::/16).

Note that to be practical, 1) seems to require that there is some
mechanism of autodiscovering tunnel broker services.  Surfing the web is a
no-go.

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 19 Jan 2003 19:26:57 +0100

> have as IPv4 customers they could do this relatively easily.

Which is exactly what we (SixXS) do, we actually let the user pick a
'preferred' POP, then measure their latency from the POPs to the
selected
IP and then we select onto which POP they go.

This, the signup process, will be done completely automatically
soon(tm).

Mind you that TSP servers can already do it, wether they really
do so I don't know though. Multiple TB's are implemented in their
system though.

> a higher probability that it actually works. And should it 
> not work the icon allows you turn turn it off.

If all is well the client should get a notification of the server
controlling
this system that:
 - it could not connect to the server.
 - it is not allowed to serv.
 - packets can't apparently reach the endpoint.
   (If you can't ping6 the remote endpoint the 6in4 path is broken)

etc.. so this could also all be done automatically.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 19 Jan 2003 20:46:32 +0100

Pekka Savola wrote:

<SNIP>

> Well.. I don't think you can get it much easier than 'echo 
> IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0' or the
like; 
> that's all you need to enable 6to4 using the anycast address on
certain operating
> Of course "actually works" is relative.

Pinging the endpoint of the tunnel and/or the relay should show that
it's up enough. if the tb/relay isn't setup correctly there isn't
much one can do about it anyways.

> From my observation point, 6to4 is ultimately superior at 1), 
> at least in locations where you have some deployment of 6to4 relays
(here 
> in Finland, there are at least two advertising 192.88.99.0/24 and
2002::/16).

Well one should not limit "Tunnel Brokers" to systems using 6in4 (IPv6
in IPv4)
IMHO there should/can/could be a mechanism that works somewhat like:

C: Connect to central service
S: I've X tunnelbrokers for you
S: The best is number 10
C: Request 10
S: type = 6to4
S: ipv4_pop = 10.1.1.1

or:
S: type = 6in4
S: ipv4_pop = 10.1.1.1
S: ipv6_pop = fec0::1
S: ipv6_client = fec0::1
S: prefixlen = 64
S: subnet = fec0:1000:1::/48

Or something similar. Note that one can take a good look at TSP for
this.

> mechanism of autodiscovering tunnel broker services.  Surfing 
> the web is a no-go.

Depends on the fact if there is a central face for the thing.
Indeed googling around for such a setup is a no-go.

Btw: on debian: apt-get install freenet6 and you are off.
Apparently there are also Win32, *BSD and other clients.

Maybe we should purssue a similiar or derived protocol like TSP?
Note that there is 1 problem here: Central Point-Of-Failure if
the central server providing the TB lists goes down/overloaded etc.
In that case 6to4 is quite good, if one can reach the anycast address
then one can have 6to4 too in most cases. As for the 'highlatency'
one should restrict their 6to4 relay too peers so that people in
austrialia simply don't see any 6to4 relay at all at the moment.
IMHO none is better as the switch.ch relay with massive overhead.

In any case if we want to see global low-latency tunnelbroker setups
there have to be deployments of those TB's/relays close to the user.

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 22:42:20 +0100 (CET)

> system ships 6to4 for isolated hosts doesn't change the original design 

My point is that tunnel brokers (plus prefix delegation?) might make 
sense beyond isolated hosts as well. For instance, it might make sense for
a home router.

The configuration isn't the elusive "zero", but it can be simple enough to
be used.

I wonder if there is any data on the fraction of the existing tunnel
broker clients serve more than one host. (It does at the office in France.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 22:52:20 +0100 (CET)

> OTOH, I think tunnel broker is a good way to provide default route for a 6to4

That would make the site be multi-addressed with a 6to4 prefix
plus a prefix that was assigned by the tunnel broker.

That raises questions of what source address filtering might be appropriate
at the tunnel server - should they accept any source address?
That would seem counter to the arguments about 6to4 relays introducing
new ways to spoof source addresses - the tunnel server would
in essence to the same.

Unless there was a way to register an alternate source address prefix
with the tunnel broker as part of configuring the tunnel broker ...

  Erik

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 20 Jan 2003 02:50:59 +0100

> broker clients serve more than one host. (It does at the 

I can answer that very positively as seen from the SixXS perspective.
Most of the users get a tunnel and are quite sharp at getting their
subnet
delegation the week later when they get enough credits for doing so.
After that one will usually see 5+ different hosts coming from the
delegated
prefix. With 'hosts' I mean IP addresses who are surfing websites.
The 'biggest' use for subnets unfortunatly is to have a cool/vanity
hostnames on IRC though. We also tend to block out most of those users.
And as we are known for doing that most of those users stay away from
our tunnelbroker setup leaving over the more serious users and those
where exactly who we want to serve.

Personally I am quite glad with my subnet, as know all my 'internal'
hosts can simply be reached from the public internet. Usually the
places I visit and where I need IPv6 connectivity I try and convince
the local admin in getting IPv6 and usually this ends up into setting
them up with a IPv6 tunnel. Which is probably one of the advantages
of having your 'own' tunnelbroker. Then again 1/3th of my
home<->internet
consist of IPv6 which IMHO is quite a lot. It would be a lot more
if somebody convinced services like google to do IPv6 though.

Most people I know/hear talking about it have the same feeling like me
on the ground that it's quite handy to have all your hosts globally
reachable.

If you want real stats I could once setup a ntop like tool which counts
traffic per destination/source port on the IPv6 level. Then one could
really see for what IPv6 is being used. Unfortunatly I don't know of
any IPv6 aware traffic analyzers which are capable of doing this.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 20 Jan 2003 03:02:00 +0100

> with the tunnel broker as part of configuring the tunnel broker ...

I tend to simply block out anything not assigned to that tunnel.
If a packet has a return path, the packet should use that as an
outgoing path too. This has to do with source spoofing and with
the fact that one otherwise would be giving a transit service
to that tunnel user. As most tunnelbroker services are free,
those ISP certainly aren't doing free transit for somebody else ;)
Also debugging problems becomes quite a mess.

Greets,
 Jeroen

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:07:49 -0500

-- jeudi, janvier 16, 2003 20:32:28 +0100 Erik Nordmark
<[email-masked]> wrote/a écrit:

> across NATs 

see draft-parent-blanchet-ngtrans-tsp-teredo-00.txt

applicability: draft-blanchet-ngtrans-tsp-applicability-00.txt

>is much better than 6to4 and Teredo when considering the space

tunnel brokers with TSP enables the user to receive:
- a ipv6 address of its tunnel endpoint. 
 + by policy, the broker could give it permanently, even if the ipv4
address change.
 + which means that you keep your ipv6 address permanent if you care.
- an ipv6 prefix, which enables a network behind the device: the network
could be a mobile small network or a fixed network.
 + the ipv6 prefix can be permanent (decided by policy of broker) after
being allocated by the broker.
- register inverse dns delegation.
- set up routing peering if necessary

> 
> The only downside of the tunnel broker schemes is potentially less
> efficient routing. 

- depends on where you put it.
- there is provision in TSP to make a redirect to another broker. redirect
could be related to topology. not perfect but could improve.

> But if the services are popular this might be a
> self-correcting problem. And if they are not popular it is either because
> there is sufficient native IPv6 access or that IPv6 is not being widely
> used.
> 
> over  TCP over NATs for those so inclined) in addition to the incentives
> above is that it avoids the security issues around 6to4 and Teredo, and is

yes. tunnel brokers are just configuring "configured tunnels". 
tsp is a way to automate the establishment of the tunnel, with
authentication.

> universes since it is all IPv6 native addresses with regular IPv6 routing.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:13:05 -0500

> that it didn't get pushed through?

we have made updates on the draft (but forgot to update the freenet6
website).
please refer to: draft-blanchet-ngtrans-tsp-*

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:16:19 -0500

-- samedi, janvier 18, 2003 00:34:07 +0200 Pekka Savola <[email-masked]>
wrote/a écrit:
> using some agreed protocol 

TSP?

> would happen to be publicized under a liberal
> license like BSD.)

freenet6 code, which implements tsp, has a Mozilla license.

> But of course, some kind of "tunnel broker discovery" or catalogues could

we have a proposal on this already, that I can send if people are
interested in it.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:19:00 -0500

> Appendix A mentions "A DTD should be placed here for the protocol."

it is finished and code is working. 
again draft on the web site was not updated, but the ietf directory has new
versions of the draft
draft-blanchet-ngtrans-tsp*

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:21:31 -0500

-- dimanche, janvier 19, 2003 18:54:06 +0100 Erik Nordmark
<[email-masked]> wrote/a écrit:

> automate this without any changes in the clients. Just have multiple
> tunnel servers at different places in the topology and have the tunnel
> broker meaure or estimate the location of the client before handing it
> off to a tunnel server.

yes. moreover, the tsp protocol enables the broker (again at the broker
level) to refer the client to another broker which would better fits its
needs (for whatever reason: 

> a higher probability that it actually works. And should it not work the
> icon allows you turn turn it off.
> 
>   Erik
>

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:23:17 -0500

> enough.  Being able to ship it by default in OS's helps.

freenet6 client (which implements tsp) is in the ports of freebsd and some
linux distributions.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:28:00 -0500

-- dimanche, janvier 19, 2003 22:42:20 +0100 Erik Nordmark
<[email-masked]> wrote/a écrit:

> My point is that tunnel brokers (plus prefix delegation?)

prefix delegation is what freenet6 (with tsp) is doing for years now, with
user authentication (using SASL framework).

> might make 

It is in order of many many thousands on just freenet6.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:30:14 -0500

-- dimanche, janvier 19, 2003 22:52:20 +0100 Erik Nordmark
<[email-masked]> wrote/a écrit:

>> OTOH, I think tunnel broker is a good way to provide default route for a
>> 6to4 site.
> 
> That raises questions of what source address filtering might be
> appropriate at the tunnel server - should they accept any source address?

tunnel server is implementing "configured tunnels", so strictly speaking,
only configured tunnels are "accepted".

> with the tunnel broker as part of configuring the tunnel broker ...

could be done, since the 6to4 prefix is derived from the ipv4 address of
the source, which is also the source address of the tsp request and the
tunnel endpoint.

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Jan 2003 06:24:19 +0200 (EET)

> with the tunnel broker as part of configuring the tunnel broker ...

There are no need for any changes provided that everybody implements the 
new default address selection.

That way communication between 6to4<->6to4 never uses the upstream tunnel 
broker, 6to4->native uses native source addresses and native->6to4 picks 
native destination addresses.

Or so I've thought.  This is very briefly noted in the new 6to4 security 
draft.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 06:37:02 -0500

On Mon, 20 Jan 2003 06:24:19 +0200 (EET)

> Or so I've thought.  This is very briefly noted in the new 6to4 security 

address selection is fundamentally broken.  it only works with two-party apps.

Keith

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Jan 2003 13:33:39 +0100

Hi,

> address selection is fundamentally broken.  it only works with two-party apps.

Could you elaborate this a bit more?  Everything that uses TCP or UDP
is a "two-party connection" - otherwise, you use multicast, which has
a completely different set of "address selection" issues.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  55857  (55593)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 07:48:30 -0500

On Mon, 20 Jan 2003 13:33:39 +0100

> a completely different set of "address selection" issues.

many applications involve more than two parties, even if the interconnections
between components of those applications are two-party connections.  a >2
component app often needs to be able to provide referrals from one component
to another - e.g. to say "if you need to access this component, contact it at
address A port P".  

if the network requires address selection in order to allow one component to
reach another, then it hinders operation of this kind of application. 
and for a variety of reasons, DNS is often too ambiguous, too slow, or too
unreliable for DNS names to be used as general-purpose names for hosts. 

actually DNS is a good example of an application that uses referrals, both for
its own use and for use by other applications.  but DNS is not the only app
that does this.

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Jan 2003 13:56:01 +0100

Hi,

> to another - e.g. to say "if you need to access this component, contact it at

In that case, a reasonable way would be to pass on the full set of 
addresses for A.  Especially for new protocols this should be taken
into account, or when adapting old protocols to IPv6.

(Deleting the already-written rant about broken protocols like FTP)

Gert Doering
        -- NetMaster

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 20 Jan 2003 10:36:30 -0500

>to another - e.g. to say "if you need to access this component, contact it at

I've been thinking about this a lot lately, and I wonder...  Why do these
referrals need to be by IP address?  It would make more sense to
refer another party to a DNS name and port number.  Then the other party
can do its own DNS look-up, and make its own address selection decision.

>unreliable for DNS names to be used as general-purpose names for hosts.

If DNS is too ambiguous, slow or unreliable for this purpose, shouldn't we
fix DNS?

Margaret

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 20 Jan 2003 16:50:35 +0100

> can do its own DNS look-up, and make its own address 

Not every IP has a correct forward/reverse pair.
Especially with the /64 subnets and then multiple ones on the same
net, not everybody will be putting up reverse and forwards.
Thus one needs to remain at IP <-> IP level :(

Also some protocols expect that the remote is the same as the other
connection comes from for security reasons etc.

Greets,
 Jeroen

---

From: Brian Haberman <[email-masked]>
Date: Mon, 20 Jan 2003 10:56:08 -0500

> can do its own DNS look-up, and make its own address selection decision.

Keith's argument is that DNS is too slow and not available.

> If DNS is too ambiguous, slow or unreliable for this purpose, shouldn't we

Yes!

If the referral model can be made to work with DNS, then many of
the issues with referrals and limited-scoped addresses would go
away (IMHO).

Regards,
Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 10:55:17 -0500

On Mon, 20 Jan 2003 10:36:30 -0500
Margaret Wasserman <[email-masked]> wrote:

> 
> 
> >many applications involve more than two parties, even if the
> >interconnections between components of those applications are
> >two-party connections.  a >2 component app often needs to be able to
> >provide referrals from one component to another - e.g. to say "if you
> >need to access this component, contact it at address A port P".
> 
> I've been thinking about this a lot lately, and I wonder...  Why do
> these referrals need to be by IP address?  It would make more sense to
> refer another party to a DNS name and port number.  

No it doesn't.  

First, because DNS is too slow and unreliable for some purposes; 

Second, because a host can have multiple DNS names associated with it at
any given time, but the binding between the DNS name and the host is
subject to change at any time and the host/app typically doesn't know
which DNS names are bound to which things; 

Third, because even if an app does use DNS lookup to get all of the
addresses of its peers it still doesn't mean that it's better to expect
the host/app to be responsible for routing than to expect the network to
do so.

> Then the other party can do its own DNS look-up, and make its own
> address selection decision.

It's the idea that it's reasonable to expect a host or app to make a decision about which address to use that I'm questioning.  Just because it's hard for the network to do routing on a large scale doesn't mean that apps and hosts are in a better position to do so.
 
> >if the network requires address selection in order to allow one
> >component to reach another, then it hinders operation of this kind of
> >application. and for a variety of reasons, DNS is often too
> >ambiguous, too slow, or too unreliable for DNS names to be used as
> >general-purpose names for hosts.
> 
> If DNS is too ambiguous, slow or unreliable for this purpose,
> shouldn't we fix DNS?

You can't fix DNS, at least not beyond a point.  Part of the problem is
that DNS names have long since ceased to be host names, and there's no
going back.  DNS names are now better thought of service names, with "host" just being another kind of service.  Another part of the problem is that DNS is by intent and design heavily federated and distributed, which means that DNS servers typically aren't co-located with, and don't share fate with, the endpoints that use them.

It may be possible to improve DNS, e.g. by building better tools to keep servers in sync and to discourage configuration errors, by using anycast addresses for DNS servers and using routing advertisements to direct queries to nearby servers that happen to be up, by building large distributed DNS server farms and getting sites to outsource their DNS servers to such farms (at least for their public DNS service), etc.  But I don't see this happening soon, and in any event I don't see how DNS can be made as reliable as IP.

DNS is a very useful service, but DNS names are not suitable as a universal replacement for IP addresses as endpoint identifiers.

-- 
I tried enlightenment but it kept crashing.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 10:57:10 -0500

> the issues with referrals and limited-scoped addresses would go

so if it's too hard to make IP routing work well, we'll just declare it somebody else's problem?   even though that somebody else is in an even worse position to solve that problem?

---

From: Brian Haberman <[email-masked]>
Date: Mon, 20 Jan 2003 11:06:50 -0500

> so if it's too hard to make IP routing work well, we'll just declare it somebody else's problem?   even though that somebody else is in an even worse position to solve that problem?

That is not what I am saying.  Some of the arguments you have
used are based on the DNS behavior.  My point is that if we
fix those, I would expect some of your concerns with referrals
could be fixed by using names rather than addresses.

Regards,
Brian

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Jan 2003 17:11:21 +0100

Hi,

On Mon, Jan 20, 2003 at 10:57:10AM -0500, Keith Moore wrote:
> so if it's too hard to make IP routing work well, we'll just declare 
> it somebody else's problem?   even though that somebody else is in an 
> even worse position to solve that problem?

It's part of the "make IP routing work" solution to put part of the burden
onto someone else.

I think we all agree that "giving everybody and his dog" portable address
space so he can do multihoming to his heart's content is not going to work.

So some other approaches are needed, and "multiple IPv6 prefixes on the
same infrastructure" combined with something like SCTP has potential to
be part of the solution, at least for a certain class of "globally-visible
address-space multihoming candidates".

Gert Doering
        -- NetMaster

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 20 Jan 2003 11:25:07 -0800

Marc Blanchet wrote:
> wrote/a icrit:

I have previously stated that I see merits in the TSP approach, but in
a complimentary (not competitive) sense wrt automatic tunneling. I believe
automatic tunneling can provide a ubiquitous, connectionless mechanism with
configured (and/or "semi-automatic") tunnels providing a connection-oriented
mechanism for special use-cases (e.g., when stronger security, bi-directonal
links, etc. are needed). See: 'draft-templin-interact-00.txt' for text
describing how an automatic tunneling mechanism (in this case, ISATAP)
can coexist with TSP.

Fred Templin
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 14:41:02 -0500

> > it somebody else's problem?   even though that somebody else is in
> > an even worse position to solve that problem?
> > 
> 

as I said in a separate thread, while DNS can be improved, I don't think it can be fixed to be fast or reliable enough for DNS names to serve as general-purpose endpoint identifiers.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 14:42:25 -0500

On Mon, 20 Jan 2003 17:11:21 +0100
Gert Doering <[email-masked]> wrote:

> It's part of the "make IP routing work" solution to put part of the
> burden onto someone else.

not when that "someone else" is even less capable of solving the problem.