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

[the otter <2the.otter@gmail.com>]

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
(Nokia-NET/Helsinki) <jonne.soininen@nokia.com> wrote:
> 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
>