Re: Tunneling scenarios and mechanisms evaluation

[Pekka Savola <pekkas@netcore.fi>]

Thanks for the feedback, Alain.  Responses inline..

On Thu, 11 Mar 2004, Alain Durand wrote:
> On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote:
> Couple questions/comments:
> 
> 1)
> Section 4.3:
>     Therefore we get that Teredo and STEP is the lowest common
>     denominator, after having to take a few tough issues in the
>     consideration, with Teredo and TSP coming somewhat behind.
> 
> Is there a typo here? Teredo is listed twice.

This is intended.  Based on the analysis, the requirement for Teredo 
exists no matter what else we choose.  The most preferable solutions
in addition to Teredo, however, seemed to be STEP and TSP.

> 2)
> This draft makes a big issue about direct connectivity and bases
> the some underlying recommendations on this.
> 
> let me ask: is this really a requirement or yet another nice to have?
> What will break without direct connectivity? (in any of the scenarios)

When your ISP doesn't offer IPv6 connectivity, but you would have to 
take a "long leg" to get it, it seems that to be able to achieve 
anything useful (e.g., peer to peer connectivity), direct connectivity 
is a real requirement.

On the other hand, when your ISP/operator is offering IPv6 
connectivity, in my eyes it is *not* a strict requirement (and not 
reflected as such in the analysis), because the extra leg that needs 
to be taken is probably in the order of 1-10 ms, not 30-300 ms.  The 
former is still usable, the latter not.

> If nothing really breaks, but things are just sub-optimal, then I
> would say this is not that bad. remember that we are talking about
> transition mechanisms, they DO NOT NEED to be perfect, if not we
> will never deploy fully IPv6... So, in a certain sense, suboptimal
> transition mechanisms can be good in the long run ;-)

I agree that I don't (personally) think direct connectivity is a 
requirement, for reasons you state, when your ISP/operator is offering 
the tunnel service.  I'm not sure which context you're discussing, but 
if you're saying that direct connectivity is not a requirement in the 
cases where your ISP is not offering a service, then I would have to 
disagree due to concerns of scalability for large-scale deployment.

> 3) this document acknowledge the importance of things that have been
> implemented and deployed but treats TSP and STEP as equal. I think
> this comparison is biased.

Implemented & deployed are tradeoffs among others.  There may of
course be some bias here :).

> To be fair, one should compare Tunnel broker & STEP as TSP is a
> particular implementation of the tunnel broker model that has
> incorporated UDP tunneling. There are a huge number of users of the
> many variant of tunnel brokers, so it is a model that has been
> proven. On the other hand, the document recognize that STEP has
> never been implemented.

I have to disagree here.  The tunnel broker is just a concept.  It 
doesn't fly on its own.  It's not even interoperable, which is causing 
a lot of problems.  STEP, as a matter of fact, is also a tunnel broker 
of a kind.

My personal preference would be to create a combination of TSP, STEP
(and ISATAP, to a lesser degree) as a single tunnel server solution:  
providing simplicity of STEP when more complex setups aren't needed,
yet providing (additional, optional?) flexibility of TSP in the cases
where e.g., static prefix is desirable.

IMHO, TSP is unnecessarily heavyweight when all you need is just a
simple IPv6 address.  You don't really need to do all of that
signalling for the basic usage case..

> 4)
>
> I was not at the last two IETF meetings for family reasons, so I
> might miss something. However, here is what I take from the analysis
> done in this document:
> 
> 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel 
> management.

Totally agree here.

> The tunnel broker model seems to work fine as demonstrated by TSP,
> which I regard as an existence proof. This area need to be
> standardized, by advancing TSP or an evolution of it on the standard
> track.
>
> Note: With regard to TSP, we are not in a situation of take it or
> leave it. If the ban on developing tools is lifted, I'm convince
> that we could design something very quickly if the detail analysis
> of TSP shows improvement are necessary.

Such ban does not exist, and IMHO it is clear that TSP (or the model
in general) requires a lot of improvement -- I reviewed it some time
ago, and sent feedback on the list.  So far that I'd rather start from
scratch, while keeping the model intact..  But this is something that 
would be very quickly doable, if we want to do it.

> 2- Teredo is only necessary when direct connection is mandatory and
> there is no help from the ISP. if the wg thinks that direct
> connectivity is absolutely necessary and this is a valid scenario,
> then we should advance Teredo on the standard track. If not,
> publication as experimental is always an option.

Yep.  Though there was some resistance to moving it along for now in 
the meeting, calling for analysis. (It's interesting, as people were 
previously shouting for moving forward.)

> 3- Isatap is really interesting in sparse deployment, which are
> early scenario. If this wg takes another 4 years to look at it, then
> its value would have long been depreciated...

Did you mean s/really interesting/really only interesting/?

The benefit of ISATAP is providing direct tunneling between the nodes.  
This may be interesting in sparse deployment (compared to 
going dual-stack; but in sparse deployment, tunnel server is also 
fine), and some have even expressed interest in dense deployment 
(compared to dual-stack: not wanting to go there; compared to tunnel 
server: not overloading the server).  IMHO, the dense deployment 
scenario calls for dual-stack, and we should not be hacking to work 
around that.. and sparse deployment can be facilitated by a tunnel 
server.  So, personally, I'm not sure if I see much applicability in 
direct connectivity in this specific "ISP-assisted" context.

> 5)
> what about the others, like 6to4? Do we still need this despite the 
> issues with the relays?

Unfortunately, I think yes -- in the unmanaged case where there is no 
ISP support ...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings