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.
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.
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.
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.
Can you provide a scenario in which an application will not request to refresh
the Sustained IP address?
Regards,
/Danny
From: Seil Jeon [mailto:[email protected]]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: [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.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
