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

>>>>> 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.
> 


Hmm, I still don't understand why you say so… At any point in time, a given IP address falls in one of these three categories.

>>> 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.
> 


That's another level of reachability. 
See, there's a chain of mapping: ID at app-level -> FQDN -> IP address -> L2 address -> L1 address.

I think you are referring to FQDN reachability.
But in this MIP-land, we are concerned about IP address reachability part of the problem.


>>> 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.
> 

That statement would be true assuming again there's some kind of host/prefix-specific route propagation.

> 
> 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.
> 

These above makes sense to me.

Alper




> -Pete
>