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

From: <[email-masked]>
Date: Wed, 26 Nov 2003 00:50:24 +0200

Pekka,

> -----Original Message-----
> From: ext Pekka Savola [mailto:[email-masked]]
> Sent: 25 November, 2003 16:52
> 
> Again, you assume that the user actually has to configure anything at 
> all.  That doesn't need to be the case, I think.  (At least, 
> I haven't 
> heard technical arguments why it couldn't be.)
> 
> 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. 

> Sounds like a circular argument without justification.

I think the justification is above.

> 
> > > That avoids getting the other features of ISATAP we don't 
> need here, 
> > > and provide a simpler architecture.
> > > 
> > > I do not believe this possibility has been analyzed well enough to
> > > understand it's possibilities (or potential flaws).
> > 
> > I think this thread and all the other threads seem to point to the
> > fact that we have to start dicussing solutions instead of scenarios.
> > We know the scenario now - we may need tunneling. If we could now
> > wrap up ISATAP in that way that it fulfills the requiremets given by
> > the scenarios/analysis. Right?
> 
> 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.

> 
> Of course, talking about solutions might be OK as well, but only if 
> one keeps the scenario in mind.

Yes, now we do have already two different scenarios/analysis pairs that call for some kind of solution. I think we should concentrate to see what the solution would be.

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

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

Cheers,

Jonne.

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 09:06:50 +0200 (EET)

On Wed, 26 Nov 2003 [email-masked] wrote:
> 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.

> I think the justification is above.

Nope, there are still some assumptions out there...
 
> 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.

> It is at least one possible tools for this job. Do you have others
> candidates (except for configured tunnels)?

Configured tunnels work just fine.
 
> 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.

---

From: Jasminko Mulahusic <[email-masked]>
Date: Wed, 26 Nov 2003 10:11:34 +0100

pekka,

> the IPv4 address of the tunnel endpoint somehow.  As the tunnel

it must be completely transparent to the user. otherwise, it is a 
non-starter. the normal user doesn't care about such things.

jasminko

p.s. instead of endlessly repeating same arguments over and over, 
shouldn't we write a requirements document for UE tunneling, or something?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 11:34:58 +0200 (EET)

> non-starter. the normal user doesn't care about such things.

It can be completely transparent, yes.

> shouldn't we write a requirements document for UE tunneling, or something?

That would be great, as it would probably help in understanding the
scenario (and it's requirements) better.  If you're volunteering....  
:-)

This seemed to have a good impact on the unmanaged tunneling 
discussion, why not here as well, then? :-)

(The document probably wouldn't even have to be published as RFC, just 
circulated as a couple of revisions of an I-D, to facilitate 
discussion..)