RE: Tunneling scenarios and mechanisms evaluation

["Jeroen Massar" <jeroen@unfix.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain Durand wrote:

> On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote:
> 
> > Hi,
> >
> > The presentation on tunneling scenarios and mechanisms has now been
> > converted to an Internet-Draft.  Some additional text was also added;
> > some other minor modifications were made
> 
> 
> Couple questions/comments:

<SNIP>

> 1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel 
> management.
> 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.

I'd rather see the IPv6 in UDP protocol be defined as that is not
included in a draft as it is not documented in any of the old nor
in the new draft (draft-blanchet-v6ops-tunnelbroker-tsp-00) and
I think that it is an interesting thing to have as many of those
so called "NAT-routers" don't support proto-41 forwarding but
do allow forwarding of udp packets on a certain port. This is
basically one of the things that Teredo addresses but that uses
a completely different model and also has signalling included.
The TSPC 1.0 sources provided through the Freenet6 site don't
mention anything about these UDP tunnels either. Having a
standard for these would be a good thing as then the OS's could
be made to support it also and afaik there is no such support yet.
Maybe the above is going to be addressed for -01?
PS: Marc, use 2001:db8::/32 and 192.0.2.0/24 in examples.

Currently I am using tinc in cases where proto-41 doesn't
penetrate the NAT or the firewall, btw think of IPv6 over tinc
over httptunnel's and have IPv6 everywhere you want ;)

As for automatic 'repointing' of tunnels I have written and
implemented draft-massar-v6ops-heartbeat-00 for those cases.
These types of tunnels are proto-41 mind you but the protocol
defined in that draft could easily be made to reconfigure
udp tunnels and the likes as the protocol itself only handles
either a src+dst pair or inner src+dst & outer src+dst pairs,
thus it is not tunneling-protocol bound.

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

Is there a ban on developing tools based on TSP? Please elaborate.
I do have another, somewhat more of my own 'problem' with TSP
and that is that I can't seem to make it fit the model of the
SixXS tunnelbroker we are running, which is why we described
our own protocol + tools for configuring clients. Draft not
ready yet though. For configuration only the serverside of
TSP could be implemented, but I guess it would be more reading
the older drafts and the sources of tspc to make that work.

<SNIP>

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

There seem to be a huge amount of traffic here in the Netherlands
going over 6to4, this because there is the newszilla6.xs4all.nl
box that has an open IPv6 NNTP (binary) service. People only need
to type 'ipv6 install' on their XP boxes and they can connect.
Thus I think one should not forget it even though it isn't totally
abuse proof and not easily traceable/debuggable, which is one of
the things I see as a big negative. It also doesn't cross NAT's
but proto-41 doesn't do that either unless the NAT-router is
configured correctly where possible.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iQBGBAERAgAQCRApqihSMz58IwUCQFEQwQAAJc4AnA/piNZwV1hZP2FIl6q6fHlg
1m0eAJ9lfZ25UUFYqAc5opI/fmRLzWFJ2A==
=T59V
-----END PGP SIGNATURE-----