[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello,

(Chair hat on)
It would be nice if you could identify yourself. It is not nice to
discuss on this kind of list with anonymous people.
(Chair hat off)

Below I have put some comments:
On Tue, 2004-11-02 at 00:45, ext the otter wrote:
> 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?
> 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?
> 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:
> 

I think the requirement is that the IPv6 address supports "always-on".
Thus, keeping the IPv6 address relatively stable - at least the IPv6
address has to be as table as the IPv4 address.
In addition, I don't think there are any restrictions on what kind of
protocols/services/applications are used over the tunnel.

> >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 tunneled
> >  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 3GPP operator may choose to use this kind of information in their
networks. However, usage of these mechanisms are to my understanding
optional in the 3GPP specifications (29.061). I don't know anyways what
would be the use case for doing this kind of IP address to MSISDN
mapping.

It may be more difficult to map the tunneled IPv6 address to the MSISDN
of the user, but most probably doable.

If there is a need to have _exactly_ the same functionality as in native
IPv4, it is better to use native IPv6 over GPRS. 
> 
> 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.

The tunneling mechanism has to support stable addressing - that's right.
That is absolutely necessary. However, I don't understand this IP
address to MSISDN mapping requirement as that information is not
available outside the operators network anyways.

Cheers,

Jonne.

> 
> Best Regards,
> N
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com