Re: [v6tc] Re: Tunneling and Transition Drafts

[Jeroen Massar <[e-mail]>]

On Fri, 2005-04-08 at 14:21 +0300, Pekka Savola wrote: 
> On Fri, 8 Apr 2005, Jeroen Massar wrote:
> > On Fri, 2005-04-08 at 13:12 +0300, Pekka Savola wrote:
> >> On Fri, 8 Apr 2005, Jerome Durand wrote:
> >>> The point here is that as an ISP, I'd prefer to work with a standard,
> >>> manageable and available solution. Is one already available? If yes that is
> >>> worth documenting how to use/deploy it (in v6ops WG). If not, then we have to
> >>> adopt a new standard (in v6tc as v6ops is not made for it).
> >>
> >> L2TP ?
> >
> > Client for all OS's that support it doing IPv6 ?
> 
> AFAIK, as L2TP layers on top of PPP, you only need PPP to support 
> IPv6, right ?

Correct. Now guess what one the biggest OS, that is deployed at
consumers, does not support :)

Ah, indeed Windows XP, even SP2 does not support IPv6 PPP (at least last time I checked).
Have fun implementing that and then passing it to your clients.

> Anyway, anything that's in the real of implementations has issues in 
> one way or another.

Then I suggest that, like I asked MS when they implement the above, when
those issues get fixed. That is a vendor problem, not a protocol problem I hope.

> As I've said in the past, I see no point in standardizing TSP as it is 
> because L2TP provides the same functionality.

Since when does L2TP support anonymous tunnels?
Since when does proto-115 cross NAT's ?

> One the other hand, if 
> we had requirements which cannot be satisfied (in a backward 
> compatible manner) by either L2TP or TSP, it makes sense to design 
> something new.

Why design something new if people who are happy with L2TP can use that,
while people who are happy with TSP can use that.

Both suffer one thing, as I mentioned previously: "discovery".

> One such requirement could be low latency and overhead; at the moment, 
> however, it is not obvious whether the different wireless communities 
> (including what Mobile IPv6 and NEMO WGs are currently discussing wrt 
> NAT traversal -- _yet another_ tunneling mechanism, this time 
> (probably) specific to Mobile IP!) were sufficiently aware of this 
> effort to bring forth theirs requirements.

There is even NAT traversal for HIP and a lot of other protocols being done.
The pain it brought was not to be foreseen ;)

On Fri, 2005-04-08 at 12:49 +0200, JORDI PALET MARTINEZ wrote:
> L2TP will be a good solution if it works in any situation, but more and
> more, unfortunately, I find hotspots where I can use 6in4, Teredo, other,
> but my L2TP VPN doesn't work !

L2TP typically does not work for the same reason why proto-41 does not
work: NAT boxes don't forward proto-41 nor proto-115.

Also LT2P has the limitation that it requires authenticated use, which
was not acceptable according to some people on this and the v6ops list.

One conclusion I can make from all these discussions is though that:
- There are a number of mechanisms
- These mechanisms all have their distinct advantages

Or better said: let the market decide on what to use.

The IETF is afaik supposed to make standards, of which there are many,
many of which most people won't use, because they don't fit the thing
they want to do. In this specific problem there are a lot of ways to do
something and there are a lot of problems which simply can't be solved
with one problem especially because of the broad set of requirements.

My take on this thus becomes:
- In general tunneling IPv6 over UDP works *everywhere*
  (unless there is an administrative filter prohibiting it
   in which case we should not try to override it either)
- TSP is deployed and works (*)

For that reason I would suggest that combination. People with other
requirements can pick their own.

> That's why I think we need a protocol that can try several encapsulations in
> case the best one doesn't work.

And then have the thing to try to get around a limitation which might
quite well be an administrative barrier?

I thought there where people concerned with 'setup latency' ;)

Greets,
 Jeroen

* = also with the few shortcomings I noted already a couple of times.

_______________________________________________
v6tc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc