On Sat, 2004-06-12 at 11:58, Pekka Savola wrote: > 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). 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, 11 Jun 2004, Jeroen Massar wrote: > > On Fri, 2004-06-11 at 11:34, JORDI PALET MARTINEZ wrote (lines wrapped): <SNIP misunderstanding part ;)> > 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." 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. > > 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. '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. > > - Configuration > > Currently only TSP (any other takers?) I apparently forgot STEP, but that is basically normal RA etc which every host should support. > > - Tunneling > > (proto-41, 6to4, teredo, ayiya, tinc, openvpn, ...) > > 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? > > 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. 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'. > (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. 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 -- > this method would be mechanism-specific.) If this document is mechanism specific shouldn't these descriptions then be included in that mechanism ? > > 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". Which targets a completely different audience: a local (organisational) network and nothing bigger, eg providing service to a complete IX. > > 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). 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. > > 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, 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 > them is probably that the responder must know of all the services that > are supported. 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. > > 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). 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... > > 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. 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... > > 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. 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. > > 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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part