[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Stranger ...!(
>
> 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.
>
With private IPv6 addresses being generated by the UE in the IPv6 domain there will be
no direct way to correlate IPv6 addresses with a User ID - that's why for example
an IMS registration must be performed anew when the UE generates a new 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.
>
Yes.
What you suggest above to me sounds very much like tunnel server
registration - at least if you are speaking about service registration only,
I may not understand how DHCP comes into play
> 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.
>
Personally, my motivation has been driven by the termed (at least) Ipv6 only IMS services
(or Ipv6-only IMS operator networks) and the explicit need for a transition solution for these,
but that's not to say that this should be the only need taken care of by zeroconf tunnelling.
BR, Karen
> 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
> >
>