Subject: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Jul 2013 11:32:40 +0300

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.

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.

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

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.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Wed, 24 Jul 2013 16:16:57 +0300

Hi Jouni,

Thanks for the review and comments.

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

> what kind of functions it is supposed to posses.

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

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

Rule 4. 

> 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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Jul 2013 16:35:40 +0300

Alper,

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

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Wed, 24 Jul 2013 13:54:55 +0000

Hi, Alper, Jouni,

Jouni Korhonen wrote:
>>> I read the draft and have few quick comments and questions.
>>> Interesting draft by the way. In Section 3.1. it says:
>>> 
> 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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 24 Jul 2013 23:58:28 +0300

Jouni,

> very little to do with reachability.

Yes, in the case of dynamic DNS there's "reachability".
But we need to understand *what* is reachable.

When HNAA is used: The IP address stays reachable. 
When we let the IP address change but keep using dynamic DNS: The FQDN stays reachable.

These are two different types of reachability. 
And they are not equivalent.
The latter has issues: Cannot converge fast, and does not work all the time (remote hosts do not keep querying the DNS just in case their peers have changed IP address… They cache DNS results…)

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 25 Jul 2013 00:06:35 +0300

Hi Pete,

> be promoted to "Access Network Anchored" if needed by the MN,

That's right.
But that's the only transition possible.

> and as Jouni
> 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.

>  A static coloring

If one can propagate host routes across the Internet, then the anchor aspect disappears. 

Alper

---

From: Peter McCann <[email-masked]>
Date: Wed, 24 Jul 2013 21:24:21 +0000

Hi, Alper,

Alper Yegin wrote:
>>>>> "- Access Network Anchored Address  This type of IP address
>>>>> provides IP session continuity but not IP address reachability."
>>>>   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.

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

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 25 Jul 2013 10:03:37 +0300

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

> Reachability of the host from nodes that don't yet know its IP address

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.

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

> and deployment consideration.

These above makes sense to me.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 25 Jul 2013 13:16:25 +0300

Alper,

> When we let the IP address change but keep using dynamic DNS: The FQDN stays reachable.

I could argue that HNAA is not stable enough to be considered
reachable as per how the draft describes it, especially in the
case of mobile devices. One flap on the wireless connection and
the address is likely to change.

> The latter has issues: Cannot converge fast, and does not work all the time (remote hosts do not keep querying the DNS just in case their peers have changed IP address… They cache DNS results…)

IMHO the difference between the ANAA and HNAA reachability is 
just the timescale. Even if the ANAA is likely to change more
frequently, there should not be a reason to state that it is
not reachable. I would rather focus on the "address stability"
or alike when coming up with the terminology. Say, your MN is
most of the time stationary (like most MNs are today) and
gets and ANAA. As long as the movement of the MN is within
a limited L2 area, its ANAA does not really differ from HNAA,
from the reachability point of view.

- Jouni

---

From: <[email-masked]>
Date: Thu, 25 Jul 2013 13:24:32 +0000

Hi Alper, Peter and Jouni,

Sorry for jumping to this discussion, I have two comments below.

Best regards,
Hassan

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper
>Yegin
>Sent: Thursday, July 25, 2013 9:04 AM
>To: Peter McCann
>Cc: [email-masked]
>Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-
>00
>
>>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>
>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

[Hassan] Why we need IP address reachability? Can you please address some concrete use-case scenarios. 

Upper level reachability is sufficient for an incoming e.g. VoIP call or SMS to a typical MN, and also even if we imagine an MN acting as a server and hosting e.g. a website, no one memorize IP addresses.

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

[Hassan] I agree that it makes sense to keep one of the addresses permanent (assuming we really need this). However, we will need one permanent anchor and data packets of incoming sessions/calls should be routed through it and then tunneled to the MN. Similar issues to the ones addressed to current IP mobility protocols in DMM problem statement will be raised, but only for incoming sessions/calls. 

In fact, I consider this approach as an integrated DMM--MIPv6 approach: MIPv6 manages a permanent HA and HoA for MN's reachability at IP address level for incoming sessions, and DMM for sessions initiated by the MN itself. Imagine mobile CNs --> DMM will be used less and MIPv6 more. I don't like semi-solutions :)

>
>Alper
>
>
>
>
>> -Pete
>>
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 26 Jul 2013 14:14:34 +0300

Hello Hassan,

> Sorry for jumping to this discussion, I have two comments below.

You are more than welcome :-)
Please see below.

> [Hassan] Why we need IP address reachability? Can you please address some concrete use-case scenarios. 

Providing a fixed/stable IP address to the MN is a rare, but existing use case.

Mobile servers need that. They cannot survive client communication if their IP address changes.
An enterprise user connecting to his company intranet via cellular network gets an IP address out of his intranet. This is like a VLAN.
Cellular operators are already marketing "fixed IP" as part of their service. 

> Upper level reachability is sufficient for an incoming e.g. VoIP call or SMS to a typical MN, and also even if we imagine an MN acting as a server and hosting e.g. a website, no one memorize IP add…

Most of the time, yes, no one memorizes the IP addresses. They memorize the DNS name. But once the DNS resolves a name to an IP address, they stick to that IP address. So, that IP address better be stay the same, otherwise the communication breaks. 

> In fact, I consider this approach as an integrated DMM--MIPv6 approach: MIPv6 manages a permanent HA and HoA for MN's reachability at IP address level for incoming sessions, and DMM for sessions in…

Oh, actually I'm not saying every MN shall have a Home Network Anchored Address.
I'm saying some need it, and only those shall get it.

Alper