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

RE: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]



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

Pekka Savola wrote:

> On Wed, 17 Mar 2004, Florent Parent wrote:
> > No one is trying to "outsmart" ISPs. To add to Erik comment: whether it's 
> > the nat mapping or whatever event occurs that changes your IPv4 
> > address/port, the point is that TB + nat traversal can guarantee that the 
> > user will have a stable IPv6 address/prefix. The user IPv6 address is tied 
> > with the user identification, not to its (temporary) IPv4 address (and port 
> > number).  This feature (stable IPv6 address/prefix) is an important benefit 
> > to the end-users, IMHO.
> 
> There are tradeoffs to consider here, of course.. e.g.:
> 
>  - signalling overhead required when tying the v6 prefix to something 
> else than IPv4 address, port or something like that.
>
>  - user authentication overhead and management complexity.

What the solution I propose here and am already using is that
we seperate the above into two sections:

 - Authorisation + Tunnel Configuration & Setup
 - Notifying to the Tunnel _Server_ of the current IP.

The first part is currently handled by a non-drafted, but
protocol as described on http://www.sixxs.net/tools/configservice/
We are working to moving this to TSP which should become
the defacto standard in tunnel setup and configuration.

The second part can and is being solved using draft-massar-v6ops-heartbeat-00
for proto-41 tunnels. Though this can also be applied to the
IPv6-over-UDP protocol which Hexago is proposing in their
TSP client, though the latter could better support the
same kind of authentication the heartbeat protocol uses
inside the UDP packet itself.

Signalling overhead is about 200 bytes every heartbeat including
IPv4 and UDP headers. This only has an advantage IMHO as it does
have quite a good means of authentication, thus avoids spoofing.

>  - the recovery time; i.e., how long does it take to detect something
> bad has happened?  How long does it take to recover from this
> incident?  Note that unless this is very quick, the result may
> actually be pretty close to IPv6 address changing (if e.g. the TCP
> connections get broken in the meantime) -- and all we might not
> actually gain much in the "ISP is changing the address on the fly"  
> -case.

Changing of IP's can be notified immediatly to the POP using
the heartbeat protocol. Typically the heartbeat is set to be
sent every 60 seconds and/or when the client detects an IP change.
OS's like Windows have API interfaces for this, unices mostly
have to rely on the dhcpcd notifying the client.

Greets,
 Jeroen

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

iQBGBAERAgAQCRApqihSMz58IwUCQFiMWwAAMicAn2lK6DQTC7DqFHQDcrxmOhT0
maxkAJ0TwFeYuYUP3AVrfO+t6jhZnJL1Sg==
=hTFs
-----END PGP SIGNATURE-----