Re: ISATAP scenario

[Christian Schild <schild@uni-muenster.de>]

On Tue, 2004-08-03 at 19:34, Florent Parent wrote:
> -- On Tuesday, August 03, 2004 17:58:30 +0200, Christian Schild wrote:
> 
> ...
> 
> > The solution we offer now is a homegrown tunnel broker based on OpenVPN
> > which is much more complex and requires much more interaction and
> > knowledge of the user.
> 
> Complexity here is more related to your implementation. I suggest you take 
> a look at the TSP broker implementation (client code available on 
> www.freenet6.net, multiple platforms supported). From the user point of 
> view, this is a service that runs in the backgroud which keeps your IPv6 
> connectivity up and running. And you get NAT traversal as a bonus.
> 
> My point here is simply that tunnel broker/assisted tunneling solution can 
> be as simple to the enduser as other mechanisms.

I partly agree. The OpenVPN solution might be quite similar to yours. 

Still, it is a difference if a user has to install a software, configure
and maybe troubleshoot it, or if he just has to activate a service
(which e.g. is one of the beauties of 6to4 and probably made it a
success story).

> > Beforehand we planned to use ISATAP for such
> > single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP
> > and now there is no such support in linux kernels. So we had to drop
> > that solution as we could no longer offer support for all main operating
> > systems in our network.
> >
> > So you might agree, there is a real demand for ISATAP and it's a pity it
> > should go experimental track now, given the facts, that there is a real
> > scenario for it, that it is (was) already implemented and that latest
> > discussion showed it could be a solution in 3gpp scenarios.
> 
> This was mentionned during the v6ops meeting:
> 
> <http://www.linux-ipv6.org/ml/usagi-announce/msg00102.html>.
> "remove ISATAP because it is (1) rather obsolete and (2) of IPR 
> <http://www.ietf.org/ietf/IPR/sri-ipr-draft-ietf-ngtrans-isatap.txt>."
> 
> Fred T. reported that is was put back in USAGI 2.4.

Yes.
I am aware of the IPR claims which hindered ISATAP (which in return is
also a pity). 
The point is, due to that regression, ISATAP is not available in current
kernels and couldn't get offered as a standard service, while it was
close to it years ago.

Christian