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

Hi, Alper, Jouni,

Jouni Korhonen wrote:
> Alper,
> 
> On Jul 24, 2013, at 4:16 PM, Alper Yegin <[email protected]> wrote:
> 
>> Hi Jouni,
>> 
>> Thanks for the review and comments.
>> 
>> 
>>> 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, 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.  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.

-Pete