On Fri, 2004-05-07 at 06:24, Alain Durand wrote:
> Thank you Carl, this is exactly the kind of feedback
> I'm looking for.
>
>
> On May 6, 2004, at 4:28 PM, Carl Williams wrote:
> > Some of the scenarios we are looking at require that
> > we be able to keep the same IPv6 address for both registered
> > and non-registered modes for each tunnel setup - this of course
> > should be a choice.
> >
> > I don't know if this is more of an implementation issue or not
> > but for registered mode I don't want to require the end customer to
> > manually enter settings via some web page every time
> > they initiate a new tunnel setup. For example, I want to require
> > registration but in a way that is automatic and transparent to the
> > user.
>
> Would a one time registration through a web page be ok?
> There could be some kind of token/key exchange happening there
> and that would be reuse automatically every time the user
> sets up the tunnel.
IMHO a protocol doing this MUST not rely on an external mechanism.
The problem is very easy to solve:
- user start tool(tm)
- tool discovers the closest tunnel setup protocol (*)
- tool connects to tunnel setup protocol
- setup server notifies client that it can handle:
* anonymous users
* pre-registered users
* allowing new registrations
all optional depending on the ISP/server deployers wishes.
A tunnel setup protocol MUST be able to do all three.
Then the tool proceeds to either:
[anonymous user]
- user claims it wants to be anonymous and presents a
'cookie' if it has that from a previous session
- setup server either validates the cookie and finds the old
IPv6 prefix(es) the user was using or returns a new one.
the client MUST be able handle to handle it and a server
MAY return a new prefix
- setup server returns prefix information, cookie, endpoint info,
etc....
[registered user, aka one with an account]
* the account can be obtained out-of-bound
(website, phone, preexisting agreement or using below regmethod)
- tool asks for possible authentication methods (MD5/SHA/whatever)
- tool asks user for authentication tokens and sends to server
- server authenticates user and:
- setup server returns prefix information, endpoint info, etc....
[registered user, but no account yet]
- tool tries asks the server how to register
- server responds with either:
* website + http://www.example.com/register/
- Tool either presents the user that it can register
through a website and if it wants to do that.
This site could also point to information how to
do it in different ways. If the user answers yes
to the question then the user is shown the url
either by starting the webbrowser directly or just text.
* direct [en|nl|de|...] (the languages supported)
- Tool asks if the user wants to register using the tool
when no, return to start.
- Tool asks server for 'registration information' in 'en'
or 'nl' or whatever depending on the language the user
wants
- Server returns "language not available" or:
<text name="name" short="Name">Your full name (first +
last name)</text>
<text name="address" short="Address">The address where
you live</text>
<text>.....</text>
* but this is implementation*
As registration through this protocol should be optional when
it is implemented it SHOULD only use the 'website' method, the
'direct' method is quite complicated and basically also presents
the same forms as the website.... (maybe better only do website?)
(*) = I split "Tunnel Setup" & "Discovery" as the discovery should be
done seperatly IMHO and could be as simple as DNS lookups but could also
do more difficult tricks. The Discovery should only return a pointer to
the Tunnel Setup Server.
(and yes... all this is already possible using the configuration
protocol in use by SixXS, waiting for this thing to settle ;)
Greets,
Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part