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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part