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

From: Alain Durand <[email-masked]>
Date: Tue, 04 May 2004 18:25:29 -0700

There is one major issue that need to be resolved in this document,
and I'd like to get feedback on.

The original draft talked about two modes, authenticated and non 
authenticated.
This was not a perfect terminology, and we now use registered vs non 
registered.

As Pekka's explained, there are three level of requirements,
the ones on the protocol, the ones on the implementations
of the protocol and the ones on its deployment.

With regard to the support of those 2 modes, this is what I would like 
to suggest:

Non registered mode:
	- MUST be supported by the protocol to be designed
	- RECOMMENDED to be implemented on client and servers/brokers
	- MAY be turned off by ISP

Registered mode:
	- MUST be supported by the protocol
	- RECOMMENDED to be implemented on clients and servers/brokers
	- MAY be turned on by ISP
	- The registered part of the protocol SHOULD not be too different from 
the non registered one,
	   so as to minimize code difference between the two modes

The difference is that the Non registered mode becomes the default mode 
of operation,
which can certainly be a valid option when the ISP has a enough control 
on IPv4 access.
(See Erik Nordmark's email on the matter)

The choice of the mode of operation (registered vs non registered) 
would then be
completely controlled by the ISP.

Would this be an acceptable solution?

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 May 2004 10:24:54 +0200

Alain, I essentially agree, but if we are writing a technical
spec rather than instructions to operators,
I suggest a slightly different phrasing...

>     - RECOMMENDED to be implemented on client and servers/brokers
*     - implementation SHOULD turn it on be default
*     - implementation MUST allow it to be turned off
>     - RECOMMENDED to be implemented on clients and servers/brokers
*     - implementation SHOULD turn it off by default
*     - implementation MUST allow it to be turned on
>     - The registered part of the protocol SHOULD not be too different 
> from the non registered one,

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 May 2004 14:33:52 -0700 (PDT)

> This was not a perfect terminology, and we now use registered vs non 

Question: in the non-registered mode is there an ability to have a mechanism
by which the same host gets the same IPv6 address each time it sets up
a tunnel?

> 	   so as to minimize code difference between the two modes

Are we assuming that the registration is done as part of the protocol
itself, or are we assuming that the registration is external to the protocol?
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.

  Erik

---

From: Alain Durand <[email-masked]>
Date: Thu, 06 May 2004 14:49:06 -0700

> by which the same host gets the same IPv6 address each time it sets up

Not today. Do you want to require such a mechanism?

> itself, or are we assuming that the registration is external to the 

unspecified at this time.

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

In the registered mode, you provide the key that was pre-assigned to 
you.

Question: are we not already in solution space?

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 May 2004 15:50:22 -0700 (PDT)

> Not today. Do you want to require such a mechanism?

If we want the non-registered mode to be the default, I think it
makes sense to make this mode provide realtively stable addresses.
Thus having the protocol being able to, at the ISPs choice, provide 
stable addresses as well as prefix delegation makes sense to me.

> Question: are we not already in solution space?

Don't think so, but there isn't a hard boundary between requirements and
solutions.

The reason I was asking is because we are talking about requirements
being placed on the protocol without having defined what
the protocol does; whether the protocol includes the registration
exchange or whether the protocol can operate based on a registration exchange
done with some other mechanism.

For example, if the protocols on which we are placing requirements
includes the registration exchange, then I think we need to have
requirements about how flexible the registration exchange needs to be
since different ISPs might use different pieces of information
and different existing mechanisms to identify their customers.

 Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 May 2004 07:41:22 +0300 (EEST)

On Thu, 6 May 2004, Alain Durand wrote:
> 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