[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Alain,

  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. 

  Thank you for creating this requirements document and I hope
that other service providers and/or mobile network operators
can comment on the requirements as well.  





 
Original Message:
-----------------
From: Alain Durand Alain.Durand@Sun.COM
Date: Thu, 06 May 2004 14:49:06 -0700
To: Erik.Nordmark@Sun.COM, v6ops@ops.ietf.org
Subject: Re: Tunnel Set-up requirements: Issue to be resolved



On May 6, 2004, at 2:33 PM, Erik Nordmark wrote:

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

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


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

unspecified at this time.

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

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

Question: are we not already in solution space?

	- Alain.