Re: [v6tc] Re: Tunneling and Transition Drafts

[Jeroen Massar <[e-mail]>]

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