[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: draft-palet-v6ops-tun-auto-disc-01.txt
Dear Jeroen,
Thanks a lot for your comments. Please see in line my reply.
Regards
Miguel A. Diaz
> 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, ...)
>
I agree with your three steps view. Indeed, we also are working in other I-D regarding this steps. May be you could be interested on taking a look on it: http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt
However the auto-discovery memo only focuses on the discovery issues, which means that by means of whatever mechanism, one or possibly a list of tunnel-end-points (TEPs) is provided the user willing to get IPv6 connectivity. Which is the best TEP is out of the scope of such a memo. How the user chooses one TEP among all belonging to the provided list is also out of scope of such a memo. This topics are addressed on draft-palet-v6ops-auto-trans-00.txt
> 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
>
>
>
> **********************************
> 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.
**********************************
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.