RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 26 Nov 2003 Jonne.Soininen@nokia.com wrote:
> > Who said that the user has to configure anything itself?  The user
> > receives a magical SMS message from his operator, the tunnel gets
> > automatically activated, and we're done?
> > 
> > Or does the user manually configure the APN as well, based on the SMS 
> > messages it sends/receives?
> 
> Look, the IP address is dynamic and usually every PDP context
> activation means a new IP address. Then there would have to be a
> mechanism for the network to guess that the user would like to use
> IPv6 on this particular PDP Context and send an SMS to configure the
> tunnel. The configuration would have to be accepted by the user, and
> so on. This would not work.

As for the client side configuration...

No, this does not seem to be the case.  The user just has to find out
the IPv4 address of the tunnel endpoint somehow.  As the tunnel
endpoint is located at its local 3GPP operator, it is fairly static,
and can even be routed somewhere else in the IGP if it moves.  Manual
one-time config (need to be redone only if you switch your home
operator) is sufficient, as well as doing it with an SMS [as one-time
config], looking it up from the DNS, or something else.

So there clearly seems to be some disconnect here, maybe some 
assumptions which haven't been spelled out.
 
Now, the network side configuration is slightly trickier..

Basically the options seem to be two-fold: either the home operator
knows which users are potential IPv6 users in advance (and can
associate "user-wants-ipv6" and the user information, and always when
the customer performs the PDP context activation, update the tunnel
end-point information), or that all the users are potential users
(implying the tunnel end-point should be updated based on the first
packet sent over the tunnel).  The former requires a bit of ops &
management glue to tie these two together.  The latter requires a
minor modification to proto-41 decapsulation code at the 3GPP
operator's tunnel router, but basically that's it.  (This is
elaborated a bit in the STEP draft already mentioned.)  There are 
probably other ways to tackle this problem as well.

The point is, the client configuration seems close to trivial.  The
network configuration is slightly trickier, but should be manageable.

> > Sounds like a circular argument without justification.
> 
> I think the justification is above.

Nope, there are still some assumptions out there...
 
> > We know that there is a scenario where tunneling is desirable in
> > certain cases, yes.  However, I'm not sure if we know the requirements
> > of the scenario, or the scenario itself, well enough yet (see the
> > points above why exactly configuring is bad, what exactly would need
> > to be configured, etc.).
> 
> Configuration would not work. I think this has been explained above
> and in other mails sent on this list. Trust me on this - configuring
> the tunnels can be at the most a very marginal case.

Based on the misunderstandings as shown above, I do not believe 
different people have a right mindset when they talk about 
"configuration".  I'm not sure if folks realize that it's really not 
so complicated.  See above.

> > I don't know what you mean by the ISATAP reference.  Clearly, we could
> > take it, and apply it in this specific scenario, and I think it would
> > work, at least to some definition of "work".  That doesn't mean it's
> > the right thing to do, of course. Is it the *right* tool for 
> > the job?  
> 
> It is at least one possible tools for this job. Do you have others
> candidates (except for configured tunnels)?

Configured tunnels work just fine.
 
> > For example, a proof of concept procedure was introduced in
> > draft-savola-v6ops-conftun-setup-01.txt; it would probably solve the
> > problem in a much simpler and easier way; it's basically just
> > expanding the couple of bullet points above about configured tunneling
> > set-up methods.  In the case of 3GPP, only proto-41 would be necessary
> > -- basically just configured tunneling at the UE, and some tricks at
> > the 3GPP operator side, depending on the mode in which it wishes to
> > operate.
> 
> Sorry, I read the document really, really quickly. It is an
> interesting document and we should discuss the different solutions
> if we decide to go to the solutions space (not wearing chair hat-I
> think it would be time). Of course, we have to consider all
> solutions.

I'm not sure if it makes sense to look into solutions too much yet
(but soon would be time for 3GPP I guess), as it clearly seems that 
the scenario is not spelled out clearly enough.

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