Subject: draft-palet-v6ops-tun-auto-disc-01.txt

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 11 Jun 2004 11:34:53 +0200

Hi,

We just submitted this document (Analysis of IPv6 Tunnel End-point Discovery Mechanisms). While officially published, a copy is available at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-01.txt.

Please, provide your feedback on it.

Regards,
Jordi

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 11 Jun 2004 13:17:16 +0200

On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped):
> Hi,
> 
> We just submitted this document (Analysis of IPv6 Tunnel End-point Discovery Mechanisms).
>
>  While officially published, a copy is available at
>
>  http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-01.txt.
> 

All the scenarios basically can be solved all with existing solutions
(TSP for instance). The issue of discovery is not the problem of the
communication between the client and the 'server' to negotiate the
tunnel parameters but _how_ to discover which is the 'best' service.
When a user knows his/her/its/... provider they already know what to
configure or it is already configured. The issue which needs to be
solved is the case where one doesn't have any configuration data or
doesn't want to use the current configuration data and automatically
discover the closest/best tunneling solution to get IPv6 connectivity.

Basically I see three steps:
 - Discovery of the 'best' tunneling service
     <great gaping gap>
 - Configuration
     Currently only TSP (any other takers?)
 - Tunneling
     (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...)

The text, abstract and actually the complete text mentions
"configuring the IPv6 tunnel endpoint on a node."
I would change that part to 'tunneling service' instead of 'tunnel endpoint'.
As mentioned in 3.1, the service could consist of multiple servers though
there is only one 'endpoint'. A service eg a Tunnel Broker, might even
have multiple endpoints etc.

Therefor I miss one possible scenario & solution:
One could announce a standardized anycast address (eg 192.0.2.6), which
can then be hardcoded into clients, maybe better to have something like
tunnelautodiscovery.ietf.org as DNS can always be changed, this could
then also be combined with the DNS prefixing path search etc.
This address, when contacted using UDP returns a packet which contains a
list of closest services that can offer tunneling solutions, along with
the type of service they provide, thus reference to them, not the final
solution. Eg a response could contain:
8<----
www.example.org tunnelbroker
tsp.example.org TSP
6to4.example.net 6to4
teredo.example.net teredo
...
---->8
The user will be presented with an optionlist to choose from or
alternatively based on properties/policies etc the client could
automatically pick the best out of the list and use that. Then
either the website, TSP, 6to4, teredo, etc take over on the process.
The discovery is really discovery here and nothing else.

ISP's which don't announce this service will recieve the prefix from
another ISP and of course could simply optional nullroute the prefix if
they want to disable this service from other ISP's and when they don't
want their users to use this service due to administrative policy etc.

Having the above would then be probably better solved with an anycast
DNS server to be able to ask that server multiple different questions
and maybe directly supply a default DNS server for many hosts solving
quite a number of problems.

Some nits about the draft:
8<--------
   TBD: should this scenario be removed? Third party ISPs may be not
   economically feasible for free, even if there is some limited
   deployment of them at the moment.  But it could be a registered and
   paid external service, for example a roaming service agreed among
   differnt ISPs.
-------->8
There are several proven installations that have been around for a
number of years that provide free (IPv6) tunneling services.
Payment should be out of scope here, but to solve the issue the above
suggested scenario could add a 'payed' or 'free' flag to note it.
Any service has a AUP or some other form of rules, one of those rules
could be payment.

The solution in 3.1 is IMHO not doable, as this defines a tunnel
endpoint but never mentions how the Tunnel Server knows where/who/what
the remote endpoint (client) is, which is autoconfigured to use the
anycast address in the first place.
How is it going to know which prefix to use and how is the TS going
to know where to route packets destined for that prefix?
Anycasting a TS is a nice idea, but IMHO in a routing sense will not
work unless you embed the IPv4 address into the IPv6 address, which
basically leads you to: Teredo & Silkroad like solutions.
Also keeping state distributed over several TS's is not likely to be
a easy thing, doable of course but still.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jun 2004 12:58:04 +0300 (EEST)

Thanks for comments..

I think your assumptions are different from those based on which this
draft was written.  They might warrant spelling out, but in the
interests of learning how to enhance the document, it would be best if
you could state more clearly which parts of the document you find
objectionable (and how to fix the issue, if possible).

On Fri, 11 Jun 2004, Jeroen Massar wrote:
> configure or it is already configured. 

I disagree with your last sentence, but see below..

> The issue which needs to be solved is the case where one doesn't
> have any configuration data or doesn't want to use the current
> configuration data and automatically discover the closest/best
> tunneling solution to get IPv6 connectivity.

You seem to be saying two differnet things here.  Above, you mentioned
that you seem to assume the user must know what his/her ISP is
providing and manually configure it.  Here you say there is indeed an
issue in automatic discovery of that information. Are you making the
assumption that the user learns that the ISP has a tunnel server from
somwhere (e.g., a web page) and manually configures it?

To make it clear, IMHO, for wide-scale deployment, non-automatic
configuration is completely unacceptable. I want to do away with such
manual configuration.  The main point of the automatic discovery
document is to describe mechanisms how the host stacks can run a
simple procedure which can lead to a result like, "yes, tunnel service
is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not
available."

>  - Discovery of the 'best' tunneling service

It doesn't have to discovery of the *best* service necessarily, but 
discovery of the service.  There's sufficiently large great gaping gap 
here... and this is what this document aims to address.

>      (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...)

These two are out of scope of this document.

> have multiple endpoints etc.

I'd be reluctant to say 'tunnel service', as you don't configure 
anything about the service itself, just the tunnel end-point.  All 
other means of configuring (or reconfiguring if there is a broker) are 
out of scope of this specification.

(Later, why you said this becomes clearer: you have the assumption 
that the service would be used for general purpose service discovery, 
for multiple tunneling mechanisms.  I don't make this assumption -- 
this method would be mechanism-specific.)
 
> then also be combined with the DNS prefixing path search etc.

There is is mentioned in section 3.1 as so-called "global anycast".

> solution. Eg a response could contain:

What you're describing is a combination of a global anycast and 
centralized broker-based system (sect 3.1 & 3.2).

> The discovery is really discovery here and nothing else.

You make the assumption that the discovery process would be common for
all the the mechanisms.  I don't.  Making it common might have an
advantage or two, but a lot of disadvantages -- the most important of
them is probably that the responder must know of all the services that
are supported.
 
> quite a number of problems.

Global anycast has disadvantages as well, as noted in the draft (maybe 
not clearly enough).
 
> Some nits about the draft:

IMHO those installations prove only little of more wide-scale 
deployment, e.g., when there would be over a million users worldwide 
or the like.  That's what we need to aim for .. not for providing 
services to IPv6 geeks or other techy users -- those will get it in 
any case so it doesn't matter.
 
> anycast address in the first place.

All the solutions assume that the tunneling mechanism -specific means 
are used to obtain that.  E.g., one could have a pseudo-interface 
which creates tunnels on the receipt of the first packet, or 
something.  This should not be a problem.

> to know where to route packets destined for that prefix?

The client doesn't need to know the prefix but it might.  It could 
just learn the prefix from the TS, similar to the process STEP uses.

> a easy thing, doable of course but still.

Embedding the v4 address is one way to achieve this goal, but not the
only one.  It's probably a requirement for a completely stateless
solution, but that's probably not something we need to aim for.

-- 
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: Jeroen Massar <[email-masked]>
Date: Wed, 16 Jun 2004 19:15:37 +0200

> objectionable (and how to fix the issue, if possible).

No, I think I am looking the issue from a different perspective.

The document is talking about 'tunnel endpoints' while IMHO these should
be 'tunnel services'. Who provides them and how they are negotiated is
not mentioned at all in the document and is up to the various
configuration protocols, while this document is targetted solely afaik
at the discovery part.

> > On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped):

<SNIP misunderstanding part ;)>

> is available, at IPv4 addrexx a.b.c.d", or, "no, tunnel service is not

Indeed. Non-Automatic doesn't work. It works, but only for a few people
who want to invest the time and effort. These are not the
random-joe-virus-running-users at which this should be targetted.

But I would rather see the discovery part say:
The service is available from:
  - here
  - there
  - there too

Or when the client only has one choice or thinks it is feasible enough
for a certain choice to use that directly.

You also note 'host stacks' but wouldn't this be better to place simply
as an additional tool. radvd isn't a part of the stack either in most
OS's at the moment. Also I am quite sure that there a lot of people who
don't want something to automatically configure it for them so anything
using this tool would need to either be setup by the user or have enough
knowledge to not run in a native network.

> here... and this is what this document aims to address.

'best' is the one that fits mostly in the situations that the discovery
is taking place in. 'best' could thus be the one that is anycasted
closest to the host etc and depends totally on the discovery method.
This is what the doc should describe.

> >      Currently only TSP (any other takers?)

I apparently forgot STEP, but that is basically normal RA etc which
every host should support.

> These two are out of scope of this document.

Thus my assumption that this document is targeted at the gap above is
correct. Then one should not be finding the best tunnel _endpoint_ but
the tunnel _service_ which can provide that endpoint. TSP for instance
does its own endpoint negotiation. Having a discovery method do that
would thus make TSP either be only for that single Tunnel Server or it
would require another step. The 'endpoint' wording thus is wrong IMHO
and should be resplaced by 'service'.

As the Discovery service can in no way know the load of the Tunnel
Service and any other properties that the provider of the service wants
to include into the calculation, wouldn't it be better after one has
discovered the 'best' service to then hand it over to for instance TSP
or STEP?

> out of scope of this specification.

With 'tunnel service' you designate the closest possiblity of giving you
the 'service' which is "providing IPv6 connectivity". With a tunnel
endpoint one would mean 'exactly that endpoint'.

> for multiple tunneling mechanisms.

Not entirely, this discovery method _could_ point to multiple tunneling
mechanism, but if the IETF reaches concensus one single protocol, then
it could be just that. Still it would be better to let the service
determine the real endpoint. Based on DNS or anycast this is simply not
an option.

What if you have a dialin pool for 'low paying' clients and 'high
paying' clients, you might want to give a better service to the ones
that give you more money, anycast nor DNS will not work here unless one
does a lot of tricks. Letting a service decide it, after that that
service has been automatically discovered is a better and more flexible
option. The service can then also either redirect the user somewhere
else or give a nice visual error message through one protocol or
another. The mechanisms described in this draft allow no such thing
because the endpoint of the tunnel is directly configured.

> I don't make this assumption -- 

If this document is mechanism specific shouldn't these descriptions then
be included in that mechanism ?

> There is is mentioned in section 3.1 as so-called "global anycast".

Which targets a completely different audience: a local (organisational)
network and nothing bigger, eg providing service to a complete IX.

> centralized broker-based system (sect 3.1 & 3.2).

Almost, because a 'service' would not have to have any of the broker
attributes. It could just tell you '6to4 is over there' and done.

> advantage or two,

The biggest advantage would be that it is generic and that it will work
for all situations and not just a few. If you only want a few, then that
would be like designing IPv6 only for the polar caps as there it freezes
but nowhere else. I don't see any OS vendor wanting to include a tool
then. The scale of Teredo is the target, aka every desktop user pc
should have it. And every of the above mechanisms solves a different
problem which the others don't. Then if one just says 'always use this'
it won't work for a large chunk of the other users and or ISP's who
might want to deploy it and they will not adopt it.

>  but a lot of disadvantages -- the most important of

Unless the IETF makes the decision that for instance TSP or STEP becomes
the 'standard' protocol for resolving these issues.

The problem I see here is that otherwise there will be tens of
'discovery prefixes', one /24 for IPv4, a /32 for IPv6 etc. While these
can all be nicely fit into one prefix per protocol. Easy for ISP's to
filter and easy for them to setup.

> Global anycast has disadvantages as well, as noted in the draft (maybe 

Using anycast for discovery doesn't have any drawbacks as the packet
exchange between the client and the 'server' would be minimal.
If you want to use anycast as a tunnel _endpoint_ that is a different
story, but this was about discovery thus we are hopefully talking
services here and not endpoints...

> any case so it doesn't matter.

I think that the end users of these systems will look at that in
completely way. Saying that something free and/or public 'is not good
enough' is not a smart thing, two words: BSD & Linux (in random order).
How many users for instance Freenet6 and Hurricane serve is unknown.
That they are not millions is mostly because there is no default tool
installed on the common users boxes, also their is no valuable content
(yet) for attracting the users to start using it

I can also note that I know that the largest amount of those users have
no clue at *all* what IPv6 is. Most of them simply get a nice host on
IRC and the others have a good newsfeed. They really don't care, they
just click a couple of times and run a script or some tool.

That these are not standardized by the IETF doesn't say they don't exist
and certainly don't mean that they are not used...

> something.  This should not be a problem.

I already see that script kiddy spoofing IPv4 packets with ease and
generating a lot of interfaces at random, but how was that configured?
Or better said how did you authenticate the user to the tunnel service?
Especially when the user is not directly coming from your own IPv4
space, a remote mobile user, a user visiting another ISP's network etc.

l2tp / AYIYA / ... etc could be used as those protocols provide
authentication inside the protocol stream, but proto-41, which is the
most common used setup doesn't work in this case.

> just learn the prefix from the TS, similar to the process STEP uses.

STEP/TSP fall under the "Configuration" header in the 3-phase list.
These should IMHO determine the type of protocol for the data being
tunneled. STEP though doesn't define any protocol, thus would be limited
to the underlying protocol that would be used, which would then make
this only applicable in a few scenarios of the many that exist.
Which again doesn't make it applicable for the many users and varying
setups out around the world.

Greets,
 Jeroen