Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

["Moses, Danny" <[e-mail]>]

Hi Alissa,

I have tried to figure out what is the cause for the confusion.

I think that the term ‘address type’ used in this document might be the cause, as you are trying to compare it with definitions of types of addresses in other RFCs.

Perhaps the term ‘address type’ is not the best term to define the type of mobile services this document is defining, but we could not find a better name for the term.

In this draft, we are not attempting to define new types of addresses in addition to the ones that were specified as part of IPv6 (Unicast, Multicast, Anycast, the different scopes etc.) and is not related to the address types defined in RFC 7721 (Public, Stable, Temporary etc.).

Yes, one might correlate between a ‘Fixed’ address and a ‘Stable’ address (‘Fixed’ sounds like ‘Stable’) or between a ‘Non-persistent’ IP address and a ‘Temporary’ address (‘Non-persistent’ sound like something not stable…), but that is not the case.

RFC 7721 definitions relate to address within a specific IPv6 link. This document discusses the ability of a network to route packets to mobile nodes that move between different IPv6 links. This is totally different.

Quoting from RFC 7721:

   Stable address:
      An address that does not vary over time within the same IPv6 link.
      Note that [RFC4941<https://tools.ietf.org/html/rfc4941>] refers to these as "public" addresses, but
      "stable" is used here for reasons explained in Section 4<https://tools.ietf.org/html/rfc7721#section-4>.

   Temporary address:
      An address that varies over time within the same IPv6 link.

Note the ‘within the same IPv6 link’ in the definition!

This document discusses the ability to reach a mobile node after it moved from one IPv6 link to a different one due to a mobility event. When the network allocates a ‘session-lasting IP address’ it guarantees to be able to route packets to that destination address even after the mobile node moves to a different IPv6 link (this is the essence of PMIP). When the network allocates a ‘non-persistent IP address’, packets destined to that address will not reach the mobile node after it had moved to a new IPv6 link.

The ‘stableness’ or ‘temporary-ness’ of the addresses, are really the ‘stableness’ or ‘temporary-ness’ of the network’s ability to route the packets after a mobility event, hence ‘session continuity’ or ‘address reachability’.

I might have used bad terminology, but this is what I meant by ‘orthogonal’. A ‘Stable’ IP address can be used as either ‘Fixed’, ‘Session-lasting’, ‘Non-persistent’ or even ‘Graceful replacement’ IP address as defined in this document. The fact that an address is ‘Stable’ in a specific IPv6 link, does not necessarily mean that it will be useful after a mobility event. This depends on the service provided by the mobile network.

In the Socket API, we used the term addressType for the argument that describes the mobility service that is provided by the network in association with the source IP address. We believe that from the programmer’s point of view this session continuity (and /or address reachability) service associated with the address could be perceived as an ‘address type’.

I hope this answer is clearer than the previous one and I hope I hit the issue that caused the confusion.

Regards,
Danny









-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]]
Sent: Friday, February 22, 2019 19:10
To: Moses, Danny <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Dapeng Liu <[e-mail]>
Subject: Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)



Hi Danny,



> On Feb 22, 2019, at 9:06 AM, Moses, Danny <[e-mail]<mailto:[e-mail]>> wrote:

>

> Hi Alissa,

> Thanks for your comments.

>

> Following are me responses:

> DISCUSS (1): Normative requirements on "the IP stack" are too broad:

> I have checked all places that have normative requirements regarding "IP stack" in the document. Please see my response per instance:

> Section 3.4 - On Demand Nature has several normative requirements on the "IP stack". One example:

> "When an application requires a specific type of IP address and such an address is not already configured on the host, the IP stack SHALL attempt to configure one."

>

> This section describes the new On Demand feature and is part of section 3 which describes the Solution for On Demand mobility. As such, I believe it is clear from the context that the normative requirements in this section are for stacks that implement the On Demand features and believe there is no need to be more specific in this place.



I disagree. At a minimum I think 3.4 needs to specify that its normative requirements apply only to implementations that support the API specified in Section 6.1.



>

> Section 5.2 - IP Stack in the Mobile Host There are several normative

> requirements on New IP stacks. This section is part of section 5 that discusses backwards compatibility and as such we assumed that "New IP stacks" refer to IP stacks that implement On Demand functionality. Still, I can see how this might be confusing and thus, I will modify the text from: "New IP stacks" to "new IP stack (that implement On Demand functionality)" to be more precise.

>

>

>

> DISCUSS (2): Intersection between definitions of address types and recommendations in this document and RFC 7721, RFC 4941 and RFC 8064.

> We had similar comments and discussions in dmm. The On Demand document does not define new address types.



If that is the case, why is Section 3.2 entitled “Types of IP Addresses” and why does it begin with the line "Four types of IP addresses are defined with respect to mobility management”? Why does the API take in an argument called “addressType”?



> It formalizes types of services that are associated with the mobility nature of a mobile host in a mobile network environment: Reachability and session continuity. It further defines an association between these services and a source IP address (or IP prefix). The motivation of associating between the service and the IP address is to enable a common understanding between the network and the application on the mobile host, with regards to reachability and session continuity provided as a mobile service by the mobile network.

>

> This is completely orthogonal with the definition of address types in the RFCs mention in the comment or the definition of the different IPv6 address types.

>



I don’t understand how it is completely orthogonal. Are you saying that any of the address types previously defined — public, stable, and temporary — could be generated and used as any of the four address types defined in this document? That’s what it would mean to be completely orthogonal, I think. And if that is not true, I think this document needs to explain which previously defined address types can be used as each newly defined type in this document. Historically we have specified a bunch of different address generation mechanisms and selection guidance inconsistently such that it’s not clear to implementors how to choose an address type for a given situation; this document should not make that situation worse.



>

> COMMENT (1): What is a "very long time" in section 3.2 A "very long

> time" is so long that the address is guaranteed to be fixed even after the mobile host disconnects from the network and reconnects later on (and even when this occurs several times). It is much longer than a guarantee to be valid throughout the life-time of an opened socket (which is longer than and address with no guarantee at all).



Specifying this by using the time period is still vague, though. Is there a difference between this type and public address as defined in RFC 7721? That is, is the point of this that other nodes are expecting such an address to host specific resources or services, which is why the address must remain the same through network disconnections? That’s what it seems like to me.



Thanks,

Alissa



>

> We thought this is clear from the description of the other types of IP addresses. If not, we could change the order of the definition of addresses and have the Fixed address definition after the Session-lasting address definition.

>

> Do you recommend that we re-order the definitions?

>

>

>

>

> COMMENT (2): Remove normative MUST in section 5.1 Ack. Will be removed

> in the next revision.

>

>

>

>

> COMMENT (3): Required discussion on privacy and security implications

> in section 7 I have discussed the content of section 7 with Daniel Migault and ended up with a completely rewritten section. I hope the new version will satisfy your concerns.

>

>

>

> Thanks for the review and comments,

> Danny

>

>

>

> -----Original Message-----

> From: dmm [mailto:[e-mail]] On Behalf Of Alissa Cooper

> Sent: Thursday, February 21, 2019 16:01

> To: The IESG <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>; Dapeng Liu <[e-mail]<mailto:[e-mail]>>

> Subject: [DMM] Alissa Cooper's Discuss on

> draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

>

> Alissa Cooper has entered the following ballot position for

> draft-ietf-dmm-ondemand-mobility-16: Discuss

>

> When responding, please keep the subject line intact and reply to all

> email addresses included in the To and CC lines. (Feel free to cut

> this introductory paragraph, however.)

>

>

> Please refer to

> https://www.ietf.org/iesg/statement/discuss-criteria.html

> for more information about IESG DISCUSS and COMMENT positions.

>

>

> The document, along with other ballot positions, can be found here:

> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/

>

>

>

> ----------------------------------------------------------------------

> DISCUSS:

> ----------------------------------------------------------------------

>

> (1) There are a bunch of places in this document that place normative requirements on "the IP stack" or "IP stacks." This seems too broad to me -- aren't these meant to apply to IP stacks that implement the new API? It seems like RFC 5014 was more careful in its use of normative language and I think that care is warranted here as well.

>

> (2) RFC 7721 defines a bunch of address types that are somewhat overlapping with the definitions here. RFC 4941 and RFC 8064 provide recommendations for configuration of different address types. How do the address types and recommendations in this document intersect with the address types and recommendations in those documents?

>

>

> ----------------------------------------------------------------------

> COMMENT:

> ----------------------------------------------------------------------

>

> = Section 3.2 =

>

> "A Fixed IP address is an address with a guarantee to be valid for a

>   very long time"

>

> This seems vague. What is a very long time?

>

> = Section 5.1 =

>

> "Applications using the new On-Demand functionality MUST be aware that

>   they may be executed in legacy environments that do not support it."

>

> This should not be a normative recommendation.

>

> = Section 7 =

>

> This section needs to discuss the privacy and security implications of the different address types (see, e.g., RFC 7721 Sections 3 and 4).

>

>

> _______________________________________________

> dmm mailing list

> [e-mail]<mailto:[e-mail]>

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