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

Re: Opportunistic Tunneling

Pekka & Jonne,

As the Unmanaged Analysis document is currently at WG Last Call, the
biggest issue appears to be the so-called "opportunistic tunneling",
i.e., automatic tunneling which would be possible without set-up or
ISP support.  Examples of these are 6to4 and Teredo. (No other
specific proposals have been made.)  We need to figure out how to move

I thought ISTAP fell into this category as well? There have been a seres of drafts.

forward. The critical questions are at least:

 1) Do we agree that this is something we need in the first place?
     * Considering user-driven deployment, maybe not.
        - example: the user says "I want to use application X" or "I
          want to use functionality Y", where X or Y would require
          IPv6.
     * Considering large-scale vendor-centric deployment, probably
       yes.

Yes, it is needed. Not all ISPs will initially offer IPv6 and having these tunneling mechanism will allow people to still use IPv6 without any direct action of their ISP. I think this is essential to getting IPv6 used by people and to encourage new applications. I also think it will have the effect of encouraging ISP to deploy native IPv6 once the see the automatic tunneled traffic growing. I don't think we want these "transition mechanisms" to be around forever (or even a long time) as we know their limitations, but I think they are very important the beginning of the transition.

 2) What are the models for deploying relays, considering the economic
    or deployment considerations (in-host, in-site, network)?
     * And what are the implications of any approach?
     * Can we decide on the recommended model?

I think the answer to this can be found by looking at what is deployed now. In any case, I didn't think the IETF needs to be discussion economic models.

 3) For NAT traversing, opportunistic tunneling, are there any
    features in Teredo which are missing or are unnecessary? I.e.,
    how good a fit would it be?  Are there alternatives?

Given there is already a lot of operational experience we should standardize it now. It can be revised later based on additional operational experience. There isn't any reason to delay this further.

We're soliciting input on how to best handle this situation. Please

I think that these mechanisms should be standardized as soon as possible. There is a need and people are already staring to ship these in products. There should be open standards for the mechanisms to allow everyone to deploy and use them if they want to.

send feedback to the chairs or on the list. Tentatively, we're
scheduling 20-30 minutes for discussion in Seoul, but how productive
such discussion would be would depend on the framing and the contents
of presentations and/or discussion. 


Thanks,
Bob