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

From: the otter <[email-masked]>
Date: Mon, 1 Nov 2004 22:45:23 +0000

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:

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

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.

Best Regards,
N

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Tue, 02 Nov 2004 14:18:03 +0200

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

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

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: the otter <[email-masked]>
Date: Wed, 3 Nov 2004 09:25:56 +0000

Hi,
The reasons an operator may make use of IP address to account mapping
at a service is to:
- provide automatic sign-on to a service (-it would be annoying to
have to insert username/password on a handset everytime you use WAP or MMS)
- determine from the IP address something about the users settings (-
for example, have they requested Location Based Services to be turned
off)
- event based PUSH (-for example, a messaging server looks up user
account, obtains IP address and pushes email to terminal)

If we cannot assume any significance about the IPv6 address then these
functions must be achieved at a different layer. At the moment in
IPv4, there exists a consistent way of determining User ID from IP
address.

Sure, these solutions only exist in the operator networks (and
directly connected 3rd Party) but this is still important. The IP
address has a lot of significance within the internal network of the
operator. And I mean just the Gi network, forget all the others. With
regard transition methods, these play a significant part in the large
international operator's network, when you consider these are actually
a number of disjoint national operators' access-networks trying to
access common services.

It would be neat to continue the identity in the v6 domain. The
solution would just need to be deterministic. I purposely didn't want
to look at the solutions, and stick to goals, but we may think about:
1) a second IPv6 RADIUS/DHCP server for DHCP to tunnels which is
interrogated in the IPv6 domain (is this against the zero config goals?); or
2) use a PREFIX function (c.f. NAT-PT 96bit PREFIX) where IPv4 address
at source (and in the RADIUS DB) can be determined from the incoming
IPv6 address (perhaps security/fraud issues?)

Again, if this is not going to feature in this draft, can we state this.

Note on standards - I cannot see the 3GPP standardising the Gi in
anyway. However barring IMS this is where all the IP Services reside.
So IMHO I think the standards will not have all the answers, and
looking at what happens in practice is beneficial. But Is the
motivation for this draft IMS alone? I interpret "3GPP" to
mean this draft is applicable to mobile operator services generally,
not IMS alone.

Thanks & Regards,

On Tue, 02 Nov 2004 14:18:03 +0200, Soininen Jonne