Subject: [DMM] Answer on raised questions for the proposed API

From: "Seil Jeon" <[email-masked]>
Date: Thu, 26 Mar 2015 20:08:12 -0000

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

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 30 Mar 2015 15:08:07 +0100

Hi Danny,

Any comments?

Regards,

Seil Jeon

From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: [email-masked]
Subject: [DMM] Answer on raised questions for the proposed API

Hi,

 

 

Regards,

Seil Jeon

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 30 Mar 2015 15:43:55 +0000

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-masked]]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: [email-masked]
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,
Seil Jeon

From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: [email-masked]<mailto:[email-masked]>
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.

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?

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.

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 31 Mar 2015 13:23:12 +0100

Hi Danny,

See the inline please.

Seil Jeon 

From: Moses, Danny [mailto:[email-masked]] 
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

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.

Seil -> Yes, it's true. Thanks for correction.

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.

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

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.

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

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.

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

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-masked]> mailto:[email-masked]] 
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc:  <mailto:[email-masked]> [email-masked]
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,

Seil Jeon

From: dmm [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [DMM] Answer on raised questions for the proposed API

Hi,

 

 

Regards,

Seil Jeon