ISATAP scenario

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

To give some feedback to the discussion about ISATAP:


We try to run/launch IPv6 in a large university network very similar to
the case Tim presented in his drafts. 

Especially we use VLAN .1Q tagging technology to "import" IPv6
capablitity to selected subnets. 

In fact, right now injecting IPv6 and IPv6 routing into the already
existing VLANs is our only available mechanism to introduce IPv6  
due to current hardware and network restrictions. 

Still, there are some very large VLANs with large broadcast areas spread
all over our network and the network operators refuse to activate IPv6
in such VLANs, because of probable complex risks that could interrupt
the current set of services. While this is partly based on fear to
activate IPv6, there are also known real problems that could arise when
running dual stack in the network and effects are highly unpredictable
in large heterogenous subnets.

The point is, we couldn't offer IPv6 in some subnets (these large VLANs
are only one example, outdated hardware may be another). However, there
are single hosts in these subnets that need IPv6 connectivity. 

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

Christian