You have a good point here.
Now I understand the need for the flag you are proposing !!!
We need to take a better look at RFC 6724 and figure out if we need to update
it.
I am thinking of two places that might require an update:
1. When an application chooses not to specify a source address (but
request a specific type)
2. When an application wishes to choose the source address from a
provided list.
When the application indicates the desired address type, but chooses not to
specify the source address (from a list provided by the IP stack), the stack
should allocate a source IP address according to the address-type requested by
the application. In this case, we should consider adding text to describe the
behavior for Sustained IP addresses. Specifically, if there are several
Sustained IP addresses allocated to the mobile host, whether to choose one of
them, or to have the mobile host request a new one from the network (as a
result of a mobility event - for example).
When an application wishes to chooses the source address from the available
list (obtained by getaddrinfo()), there are some alternative approaches we
should consider:
1. Enhance getaddrinfo() enabling the application to specify the required
address type, and return the list of source addresses that are of that type
(Nomadic, Sustained, Fixed or DontCare), or -
2. Provide the list of addresses with an indication of their type
(Nomadic, Sustained, Fixed or TypeUnknown) and an indication of whether each
address is New (allocated after the last handoff event) or Old (allocated
before the last handoff event)
3. Some other approach...
The flag is need here, to enable the application to request a new IP address
(if the returned list only contain 'Old' addresses) !!!
I agree that we should discuss this. How about bringing it to the next
'Mobility Exposure and Selection WT' call?
Regards,
/Danny
From: Seil Jeon [mailto:[email protected]]
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: [email protected]
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Danny,
Meeting is always good, even with you by f-to-f. But in the discussion, the
main issue is whether we will allow the default source address selection rules
defined in RFC6724 for selecting a Sustained IP address among several ones or
fundamentally block them for a specific reason raised by a DMM need. The latter
approach is not reasonable no matter how I try to think of.it.
If an application has the specific preference of a newly obtained Sustained IP
address, it uses the proposed API.
Regards.
Seil
From: Moses, Danny [mailto:[email protected]]
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil Jeon
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Seil,
By now we have been discussing this for quite some time and clearly we did not
succeed in convincing each other.
I suggest we try again when we have a chance to meet face to face. Meanwhile,
let's listen to what other people have to say on this matter.
Regards,
/Danny
From: Seil Jeon [mailto:[email protected]]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [DMM] Answer on raised questions for the proposed API
Resent.
Seil
From: Seil Jeon [mailto:[email protected]]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: '[email protected]'
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Danny,
See the inline please. I marked current replies with ">>" and previous replies
with ">" for you to catch them easily.
Regards,
Seil
From: Moses, Danny [mailto:[email protected]]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Seil,
Please see my replies (surrounded by >>2) to yours.
Regards,
/Danny
From: Seil Jeon [mailto:[email protected]]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Danny,
See the inline please.
Seil Jeon
From: Moses, Danny [mailto:[email protected]]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [DMM] Answer on raised questions for the proposed API
Hi Seil,
As to the potential of abuse:
Yes, I see your point and you are correct. If the IP stack will not request a
sustained IP address more than once after each movement to a new LAN (with a
different prefix), than there will be no abuse.
> Yes, it's true. Thanks for correction.
As to the second comment, please let me elaborate:
One potential implementation of the IP stack in the host, can be to request a
Nomadic IP address and a Sustained IP address whenever connecting to a
network, and whenever moving to a new LAN, regardless if there are any
applications requesting any addresses. This way, whenever an application is
launched and requests either a Nomadic or Sustained IP address, the stack can
provide one without having to issue a request to the network. In this case,
there is no need for this flag from the application.
> Decision of which type of IP address by default will be depending on the IP
> pool management policy by operators. You case may correspond to one of them.
> What if only the Nomadic IP address is basically allocated upon a network
> attachment? That is, a lot of applications require mere Internet connectivity
> without session continuity support. So, the Sustained IP address will be
> requested on demand, and the proposed flag will be used to get a new
> Sustained IP address by expressing the explicit request by an application.
>>2
As I mentioned at the beginning of the description - it is a description of one
alternative. I am not assuming it is the only scenario.
Yes, I agree that many apps require only Nomadic IP addresses, but in this
example, the IP stack in the host pre-allocates both Nomadic and Sustained IP
addresses upon attachment...
>> As I said, it could be, but not as general one. The proposed API is useful
>> through the explicit expression for any potential scenarios.
Yes, we can describe an alternative in which a Nomadic IP address is
pre-allocated upon NW connection (and after every movement to a new LAN) and a
Sustained (and/or Fixed) address is allocated on-demand. Even in such a
scenario, I do not see any use for this flag - see my reply to the second item
below...
>>2
>> My answer was already given in following answer in previous email.
Another potential implementation of the IP stack in the host is not to request
IP addresses in advance. In that case, it will issue a request for a Nomadic IP
address or a Sustained IP address the first time an application requests one
and use it for subsequent requests as long as it is not moving to a different
LAN. Once it moves, it will again request a new IP address (Nomadic or
Sustained - according to what is required) after receiving the first request
from any application. In this case as well, there is no need for this flag.
> Another application requested just Sustained IP address while the IP stack
> has already a Sustained IP address. Why should the IP stack try to get a new
> one, though the application indicated simply "Sustained IP address type"? You
> case took a step towards a solution where you want to draw. I don't expect
> the action is generic when a Sustained IP address type is requested.
Besides, you assumption on IP address allocation seems not valid. A mobile host
would get an IP address whatever the allocated IP address type is when it
attaches at a network, regardless of an application's IP address request.
>>2
Looks like I did not express myself well enough (and did not fully understand
your reply). Let me list some events that might help clarify...
Initial state: Mobile node is connected to a network; no Sustained IP address
is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating
that if an application requests a Sustained IP address, it will have to request
one from the network.
Event1: An application that requires a Sustained IP address is launched.
APP action: App requests a Sustained IP address from the IP stack using the
proposed new API.
IP stack action: Since SustainedIPAddressNeeded is set, request one from the
network.
Network action: Assigned a Sustained IP address to the mobile node.
IP stack action: (1) Mark the new Sustained IP address as the one to be
associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete
the API action and associate the marked Sustained IP address with that port
(app)
Event2: A new application that also required a Sustained IP address is launched
App action: App requests a Sustained IP address from the IP stack using the
proposed new API
IP Stack action: Since SustainedIPAddressNeeded is not set, complete the API
action and associate the marked Sustained IP address with that port (app)
Event3: The mobile node moves to a new LAN
IP Stack action: Set a flag indicating that the currently available Sustained
IP address is not optimized
Event4: An application that requires a Sustained IP address is launched.
APP action: App requests a Sustained IP address from the IP stack using the
proposed new API.
IP stack action: Since SustainedIPAddressNeeded is set, request one from the
network.
Network action: Assigned a Sustained IP address to the mobile node.
IP stack action: (1) Mark the new Sustained IP address as the one to be
associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete
the API action and associate the marked Sustained IP address with that port
(app)
Note that the behavior of the IP stack in Event4 is exactly like the one in
Event1.
I believe that this event is the one we have different of opinions: I think
that the default behavior of the IP stack is to request a new Sustained IP
address since it moved to a new LAN, and you think that it should do so only if
the application specifically requests a new Sustained IP address via the flag
you are proposing.
>>2
>> You can see my answer at the lowest ">>" in this mail.
As a matter of fact, if such a flag is defined, I cannot think of an example
where it will not be used. It seems to me that applications will always request
a refreshed Sustained IP address (when requesting a Sustained IP address). If
this is correct, the flag is redundant.
> Some applications, e.g. email, that are not relatively restricted from
> optimal routing would consider a Sustained IP address without issuing the new
> flag. More applications based on such network characteristic can be thought
> more than expected.
And such use of existing Sustained IP address is not extraordinary, since IP
address is a resource, even in the consideration of IPv6 deployment. If as many
as applications require new Sustained IP address, it will end up in a lot of
network resource consumption in the mobility routers where the Sustained IP
addresses are anchored as the terminal moves.
>>2
I am sorry but I disagree with the email example. I categorize it as an example
of an application that will request a Nomadic address since it does not break
when the mobile node moves to a new LAN and the source IP address is changed.
It simply restarts the socket and continue with the new source IP address (the
user will not even notice this).
>> The example was given as a benefit when the existing Sustained IP address is
>> used. You could get some insight from such kind of application not caring
>> much the routing distance even on the Sustained IP address.
I did not understand the other text regarding resource consumption. I thought
we agreed that even of a new Sustained IP address is requested upon each
movement to a new LAN, the effect on IP address allocation is not significant.
Otherwise, my initial comment on applications abusing the network using your
proposed flag, becomes valid again
>>2
>> No, our draft didn't say so. Our idea is that a new Sustained IP address is
>> requested upon receiving *new* flag from an application, as a preference for
>> a source address selection. You need to read our draft classifying the
>> categories of IP address request again.
Besides, I don't understand what is abused. Delivering its preference cannot be
abuse. Regarding "abuse", I see it in your default behavior you're assuming
here. In your scenario, a new app initiated in a new network will be forced to
use a newly obtained Sustained IP address. You see that? You totally block the
possibility to be considered by the default source address selection rules
defined in RFC6724. But in our draft, in case the need of a newly obtained
Sustained IP address is prioritized, the proposed *new* flag can be used by
app's request, thus it will be selected with priority.
Can you provide a scenario in which an application will not request to refresh
the Sustained IP address?
> It was mentioned in the former comments.
Regards,
/Danny
From: Seil Jeon [mailto:[email protected]]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: [email protected]<mailto:[email protected]>
Subject: FW: [DMM] Answer on raised questions for the proposed API
Hi Danny,
Any comments?
Regards,
Seil Jeon
From: dmm [mailto:[email protected]] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: [email protected]<mailto:[email protected]>
Subject: [DMM] Answer on raised questions for the proposed API
Hi,
I could attend DMM Thursday meeting via MeetEcho.
I could also hear some raised comments by Danny and Someone. Here goes answers
to the raised questions.
First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),
The use of the proposed API is suggested in the SUSTAINED IP address case in
the draft. On receiving this API with the SUSTAINED IP address type at the IP
stack, it will try to get a new SUSTAINED IP address if there is no available
in the currently attached access network. So, actual obtaining of the IP
address will be tried one time while attached at a specific access network.
Even some applications put this API after, the already obtained SUSTAINED IP
will be used. So, no worries about abuse.
Second question sounded to me like that this API is not needed because the host
can get a new SUSTAINED IP address, right?
If the question is right, I don't understand what the question is meant, that
is how the host can get a new SUSTAINED IP address?
Based on the definition of three types of IP address, an application should
show its requirement with an API among them. If it is the SUSTAINED IP address,
how do we expect the IP stack will try to get a new SUSTAINED IP address?
Besides, the propsoed API is not used alone but with the three type APIs.
Regards,
Seil Jeon
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
