stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 17 Mar 2004, Erik Nordmark wrote:
> > 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.

Sure.  There is no dispute of that.

But MIPv4 has assumptions which I do not agree with.  It assumes you 
have an authenticated association with the Home Agent.  Here, the 
respective element is the tunnel server.

I do not want to require such authenticated association -- which is 
required if you want to have a stable v6 prefix which is independent 
of v4 address [/port].  I think this is a useful additional mechanism 
which can be used when authentication is available, but when it isn't 
-- there is no use requiring it!

In that case, all you can do is somehow tie the prefix to an 
address[/port] or some magic token transmitted in the packet.  But 
unless it's carried in every packet, this is something that has to be 
remembered by the server.

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

Agree with all of that -- and we already have mechanisms on the table 
doing something like this.

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

Yep -- or something like that.  I guess 
draft-thubert-nemo-ipv4-traversal-01 is already doing that in v6 
context; but again, that builds on top of MIP[v4].

I think the critical point here is whether we require this
registration protocol / user authentication in the mechanism, or
whether it's an optional step.  IMHO, we must not require that.

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