Re: Tunnel Set-up requirements: Issue to be resolved

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 6 May 2004, Alain Durand wrote:
> > In the latter case you can the ISP that supports registered tunnels can
> > have a web site where the user types in the credentials it uses
> > with the ISP (userid? contract number? whatever)
> > and as a result gets some registration key/tag which will be used
> > in the actual tunnel setup protocol.
> 
> That is definitively one way of doing it.
> 
> This could be a way to unify the two modes: if you are unregistered,
> you provide an empty key and the system could (if desired by the
> ISP) allocate you one so you would be able to retrieve the same
> address next time by presenting that key.

[this may partially be in solution space, but probably useful in any 
case as I think it makes us able to understand the 
scenarios/requirements better..]

.. or the user could just generate some kind of hash himself.

The trivial part of getting the same address/prefix is to base the v6 
address/prefix on the v4 address/[port], so that if that does not 
change, your address is constant.

That has a good side that if the ISP implements ingress filtering, you 
don't need v4 return routability for the signalling exchange.  This 
could be the simplest model.

An extension could be using some hash or pseudo-key as Alain
mentioned; if both stored the key, stability might be possible even
without explicit registration.  You'll need to have v4 return
routability check here though, adding at least one round-trip.

It's worth considering what are the differences with this kind of
non-registered pseudo-keys to normal AAA methods.  I'd argue that the
ISP is less reluctant to save these pseudo-keys: not wanting to store
them in an external database.  It might be that they are only stored
in the memory of the tunnel server, or possibly in the stable storage
of the tunnel server (as e.g. DHCP spec requires).  If stable storage 
is not used, the sessions are lost at restart.

Now, if we assume that stable storage would be recommended, there is
actually very little difference except that the really registered
users can be ensured to get a static address/prefix delegation, and
possibly custom configuration based on the AAA databases.

So, this seems to lead to a conclusion that a single common protocol
would be sufficient as long as it may fill both the
non-registered/registered requirements.

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