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

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

FWIW RFC 3519 seems to do a reasonable job of accomplishing this
in the context of MIPv4.

Refreshing the NAT mapping and detecting when it might have been changed
can be done using ICMP echos to the tunnel server. When a failure is suspected
the host can redo the registeration protocol.

In genenral you can't detect the failure (mapping change) without sending
and receiving packets, but that is just a case of quick failure recovery
having a cost.

So I think the rocket science has already been invented in RFC 3519 - just need
to carry it to a different registration protocol.

   Erik