Re: comments/questions on draft-yegin-dmm-ondemand-mobility-00

Hi, Alper,

Alper Yegin wrote:
> Hi Pete,
> 
>>>>> Alper,
>>>>> 
>>>>> I read the draft and have few quick comments and questions.
>>>>> Interesting draft by the way. In Section 3.1. it says:
>>>>> 
>>>>> "- Access Network Anchored Address  This type of IP address
>>>>> provides IP session continuity but not IP address reachability."
>>>>> Why is that? What makes IP(v6) address unreachable (I assume from
>>>>> Internet side)? I would like to see the rationale described here
>>>>> for this reachability assertion.
>>>>> 
>>>> 
>>>> 
>>>> IP Address Reachability is defined as follows:
>>>> 
>>>>   IP address reachability: The ability to maintain the same IP
>>>>   address for an extended period of time.  The IP address shall stay
>>>>   the same across independent IP sessions, and even in the absence of
>>>>   any IP session.  The IP address may be published in a long-term
>>>>   registry (e.g., DNS), and it shall be available for serving
>>>>   incoming (e.g., TCP) connections.  IP address reachability is
>>>>   essential for mobile hosts to use specific/published IP addresses.
>>> 
>>> 
>>> I can read that from the draft but it still does not answer my
>>> question. Say, I get an ANAA and the either the MN or the AN does
>>> dynamic DNS update. Assuming the AN does not intentionally block
>>> incoming connections for ANAAs the MN can be reachable. What is the
>>> rationale to rule out incoming connections? I recon you also mix the
>>> "IP address shall stay the same across independent IP sessions" with
>>> your definition but IMHO that has very little to do with reachability.
>> 
>> I see Jouni's point, and I think the distinctions between different
>> types of addresses and their capabilities is a bit artificial in
>> both the Yegin draft and the prefix coloring approaches.
>> 
>> I think that any given address may change its type and function over
>> its lifetime.  An address that was originally assigned as "Unanchored"
>> could be promoted to "Access Network Anchored" if needed by the MN,
> 
> That's right.
> But that's the only transition possible.

Depending on how you define these terms, you are right.  But I am
saying that the hard distinctions you make in the draft may not be
that intellectually useful.

>> and as Jouni
>> notes an "Access Network Anchored" address could be registered in
>> DNS to provide reachability, and then you just need to make sure you
>> maintain that address for as long as the DNS entry exists + TTL.
> 
> It's a different type of reachability, with very distinct
> characteristic. Please see my response to Jouni.

Sure, but maybe reachability of an IP address is not what's needed here.
Reachability of the host from nodes that don't yet know its IP address
is what counts.

>>  A static coloring
>> of prefixes at the time they are assigned is not good enough.  We
>> really need to know how many references to an address are outstanding
>> everywhere in the system, and garbage collect old addresses when these
>> reference counts go to zero.  Of course, we cannot hope to keep track
>> of all the places throughout the Internet that have cached a given IP
>> address associated to an MN, but we can at least attempt to provide an
>> approximation to this abstract idea.
>> 
>> Also, I take issue with the use of "anchored" to distinguish address
>> types. It is possible for an address to be persistently assigned
>> without being "anchored" on any one given endpoint, especially if we
>> use routing instead of tunneling to maintain the connectivity.
>> 
> 
> If one can propagate host routes across the Internet, then the anchor
> aspect disappears.

Maybe you need an anchor after you have moved a certain distance in the
Internet topology, but not before.  And there is no need for that anchor
to be the same as the first access router that assigned the address.


An MN should be able, at any time, to get a fresh IP address (in general,
we should be talking about a prefix) that is topologically matched to its 
current attachment point.  That prefix will be routable over a certain
set of other attachment points by network-based means, and some mechanism
should be provided to inform the MN whether the prefix is still on-link
at any new attachment point (perhaps as simple as an RA, or something
more optimal could be developed for specific link technologies).  If the
address is no longer on-link, the MN should be able to get a new prefix
and set up a tunnel from an HA to its current attachment point.  The HA
and the HA-MN security association should be established simultaneously
with the assignment of the original prefix (this step is optional if the
network that originally assigned the prefix doesn't want to provide global
mobility for that prefix).

The MN thus maintains a pool of prefixes, and should be able to renew its
lease on any prefix remotely from wherever it happens to be currently
attached.  It is entirely up to the MN to decide of which prefixes it needs
to maintain ownership, whether to register any of these addresses in DNS,
and to decide which prefixes are no longer needed by any applications and 
can be returned to the network(s) that assigned them.

It's possible that one or more of these addresses are "permanently" assigned
to the MN (for some definition of "permanent") and provide the "reachability"
property that you defined in the draft.  However, that's merely a configuration
and deployment consideration.

-Pete