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

From: Soliman Hesham <[email-masked]>
Date: Wed, 26 Nov 2003 05:21:59 -0500

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

=> This alternative is a non starter. This knowledge would not
exist unless static addresses are used, and they're not used
at all.

   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.  

=> I'd rather not make this assumption either. 

It seems to me that we're going around trying to avoid 
using an existing, well understood, implemented in products,
proposal (ISATAP), why? The people that implemented it in
products are happy with it. 

It's time to make a concensus call on this issue. Frankly,
this discussion has gone for a long time and no one is
moving so let's get a feel for what the WG thinks.

Hesham

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 12:41:49 +0200 (EET)

(chair hat=on)
Btw, please try to trim the text being quoted -- to make it easier to 
read -- and remove any unnecessary text (e.g. at the end).
 (chair hat=off)

> exist unless static addresses are used, and they're not used

This cannot be true.  The home operator must know the address of the 
UE, if for no other reason, but because it's tunneled back from the 
foreign network.  

In the traditional ISP networks, the knowledge is out there, even for
dynamic prefixes (e.g. in TACACS/RADIUS logs, etc.).  I fail to see
how that would be different for 3GPP?  Please elaborate!

> => I'd rather not make this assumption either. 

Well, some rather might! :-)  Can you provide some technical 
arguments?

> products are happy with it. 

This is not true.  I know for sure that it is not well understood (I'm
not sure how well I can argue about the others, so I don't respond to
that point now).  The previous ISATAP advocate, for example, thought
it to be a simple host-to-router tunneling mechanism without direct
connectivity between hosts in the ISATAP domain.  That feature had
been included for at least a couple of years or so..

> moving so let's get a feel for what the WG thinks.

The discussion has gone for long time, that's for sure, but I believe
only until recently we've been able to tease apart the assumptions
different people have about the requirements and the scenario in
question.  People have been talking past each other, with certain
assumptions in mind (e.g. about configuration required in configured
tunneling).  I believe there is progress to be made, if especially
folks who have taken ISATAP as their "one true solution" are willing
to keep the eyes open.