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

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.


> Then later in Section 3.1. it says:
> 
>  "The IP address is allocated by a serving IP gateway.  When the mobile"
> 
> I cannot find a proper description what a "serving IP gateway" is and
> what kind of functions it is supposed to posses.
> 

It's just the default IP gateway, the IP router serving the subnet. 


> In Section 3.4. there are few things. First, it says:
> 
>  "available set of IP addresses when selecting an address.  According
>   to the proposed solution, if the requested type IP address is not
>   available at the time of the request, then the IP stack shall make an
>   attempt to configure one such IP address.  The selected IP address"
> 
> Assuming the address configuration as per SLAAC or DHCPv6 has already
> taken place within the stack, how the "attempt to configure one such IP
> address" should be understood? Would it imply signaling towards network
> or creation of tunnels or what?

Yes. 
For example if a Home Anchored IP address is needed, but none is available, then the IP stack would trigger Mobile IP to configure one.



> This is quite unclear to me after reading
> the draft.
> 
> Second, it says:
> 
>  "shall be compliant with the requested IP address type, whether it is
>   selected among available addresses or dynamically configured.  In the
>   absence of a matching type (because it is not available and not
>   configurable on demand), the source address selection algorithm shall
>   return an empty set."
> 
> I read this as a change proposal to RFC6724 algorithm.. which part and
> which rule you intend to modify/add? Since you aim to standards track
> this part should be described in detail.
> 

Rule 4. 


> Last, there is no discussion how the stack/host knows what address in
> unanchored/access anchored/home anchored. I would like to see some
> technical discussion how that is accomplished and possibly pointers to
> existing work on that area if there is some.
> 

We'd refer to prefix coloring drafts.

(We'll add clarifications to the text in revision addressing your questions.)

Alper




> - Jouni

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm