On Wed, 2005-04-13 at 02:44 +0800, Fred Baker wrote: > I'm perfectly happy to standardize on existing types of tunnels - > IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or > whatever. If we don't solve the rendezvous problem (and btw communicate > to the peer what kind of tunnel a given gateway is willing to support) > we have not *touched* the transition problem. L2TP seems to cover the hole quite well. Except for the fact that there is no discovery and the datastream of L2TPv2, as LTPv3 has some magic stuff to fix it, can easily be spoofed, just like proto-41. IPSec can solve this, but requires authentication and external setup again. L2TP covers imho 90% of the cases. But... if you don't have a PPP infra it will be (harder) to setup. And it doesn't allow for quick mobility like in AYIYA or proto41+heartbeat. Thus when switching IP addresses (walking to another floor with your wireless) the tunnel needs to notice (L2TP StopCCN) that it is failing and renegotiate, which takes a few secs, not more, but might give a different IP etc as it will do RA's again or DHCPv6, which might take a bit longer and most likely will break your SSH session if you like this. But we are not standardizing Mobile IP here ;) It might be, according to some that L2TP+PPP is heavy code, including definitions about 2k lines of code for a minimal implementation that works. Overhead of a L2TP tunnel including PPP is minimal. At least it won't be noticed much when you are streaming video's over your neato G3's or whatever cellphone. Btw, anonymous tunnels in L2TP can be solved by not letting the server request authentication and letting it reject auth attempts from the client. Though I have not been able to verify how many servers support this. TSP or a similar protocol is IMHO a must, because L2TP simply can't be deployed everywhere and better, not everybody wants it: Market::Decide() TSP is handy in all cases, it can also have a template pointing to a L2TP server etc. Next to that there is a client available for all platforms. As for the point made in the minutes that there is only one implementation, AICCU will support TSP too as an option in the near future. > And what I would like to see happen is for someone, somewhere - and > note that I am very willing to do this in v6ops if people want and also > willing to send it to v6tc or wherever else - to solve that rendezvous > problem. As a result, I would like to see the various competing > transition strategies all rendered OBE and get everyone to converge on > a single transition approach. I've finally submitted my "_service" draft to the secretariat, it should appear shortly in dnsop. I'll forward it to v6ops + v6tc when it is there. In "short": Anycast prefix 1.2.3.0/24, on which on 1.2.3.53 there is a DNS server listening. This is a (caching) recursive server which can be used for looking up anything (www.google.com www.ietf.org etc). It is also authoritive for the "_service." domain, in which we stick SRV records. Usually _service is a DNAME to _service.example.net. Which fulfills the searchpath, if the user does not have this special DNS server configured, but does have it's ISP's domain in the searchpath, then the resolver will come to _service.example.net because of the searchpath. Thus, client gets turned on, it gets connectivity, it needs to lookup something, resolver is default configured to 1.2.3.53, resolving thus works. The prefix is anycasted by it's or another ISP, who can filter on wish etc. If user needs a service, eg SMTP, it resolves the SMTP SRV records, which can specify load balancing and other stuff. Same for POP3, IMAP, or lookup eg help.www._service which returns a TXT record to the URL of the servicedesk of the ISP you are using. For the v6ops/v6tc case a client can first try l2tp.ipv6._service if that exists, use it, then try tsp.ipv6._service, if that exists, use that one. Discovery solved in the most generic way. It does indeed take a couple of resolves, but hey people want it automatically. As for the ones screaming "but I don't want a default thing" then configure the client you are using for doing this. Of course a similar prefix for IPv6 so that this also solves dns configuration. Another good thing is that, assuming you have connectivity you will always have the closest dns server, also ISP's can then nicely block all the RFC1918 registrations in those, but that is most likely just a good hope from me, most don't even filter... Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part