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 09:56:51 -0500

> > But this is a problem. The new solution has to be specified and
 > > implemented. This is not a trivial process. The boxes (and most
 > > probably are) of different vendors and implementing something like
 > > this and integrating it to the current networks is not a trivial
 > > task.
 > 
 > Which implemenation are you refering to?  You probably wouldn't need 
 > to touch 3GPP systems; more probably, all you'd have to is to modify 
 > the tunnel router (which could be just a PC, a regular IPv6 
 > router, or 
 > whatever).

=> A PC ??? Come on... The routers used to connect the 
GGSN to are BIG! 3GPP or not, a core router used in a telecommunications
network is required to be reliable. Now, you said you did
product development before, so think about how long it 
takes to specify a solution on a product level, order 
a project, allocate resources, develop it, test it then
release it and support it. Think about that and then
try to convince someone who already developed another
solution to remove it and adopt this new idea that you
propose (which we certainly don't understand fully yet). 

A much easier process is to ask for WG concensus on this
issue and follow whatever the WG wants to do.

 > 
 > Right.  So, the users, even when roaming, get the IP address 
 > from the 
 > home GGSN.  So the addresses used by the users are known at least by 
 > the home GGSN, and probably also some other accounting/billing 
 > databases etc.
 > 
 > If one doesn't provide the users a static IPv4 address, it 
 > may not be 
 > a requirement to provide a static IPv6 prefix (especially if 
 > the GGSNs 
 > etc. don't support v6 yet) either, right?
 > 
 > In such a case, it'd probably be enough to just give everyone a v6 
 > prefix either sequentially or depending on the v4 address, 
 > e.g. using 
 > the STEP "ad-hoc" mechanism.  
 > 
 > With that kind of "trick", the tunnel router would not have 
 > to get the
 > user/IP-address/v6-prefix information from anywhere, but the tunnels
 > would function as if they were configured tunnels, and the UE's would
 > not even know the tunnel router is doing some "magic tricks" to
 > generate configured tunnels.

=> Pekka, I hope you realise how many assumptions you are making
and assuming that this is _the_ way it should be. Again, is all this
worth it? I don't think so. 

It'd be really great if there is a concensus call on this issue
so that we can decide whether we _have_ to look at other 
options or simply take what we have now. Why not ask the WG?

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 17:13:21 +0200 (EET)

On Wed, 26 Nov 2003, Soliman Hesham wrote:
> => A PC ??? Come on... The routers used to connect the GGSN to are
> BIG! 3GPP or not, a core router used in a telecommunications network
> is required to be reliable.

If the number of customers was high, the operator would deploy native,
minial IPv6 support.  The current IPv6 usage statistics suggest
otherwise. If it the number of customers is low, I would be rather
doubtful that the number of IPv6 users would be counted e.g. in
hundreds of thousands in the first phases where tunneling from the UE
is a reasonable solution.

But in any case, whether the router is a PC or something else is
rather irrelevant; the point is that it's probably some standard ISP
industry equipment without a 3GPP "price added" tag.

> Now, you said you did product development before, so think about how
> long it takes to specify a solution on a product level, order a
> project, allocate resources, develop it, test it then release it and
> support it. Think about that and then try to convince someone who
> already developed another solution to remove it and adopt this new
> idea that you propose (which we certainly don't understand fully
> yet).

Are we asking anyone to remove anything?  Is it the IETF's fault if 
someone wastes resources in a dead-end solution?  In any case, 
resources needed for a "simple" product, like the one I described, 
would be rather minimal.

(I agree that we probably don't understand the idea I proposed fully,
but because the idea itself is simple, and the method operates with
very strict premises (compared to e.g. ISATAP), I suspect it will be
relatively easy to understand it in a very short order.)

[[ whether or not now is the appropriate time to call for WG consensus 
on which way to go remains to be considered ]]

-- 
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: Jasminko Mulahusic <[email-masked]>
Date: Thu, 27 Nov 2003 17:47:22 +0100

> on which way to go remains to be considered ]]

and here are the requirements that have been expressed on this list so far:

http://www.imslab.net/draft-mulahusic-ue-tunneling-reqs-00.txt

if we have an existing mechanism that can fulfil those, let's recommend 
it and move on.

if we don't have one let's say so and move on.

i don't see where we'll get by holding up this spec because of this 
issue? after all, the spec states clearly that the native v6 is the best 
way to go.

jasminko

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Nov 2003 19:36:45 +0200 (EET)

Thanks for putting the document together.

Highest order bit first:

> issue? after all, the spec states clearly that the native v6 is the 
> best way to go.

.. I certainly don't require holding the spec on this -- if the text
is generic enough not to presuppose solutions, that would probably be
fine by me..

> if we don't have one let's say so and move on.

some quick comments:

==> the requirement numbers go back to R3 after R5..

      R2: Not requiring modification of the existing equipment

         The tunneling mechanism should not require that the existing
         network elements be upgraded or modified. I.e., additional and
         new nodes might be required to be placed somewhere in the
         network, but the assumption that the existing ones can be
         upgraded or modified to support new features, cannot and should
         not be made.

==> you should be more specific about that.  You refer to 3GPP network 
equipment, correct?  UE's would still be a fair game, naturally?

         The tunneling mechanism should work regardless if the client
         has a dynamic address, that can change over time, or a static
         address. It can not be assumed that the DHCP has been used when
         the client was assigned the dynamic address.

==> why can't you assume DHCP w/ dynamic address?  Maybe using some 3GPP 
variant here, or what? spell it out..

      R3: User may be located behind a NAT

         The UE might have been assigned an private address. It cannot
         be assumed that the user can control the NAT. Neither can it be
         assumed that any other part involved in the tunnel set up
         procedure will be able to control the NAT.

==> this should be clearer whether you require that the mechanism must be 
able to operate using private IPv4 addresses (there being a NAT *somewhere*),
or whether the mechanism must also work when there is a NAT box between 
the UE and the 3GPP home operator's equipment (i.e., ISATAP wouldn't work either).
May need serious reword.

      R3: Host-to-host vs. client-server communication

         The network operator should be able to decide wheater to allow
         direct host-to-host communication between UEs or wheather all
         packets will have to traverse the tunnel end-point.

==> this has to be reworded.  You haven't even established a requirement
for host-to-host tunneling, right?  If that's done, on the other hand, 
there may be a requirement to be able to control it. 
("client-server" -> "host-to-router" but that's inaccurate as well, because
the UE could very well be a router)

==> additional requirements, maybe:
 - should one be able to have UE act as a router/bridge, 
to connect more nodes; i.e. should more than just one address be
assigned to the UE.
 - you don't mention things like "simplicity", "security", as 
requirements at all.  These are about number ones in my book.  
These are rather complex requirements, though, because they operate in
so many layers (simplicity specification-wise, simplicity implementation-wise,
simplicity operationally, etc.).
 - you do not mention whether the user should be able to get a static v6
address if its ipv4 address is dynamic.  Maybe this is not a requirement 
(I don't see it s one myself) -- maybe there should be a non-requirements 
section?