[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opportunistic Tunneling

[[ list administrator note: non-member submission ]]

Pekka,

I think this can be looked at from the perspective of who is driving
the IPv6 deployment.

If the user wants to use an application (or something else) which
requires or would profit from IPv6, I consider the case "user-driven".
The user says, "I want to do X", where X requires IPv6.  As the user
has motivation for getting IPv6 connectivity, (s)he will be willing to
do some effort to make it happen: e.g., contact his ISP, asking for a
tunnel or native service, contact a tunnel broker, or whatever.  This
is the model we've started with, I think.  Automatic mechanisms can
help here as well, but they aren't strictly required IMHO.

Now, let's look at this from the different angle.  A vendor wants to
start using IPv6 in its products for some specific reason, independent
of what the user thinks.  For example, to simplify its peer-to-peer
applications.  To be able to deploy the new version of the
products/applications in any meaningful way, the vendor requires that
IPv6 connectivity must be available to all or at least significant
portion of the user base.  As there are thousands of ISPs in the
world, with only a few offering IPv6, "managed methods" as described
above are a non-starter.  The vendor requires *something* which will
be able to kickstart IPv6 deployment.  The deployment of automatic
tunneling mechanisms is this something.

Hope this clarifies..

Actually, it doesn't. I think they are the same.

The vendor supplies the application requires (or benefits) from IPv6 that the user wants to use. The vendor can supply it so it requires the user to acquire IPv6 service, or it build into its product the ability to detect existing IPv6 connectivity on the users system and if there isn't there, initiate create it via one of the automatic tunneling mechanisms.

Both scenarios are vendor and user. The only difference I can see is if the vendor includes the capability to automatically create IPv6 connectivity. Both are driven by the user (wanting to use an application) and enabled by the vendor (including it in the product). The vendor can't make the user do anything (or even buy it's products). I don't see the distinction you are proposing as being useful.

More importantly in the current world, a vendor who doesn't include the capability to create IPv6 connectivity where it doesn't exist isn't going to see very much IPv6 application usage. The number of users on the Internet who will know to ask for IPv6 (or anything else technical like public addresses in IPv4) is very very small. How many even know they have a NAT....

This is also why I think that standardizing the current set of automatic tunneling (or whatever we want to call it) mechanisms is very important. We should stop analyzing the requirements and publish the specifications ASAP.

Bob