In your previous mail you wrote:
During the last IETF, there was a discussion about when a mobile node
should use its care-of address for communications.
=> yes, I asked for more flexibility in the (source) address selection
mechanism.
One possible answer is "never". Mobile IPv6 was designed to avoid
extra signaling overhead that might result from the use of the home
address.
=> "never" is the proposed solution in the current draft
(draft-ietf-ipngwg-default-addr-select-01.txt). IMHO a finer control
is needed. The current text is:
>Rule 5: Prefer home addresses.
>If SA is a home address and SB is a care-of address, then prefer SA.
>Similarly, if SB is a home address and SA is a care-of address, then
>prefer SB.
>An implementation MAY support a per-connection configuration
>mechanism (for example, a socket option) to reverse the sense of
>this preference and prefer care-of addresses over home addresses.
However, if the mobile node can make the following assertions:
1. No mobility events will occur
=> this can be enough to reverse the "never" in "always" but a
per-connection config is not enough. And of course there are many
cases between never and always, like "close enough" to home or
visited network.
Another interesting factor is what might be meant by (1).
=> there is a good example of (1): the use of mobility for "smart"
nomadism, ie. for instance you have a laptop with an address in
Nokia labs in the Silicon Valley and when you go to Nokia labs
in the New England you'd like to keep this address for receiving
your mail through your prefered MTA, but use the local address for
all other things like printing documents.
I claim that it is up to the application to make these determinations,
=> this is done by the per-connection (ie. socket option) hook.
or else it is up to the context in which the user invokes the
applications.
=> then you believe we need more flexibility here too?
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.
=> as far as I know there is no other mailing list than the IPng one
for discussion of these issues. I wrote a proposal and sent it
to authors of the draft. We have done no progress since the end of
the IETF meeting (jetlag + holidays?) but I'd like to resume the
discussion if more work is needed...
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 have coded a notion of proximity with longest prefix matching
(the one used in routing), is it enough?
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.
=> Rule 7 is as inflexible as rule 5. Is the per-connection (socket option)
hook enough? I believe you'd like to have a per-context (binary) control.
This note is already too long, but there is much more to say.
I look forward to seeing whether others are as interested in these
issues.
=> I am interested... There are two points I'd like to see explained:
- add binary choices of rules 5 and 7 in the policy table in order to
have finer control (note that for rule 5 binary is not enough).
- what are the proposed granularities for the policy table (only one
node-global table, an optional table in environment (per user, per
session, per process-group, ...), ...).
And for the last point what difference between the source and destination
selection (implementations can be done at different layers)? I think
there should be no difference but they are some implementation trade-offs...
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
