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

["Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>]

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
>