Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Tue, 2 Nov 2004 13:39:43 +0100

Hi,

> Hi Karen,
> Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
> would like to ask about push functionality and user identity within
> the 3GPP network.
> PUSH relates to tunnel duration/accessibility:
> 
> >6.7. Tunnel Link Sustainability
> >
> >  The tunnel link established in between a host deploying Zero-
> >  Configuration Tunneling and an associated Tunnel Server should be
> >  expected to remain in administrative active state for the 
> lifetime of
> >  the IPv6 address provided to the host.
> >
> >  The tunnel protocol must not mandate keep-alive messages to be
> >  transmitted by the host simply in order to sustain tunnel link
> >  connectivity.
> 
> Is it intended that the tunnel remain up while the UE has an active
> PDP context?

Yes and no.

It is intended that the tunnel remains active for 
the lifetime of the address allocated. The latter which could be infinity,
but also a smaller time span, e.g. one day, one week, depending on operator policy.

The terminal would have to refresh the address/tunnel once the lifetime
expires.

(In the case of unlimited/infinite address lifetime, the answer to your question is yes.)

> In an "always-on" network there may be services that perform PUSH
> (i.e. server initiated) functions - is it a requirement to 
> allow IP PUSH from
> the IPv6 domain toward the client?

It is not intended to allow server initiated set-up of tunnels.

It is intended to support the run of various IMS services over the tunnels, though not 
services which rely on PDP context based IMS and GGSN interworking, e.g.
SBLP mechanisms over the Go interface. 

Services based on server initiated PDP context activation for media traffic will
not be supported.

> I would suggest that this be a requirement or it will limit the
> service use cases for this solution.
> The PUSH functionality leads on to the User Identity issue which
> relates mainly to this section:
> 
> >6.6. Address Assignment
> >
> >  The tunnel protocol must allow for the assignment of at least one
> >  globally routable (/128) IPv6 unicast address to use for tunnelled
> >  IPv6 connectivity over the link provided by the Zero-Configuration
> >  Tunneling mechanism.
> 
> 3GPP networks may utilise a database that combines authentication and
> DHCP functions (RADIUS + database). This ensures there is an
> authoritative system that can provide "User Identity", that 
> is to say link
> IP address to User Account. A service can then query the data base to
> resolve an IP address to a User account or vice versa. Is the IPv6
> address assignment for the tunnel client compatible with this model?
> If this is not provided then some types of services in the IPv6 domain
> will not work. May I suggest that maintaining user ID mapping via IP
> address be a goal.
> If these are not to be goals then perhaps this could be stated.
> 

The intend was that where ID and Ipv6 address mapping must be established, 
e.g. IMS registration ?, this must be done by the user.

> IMHO the issue I see with leaving these out is the transition 
> mechanism
> becomes a solution for only the most basic of "web" type services.
> While this makes the solution simple, it removes the motivation for
> IPv6 within the 3GPP network. It is important to at least match or
> mimic the functionality available in the IPv4 domain.
> 

Tunnelling in 3GPP is not intended to provide full emulation of 
the native IPv4 or native IPv6 services, since that would basically require
full dual IP support in all related 3GPP signalling interfaces.

BR, Karen

> Best Regards,
> N

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Nov 2004 19:15:14 +0200 (EET)

> full dual IP support in all related 3GPP signalling interfaces.

Without knowing the details here, I'll have to personally join in the 
first mentioned sentiment: as far as I see it, the UE tunneling offers 
the operators and UE vendors the chance to pilot IPv6 application 
deployments etc. without requiring immediate upgrades in the 3GPP 
network.

Unless the tunneling can provide a reasonable means to test out at 
least some potential applications that could be realized with IPv6, 
then its applicability might be a bit questionable.

Remember, IPv6 isn't all that inrestesting just because of a dancing 
turtle on a web page ;-).  It needs to provide a way to deploy nice 
new applications.  Even though full functions of IPv6 were not yet 
realized with the tentative tunneling solution, IMHO it should provide 
at least basic means to deploy some novel IPv6 applications (e.g., 
relativng to peer-to-peer).

-- 
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: the otter <[email-masked]>
Date: Tue, 2 Nov 2004 23:35:26 +0000

You have answered the PUSH question. If the tunnel remains up as long
as the terminal has an IP address then that is good. The server can
assume the tunnel is up if there is a valid IP to contact.

Thanks & Regards,