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

[Pekka Savola <pekkas@netcore.fi>]

Thanks for putting the document together.

Highest order bit first:

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

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

On Thu, 27 Nov 2003, Jasminko Mulahusic wrote:
> > [[ whether or not now is the appropriate time to call for WG consensus 
> > 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.

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?


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