Hi Charlie,
This response is not as IETFer but as member of implementation team
working with customers to deploy Mobile IP and with GPRS GSM for now and
eventually ALL-IP and ALL Mobile IP for IPv4 and IPv6 on our platforms.
>During the last IETF, there was a discussion about when a mobile node
>should use its care-of address for communications. One possible answer
>is "never". Mobile IPv6 was designed to avoid extra signaling overhead
>that might result from the use of the home address. However, if the
>mobile node can make the following assertions:
I think "never" is too restrictive a concept pretty much universally
except for death, but definitely invalid for protocol optimizations.
>1. No mobility events will occur
>2. The other endpoint does not need the mobile node's DNS name
>3. The other endpoint is not concerned with the mobile node's
> home address
OK I will take these as assumptions.
>or, alternatively, if (3), and the mobile node does not expect to
>receive any packets from the other endpoint, then it is likely to
>be safe for the mobile node to use its care-of address. These
>considerations, by the way, are the same as for IPv4. Another
>interesting factor is what might be meant by (1). If the layer-2
>protocols handle local mobility over a wide enough range, then
>there is a corresponding relaxation on how rarely the conditions
>might be satisfied.
If your last sentence is TRUE which is TRUE for deployment now as best I
can tell the relaxation is clearly OK. But to sway those to support
this in the standards arena you will need other bullets too once (1) may
in fact occur because of ALL Mobile IP, not that I think we do, I think we
should just do this now and it makes sense but I am getting used to
hanging around and working on stuff just to do what I knew we would do
two years before we could actually do it. (yes it is confusing and so is
the sentence). So we hopefully can proceeed to work this idea and beat it
until its a dead horse, make it PS, and then the benefit can be practiced.
Another issue is that roaming Cell Phones and PDAs and other handhelds
will not be the only Mobile Nodes. A LapTop will roam but most likely
will be stationary for longer period of time satisfying (1). And once
communications is established (2) and (3) are pretty safe bets too.
>I claim that it is up to the application to make these determinations,
>or else it is up to the context in which the user invokes the
>applications. Sometimes the same application may, or may not, have
>requirements for smooth network connectivity in the face of mobility
>events. Anything that is considered a "session" is an example of
>something that is likely to fail to satisfy the abovementioned
>conditions.
I suggest its a system parameter on the MN as I hope most
applications do not have to know the inner workings of Mobile IP.
It can be a system parameter that can support individual, group, or
system wide application granularity. I don't think it should be an API
or 2 Year IETF effort to discuss it and define it and build a camel
instead of a horse. What has to be done is a simple statement to permit
the behavior as extension to Mobile IPv4 and IPv6. Clearly this needs
to be defended and discussed, but just the permission of it, and the market
will figure out how to use it. thank you.
>During the IPng meeting, there was a proposal to create a mailing
>list for discussion of these issues. If the mailing list is already
>in operation, I'd like to join up. I hope this message will be
>considered relevant.
Well me or someone on my team would like to join too when its known if it
exists or will exist.
>This whole problem is merely a particular example of a much larger
>issue regarding the association of application invocation context
>and IP addressability. For instance, if a user wishes to associate
>various "identities" to various IP addresses, then the user might
>try to get applications to select IP source addresses that appropriately
>express the desired identity to the other endpoint of the application's
>>communication. From this point, we "could" devolve into more extended
>discussion about the dual role of the IP(v6) address as a way to
>encode both an identity and a route. I do not propose to regurgitate
>that entire discussion again, but I do note that it is highly relevant.
I suggest we don't go there. From past history we will just go in
circles, cause a white paper to be written that does not solve the
problem, and this time we may even have a melt down and loose critical
IETF resources into the ozone. But its your own trip. But I have found
Trips on EIDs have been very bad Trips. In fact you may have a social
responsibility if we could loose IETFers to the ozone to not go
there :----)
>Instead, I would like to point out that in particular the use of
>anonymous IPv6 addresses has to be considered as something under
>the control of the application invoked by the user. Thus, it is not
>realistically possible to specify default source selection rules for
>the use of anonymized IPv6 addresses. Sometimes a user wishes to
>be anonymous, and sometimes a user does NOT wish to be anonymous.
>I do not think it is appropriate for the network protocol stack to
>try to second-guess the user's intentions.
I agree 100%. In fact I will take it further. I think its a users
right to not believe in this entire privacy issue about IPv6 and decide
to live with the perceived risk (especially on private Intranets).
Anonymous address processing will cost something on a node that uses them
and users may not want the interference. Users rule a the end of the day
because they pay, and second guessing their intentions is not something
I will ever build as an engineer unless they ask me to. Most users
assume personal responsbility for their intentions I know, and know the
trade-offs or ask people like me when it comes to networking.
>This note is already too long, but there is much more to say.
Good note though and good idea because if we can send to the
care-of-adress directly it is simply faster and heck to any user faster
is better.
>I look forward to seeing whether others are as interested in these
>issues.
Count me in Charlie,
thanks
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
