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:[email protected]]
Sent: Friday, February 22, 2019 19:10
To: Moses, Danny <[email protected]>
Cc: The IESG <[email protected]>; [email protected];
[email protected]; [email protected]; Dapeng Liu <[email protected]>
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
> <[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of Alissa Cooper
> Sent: Thursday, February 21, 2019 16:01
> To: The IESG <[email protected]<mailto:[email protected]>>
> Cc:
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>; Dapeng Liu
> <[email protected]<mailto:[email protected]>>
> 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
> [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
