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

[Pekka Savola <pekkas@netcore.fi>]

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:
> 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.
> > 
> > Please, provide your feedback on it.
> 
> 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. 

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

> Basically I see three steps:
>  - Discovery of the 'best' tunneling service
>      <great gaping gap>

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.

>  - Configuration
>      Currently only TSP (any other takers?)
>  - Tunneling
>      (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...)

These two are out of scope of this document.

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

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

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


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

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

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

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

Global anycast has disadvantages as well, as noted in the draft (maybe 
not clearly enough).
 
> 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.

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

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.

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

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.

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

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