Hi Lorenzo,
The intent of this draft is to focus on the Socket API extensions and the
interaction between applications and the IP stack running on the mobile host.
Not to describe the interactions between the IP stack and the network.
My understanding is that as long as the draft maintains the above, your
concerns should be satisfied.
I reviewed the draft once more and found (in addition to some typos which I’ll
fix) a couple of places in section 3.4 – Conveying the Selection – that need to
be modified in order to satisfy your concerns:
1. The paragraph before the definition of the IPV6_REQUIRE_SRC_ON_NET flag:
‘When the IP stack in required to assign a source IP address of a specified
type, it can perform one of the following: It can assign a preconfigured
address (if one exists) or request a new one from the network. Using an
existing address is instantaneous but might yield a less optimal route (if a
hand-off event occurs since its configuration), on the other hand, acquiring a
new IP address from the network may take some time (due to signaling exchange
with the network).’
I propose the following modifications:
i. Replace ‘… or request a new one from the
network…’ to ‘… or configure a new one using new resources from the network…’
ii. Replace ‘… acquiring a new IP address
from the network may…’ with ‘… configuring a new one using new network
resources may…’
The modified paragraph will be:
‘When the IP stack is required to assign a source IP address of a specific
type, it can perform one of the following: It can assign a preconfigured
address (if one exists) or configure a new one using new resources from the
network. Using an existing address is instantaneous but might yield a less
optimal route (if a hand-off event occurred since its configuration), on the
other hand, configuring a new one using new network resources may take some
time (due to signaling exchange with the network).’
2. The paragraph following the definition of the IPV6_REQUIRE_SRC_ON_NET:
‘If set, the IP stack will request a new IP address of the desired type from
the current serving network…’
I propose the modify this to:
‘If set, the IP stack will request new resources from the network in order to
configure a new IP address with the desired service type…’
Please also notice the disclaimer in section 3.3 – Granularity of Selection –
that says:
‘It is outside the scope of this specification to define how the host requests
a specific type of address (Fixed, Session-lasting or Non-persistent) and how
the network indicates the type of address in its advertisement of addresses (or
in its reply to an address request).’
I can modify that to ‘… type of address/prefix…’ but I prefer not to, since
this draft focuses on Socket APIs (which deal with addresses – not prefixes). I
hope you can accept this.
Do the above modifications fully address your concerns?
Thanks,
Danny
From: Lorenzo Colitti [mailto:[email protected]]
Sent: Monday, December 05, 2016 03:57
To: Moses, Danny <[email protected]>
Cc: Peter McCann <[email protected]>; jouni.nospam
<[email protected]>; [email protected];
[email protected]
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Danny,
yes, there are two documents, but draft-ietf-dmm-ondemand-mobility is the one I
am objecting to at the moment.
The reason is that it describes a practice where the application gets an IPv6
address by issuing a request to the network, and RFC 7934 explicitly recommends
against that. It doesn't matter whether the IPv6 address is requested and
granted via DHCPv6, PCO options, HTTP requests, or smoke signals - the key
point is that per RFC 7934, the network should not be handing out individual
IPv6 addresses based on explicit requests by the host.
The best example of that practice is this text:
In case an application
requests one, the IP stack shall make an attempt to configure one by
issuing a request to the network. If the operation fails, the IP
stack shall fail the associated socket request
but there are likely other examples elsewhere in the draft.
I would suggest rewording that text to say that the MN should pick an IP
address out of a (/64 or shorter) prefix that has the desired properties. If
there is not already a prefix assigned to it that has the desired properties,
then it should request a prefix with the desired properties.
I agree that we do not need application developers to think in terms of
prefixes, but we do need network protocol designers and implementers, and OS
implementers, to design and implement the request machinery using prefixes and
not individual IPv6 addresses.
Cheers,
Lorenzo
On Sun, Dec 4, 2016 at 1:13 AM, Moses, Danny
<[email protected]<mailto:[email protected]>> wrote:
Hi guys,
I hope there isn’t a confusion between draft-ietf-ondemand-mobility and
draft-moses-dmm-dhcp-ondemand-mobility.
• Draft-ietf-ondemand-mobility defines the ability of the network to
provide different types of session continuity services and extends the Socket
interface to enable application to influence the service they require for the
newly established IP session. It does not specify how the session continuity
requirements are conveyed to/from the network.
• Draft-moses-dmm-dhcp-ondemand-mobility is the draft that defines
extensions to DHCPv6 in order to convey session-continuity service type to the
network.
Lorenzo,
I the last F2F in Seoul, you expressed your concerns that the proposed DHCP
extensions to enabling the specification of the service type in IP address
requests, contradict the recommendations specified in RFC 7934. As I mentioned
in the discussion, I am committed to fix the wording in that draft to resolve
that contradiction.
But draft-ietf-ondemand-mobility discusses extensions to the Socket interface.
Sockets are used by application developers to initiated IP sessions. I do not
think application developers should be networking experts and should be aware
of what is being allocated by cellular networks to mobile hosts (or UEs, in the
3GPP jargon…). This draft does not indicate that each invocation of a socket
API to initiation an IP session, results in a request to the network. It does
not get into these resolutions intentionally. We are separating the description
of what an application does, to what the mobile host’s IP stack does.
Therefore, I do not think we should confuse application writers with IP
prefixes. All they need to know is how to influence the service that are
getting, like their ability to choose between a reliable transport (TCP) or
unreliable one (UDP).
I hope you agree with this separation.
Thanks and regards,
Danny
From: Peter McCann
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, December 02, 2016 22:37
To: Lorenzo Colitti <[email protected]<mailto:[email protected]>>
Cc: jouni.nospam <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at
the same time. However, I think it is important to reclaim a prefix for use by
another MN after the current MN has moved to a new attachment point and stopped
using the prefix it got from the old attachment point. It is also important
to refrain from advertising the prefix to another MN until the current MN has
stopped using it. That is the network state I am talking about.
-Pete
From: Lorenzo Colitti [mailto:[email protected]]
Sent: Friday, December 02, 2016 3:32 PM
To: Peter McCann <[email protected]<mailto:[email protected]>>
Cc: jouni.nospam <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
On the particular case of shared links: note that they have substantial
scalability and performance issues. In order for shared links to work you have
to engage in DAD proxying, ND snooping, client isolation and all sorts of
unsavoury and L2/L3 magic that does not scale. Some of these issues are
described in RFC 7934 section 9.3. On shared links, these forces act to reduce
the number of IP addresses per host that the network can support and leads to
the negative consequences in section 4 of the document, which is why they are
not recommended.
For these and other reasons, on many public networks we're seeing a shift
*away* from shared links - see, for example,
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large
deployments of that model in the form of Comcast community wifi.
For many years 3GPP networks have been providing those benefits by providing a
full /64 to every host. I would hate to lose those benefits.
On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann
<[email protected]<mailto:[email protected]>> wrote:
With a fixed access network the prefix can be assigned to the link and used by
anyone who joins the link.
With a prefix offering mobility the prefix belongs to the mobile host and needs
to move with it. There aren’t enough prefixes (even in IPv6) to assign a
permanent prefix to each UE for every topological attachment point that it
might visit or start a session from.
-Pete
From: Lorenzo Colitti [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann <[email protected]<mailto:[email protected]>>
Cc: jouni.nospam <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
But you have that problem with IP addresses as well, right? I don't see how
"assigning a prefix with certain properties" requires more state in the network
than "assigning an IP address with certain properties".
On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann
<[email protected]<mailto:[email protected]>> wrote:
Providing any kind of mobility service for a prefix will require some state
somewhere in the network. It would be great to avoid an allocation request /
response for the prefix, but the state has to be created somehow before the UE
can use the prefix and it has to be reclaimed eventually after the UE stops
using the prefix (which may not be until well after it disconnects from the
current link and moves to another one).
Would welcome any suggestions on how to manage this state.
-Pete
From: dmm [mailto:[email protected]<mailto:[email protected]>] On Behalf
Of Lorenzo Colitti
Sent: Friday, December 02, 2016 12:04 PM
To: jouni.nospam <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Hi,
I like the goal of reducing network cost by allowing the use of IP addresses
that do not require network mobility, but we should not be doing this by
requesting IP addresses from the network, because this violates IPv6 address
assignment best practices.
Specifically, RFC 7934 recommends that a) the network should provide multiple
addresses from each prefix and b) the network should allow the host to use new
addresses without requiring explicit requests to the network. This is in
conflict with at least this text in the draft, which says:
In case an application
requests one, the IP stack shall make an attempt to configure one by
issuing a request to the network. If the operation fails, the IP
stack shall fail the associated socket request
One way to resolve this conflict would be to say that the network must not
assign individual addresses, but /64 (or shorter) prefixes. So if the device
desires to use fixed IPv6 addresses, then the network should give the host a
fixed IPv6 prefix from which the host can form as many addresses as it wants.
I do not think we should advance this document until the conflicts are
resolved. This document is about IPv6 address assignment to mobile nodes, and
we should not publish a document about IPv6 address assignment that conflicts
with best current practices on IPv6 address assignment.
Regards,
Lorenzo
On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam
<[email protected]<mailto:[email protected]>> wrote:
Folks,
The authors of draft-ietf-dmm-ondemand-mobility-07 and
draft-sijeon-dmm-use-cases-api-source have come up with a merged document
draft-ietf-dmm-ondemand-mobility-08.
This email starts a 2 week WGLC for draft-ietf-dmm-ondemand-mobility-08.
The WGLC starts 11/28/16 and ends 12/12/16.
Provide your comments, concerns and approvals to the email list (and hopefully
also to IssueTracker).
- Jouni & Dapeng
Begin forwarded message:
From: IETF Secretariat
<[email protected]<mailto:[email protected]>>
Subject: IETF WG state changed for draft-ietf-dmm-ondemand-mobility
Date: November 28, 2016 at 12:51:34 PM PST
To:
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>
Resent-From: <[email protected]<mailto:[email protected]>>
Resent-To: [email protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]>
The IETF WG state of draft-ietf-dmm-ondemand-mobility has been changed to
"In WG Last Call" from "WG Document" by Jouni Korhonen:
https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
Comment:
WGLC starts 11/28/16 and ends 12/12/16.
_______________________________________________
dmm mailing list
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
