Greg Daley wrote:
That's right. This gives the option to use LCoA with a CN if MN wants to. So, location privacy is an optional feature for MN to use, unlike with the NATs.
Actually, I think that MN can decide about its use of location privacy only if the network allows it. If the network doesn't allow it, in the advertised MAP options, then MN can not do anything and it will reveal its location to CN?:
"This can be done if the I or P flags are set in the MAP option.
Otherwise location privacy can not be provided in this manner. If
the V flag is set (in addition to the P or I flags), the mobile
node MUST tunnel all outgoing packets to the MAP."Specifically, if the V, I and P flags are not set in the MAP options (in other words network decides MN is not a VIP) then MN must reveal location information to CN.
I mean, I interpret it that way, but the intended meaning might be otherwise.
This is nice, because the MN might want to signal its location to some CNs for things like location-based services.
Yes, ok, but must be entirely MNs option, not network's? Or maybe this was already discussed.
Actually, it is possible to use a site-local address for LCoA, if all outbound packets are forced to go through the MAP. Since there
is a unique mapping for RCoA to the LCoA and tunneling of received
globally addressed packets you don't get the application interference of NAT though.
Of course, this will only be possible if we still have site-locals,
and may require some protocol tweaks on entering a MAP domain which only advertises site-locals.
Ok, here is were we diverge. Mobile IPv6 in itself provides a form of location privacy, in that if RO is not used, then all packets are tunneled back to HA, so CN doesn't know the actual location. Moreover, in Mobile IPv6 it would be much simpler if the concept of "site-locals" didn't exist.
In HMIPv6, the above text, kind of requires the site-locals concept to be in place in order to offer location privacy.
So, an idea is that the location privacy might be a problem, and that Mobile IPv6 might offer a site-local-free solution for that problem, and that HMIPv6 needs site locals in order to provide a solution to that problem.
Alex GBU
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
