Hi Dave,
Regarding the term "Nomadic" IP address:
Actually, this draft is about enhancements to the Socket API that are useful in
relation with movement of the mobile host. Its intent was to notify the access
network as to the type of IP session continuity it requires upon movement
between LANs. The idea is to reduce the network support for session continuity
(via PMIP, GTP, etc) when it is not needed. This draft is not dealing with
devices migrating from one service provider to another as other issues should
be handled in such scenario.
"Local" is not good as it clashes with IPv6 Local addresses.
The best term in my mind would be: "An IP address without any NW guarantee to
continue to be valid after a potential host movement to a new LAN with a
different IP prefix". So far, we could not come with a good name for such an
address. May be "Guarantee-less"?
Let's not forget: this is going to be used by application developers who do not
necessarily fully understand how networks allocate IP addresses and maintain
their validity.
Regarding when On-Demand resolution occurs (Point 6):
How about if we say:
If applications want to influence the type of IP address their generated
traffic will use, they must do so after creating a Socket and prior to
generating the first transmitted packet.
We do not want to be too specific since it is not a user's manual.
Does this sound reasonable to you?
Thanks,
/Danny
-----Original Message-----
From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, February 18, 2016 22:46
To: Moses, Danny; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
Danny and Alper,
Thanks. I hope your helpful explanations below make it into the draft as well.
On the "nomadic address" question, this name really feels wrong to me. The
address doesn't move and hence isn't nomadic.
You don't like "ephemeral" because it doesn't convey movement.
But a question, does the host have to move for the principles of this document
to apply?
Couldn't a host get a new address (perhaps from a different wireless provider)
without moving?
Maybe "non-nomadic address" or "provider-local address" ?
On point 6, yes I think you have to specify when the resolution occurs, since
it affects which functions return error codes.
I don't think the local address can be resolved before connect(), since the
choice of local address may depend on the remote address to connect. E.g.,
connections to a peer on a local LAN subnet need to use an address on that
interface.
-Dave
-----Original Message-----
From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, February 18, 2016 9:13 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
Hi Dave,
Sorry for the very late response. Somehow we missed the original email and were
reminded by Jouni (Thanks Jouni).
Anyway, thank you for the thorough and helpful comments. We have produced a new
version and will publish it shortly.
Please see further details to your comments:
Dave>
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but
in this draft, Nomadic IP addresses do not move around; they are replaced.
"Ephemeral IP Address" might convey the idea more clearly.
Reply>
"Nomadic" was discussed, it is not the best name but we could not find a better
one.
What 'moves around' is the mobile host and as a result of that movement, its
source IP address might become obsolete (when it moves from its original LAN to
another with a different prefix). An application on a mobile host requires a
'Nomadic' IP address when it does not care for the IP continuity guarantee
services provided by the network. This is either because it knows that the
mobile host is not really mobile, or because it has other means of maintaining
session continuity and does not want the overhead associated with
network-provided IP continuity services.
The term 'Ephemeral' is not associated with movement - we think it is better to
have a 'movement'-related name.
Dave>
2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in
IPV6_REQ_FIXED_IP etc.
- IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC
Reply>
Make sense. Will be changed in the next version.
Dave>
3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs to
be resolved. I suggest the most restrictive flag applies.
Reply>
This is about whether to enable the application to set more than one flag or
not per a given socket. We left that for discussion in the draft but never
resolved it.
We prefer not to enable setting more than one flag since it add complexity. The
application can check the returned code and act upon it. For example, if it
uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns with an error
code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or
IPV6_REQUEST_NOMADIC_IP (or without the flags - in case they are not supported
by the network).
So we are replacing the original text:
More than one of these flags may be set on the same socket. In that case, an IP
address compliant with any one of them shall be selected.
TBD: Disallow this case?
With:
Only one flag of these flags may be set on the same socket. If an application
attempts to set more than one flag, the most recent setting will be the one in
effect.
Dave>
4. Must resolve "Application of this solution to IPv4 is TBD."
- clearly the socket option is IPV6_something, but...
- there is uncharted territory surrounding IPv4-mapped-IPv6 addresses
(https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option
IPV6_V6ONLY is false.
- I think the goal should be that the API *does* apply to IPv4 via
IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or
network may not be able to fulfill the request.
- I.e., permit the application to request constraints on IPv4, but also
expect the application to try for a relaxed address if the initial request
fails.
- I see no need to support the API with AF_INET sockets, since AF_INET6 can be
used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.
Reply>
Actually, the charter of DMM addresses IPv6 only. So we are removing the text
that refers to IPv4 altogether. If we see in the future a need to address IPv4,
we will do so in a separate draft.
Dave>
5. The error codes are not clearly defined. What is the errno for failure of
setsockopt() and others?
Reply>
True.
We added the following text at the end of section 3.4:
The following new error codes are also defined in the document and will be used
in Socket API in compliance with the [RFC5014]:
EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to request
that IP address type */ EAI_REQUIREIPFAILED /* The network could not assign the
specific IP address type */
Dave>
6. I'm unclear on when the on-demand resolution occurs? I don't think it can be
done at the time of setsockopt(); as I understand it, the addresses are
resolved later, at connect() or listen(). I'm not sure about this, but it
should be explained. If the resolution is done at connect() time, is a new
errno required?
Reply>
The addresses should be resolved before connect() or listen() in order to avoid
unnecessary delay caused by the need to request the address from the network
(with DHCP - for example). Furthermore, UDP should also be supported, hence
connect() or listen() may not be used. There for, they must be resolved at
setsockopt() prior to the above calls. Do you see any problem with that?
Do you think text should be added to clarify this?
Dave>
7. Some socket interfaces are not mentioned. What about sendto(), sendmsg(),
which are not connection-oriented?
Reply>
Both assume that a source IP address was assigned to the host.
If the application invoked setsockopt() successfully prior to attempting to
send a message, the appropriate source IP address type will be used for the
transmitted packets. If not, whatever source IP address assigned to the host
will be used.
Dave>
8. In section 4.1, support for legacy applications does not really say how to
support legacy applications.
- my opinion: the default (lacking new socket options) should be to require
Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for
non-connected datagrams.
Reply>
Legacy application will not use these new flags, and as a result, will not be
able to influence the source IP address type and related mobility support. As a
result, they will behave exactly as applications behave today.
Clearly there will be some default behavior as to the assigned source IP
address. Today, this depends on the access networks. Cellular networks usually
provide Fixed or Sustained source IP addresses, and WiFi networks usually
provide Nomadic source IP addresses.
We do not think we should specify a strict behavior in this case, but rather
leave it to be implementation-specific.
Once again, thanks for the good comments.
Alper and Danny
-----Original Message-----
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, December 02, 2015 18:42
To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
(I haven't paid close attention to the list, so apologies if I'm raising old
issues.)
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but
in this draft, Nomadic IP addresses do not move around; they are replaced.
"Ephemeral IP Address" might convey the idea more clearly.
2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in
IPV6_REQ_FIXED_IP etc.
- IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC
3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs to
be resolved. I suggest the most restrictive flag applies.
4. Must resolve "Application of this solution to IPv4 is TBD."
- clearly the socket option is IPV6_something, but...
- there is uncharted territory surrounding IPv4-mapped-IPv6 addresses
(https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option
IPV6_V6ONLY is false.
- I think the goal should be that the API *does* apply to IPv4 via
IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or
network may not be able to fulfill the request.
- I.e., permit the application to request constraints on IPv4, but also
expect the application to try for a relaxed address if the initial request
fails.
- I see no need to support the API with AF_INET sockets, since AF_INET6 can be
used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.
5. The error codes are not clearly defined. What is the errno for failure of
setsockopt() and others?
6. I'm unclear on when the on-demand resolution occurs? I don't think it can be
done at the time of setsockopt(); as I understand it, the addresses are
resolved later, at connect() or listen(). I'm not sure about this, but it
should be explained. If the resolution is done at connect() time, is a new
errno required?
7. Some socket interfaces are not mentioned. What about sendto(), sendmsg(),
which are not connection-oriented?
8. In section 4.1, support for legacy applications does not really say how to
support legacy applications.
- my opinion: the default (lacking new socket options) should be to require
Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for
non-connected datagrams.
-Dave
-----Original Message-----
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Tuesday, December 01, 2015 1:07 PM
To: dmm@ietf.org; Jouni; Dapeng Liu
Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
Folks,
This mail starts two week WGLC for the I-D:
https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
The WGLC ends 12/15/2015.
Provide your reviews and comments to the mailing list. For the better tracking
of issues and proposed changed use the Issue Tracker to submit your
issues/proposals.
- Jouni & Dapeng
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
---------------------------------------------------------------------
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
