Re: [v6tc] Re: Tunneling and Transition Drafts

[Fred Baker <[e-mail]>]

Realistically, I think all of the various tunneling technologies will 
in fact be used. The important question is the rendezvous problem.

On Apr 13, 2005, at 4:25 AM, Jeroen Massar wrote:

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

_______________________________________________
v6tc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc