Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues
draft-ietf-netlmm-mip-interactions-07

[Ballot comment]
I found the document very difficult to read for the reasons cited in point 1 of the GENART review.

This issue needs to be addressed before publication.

[Ballot comment]
There is one typo in the RFC Editor Note.  The change introduced by the following text is in section 3.2, not section 2.

Still in section 2, in the last bullet of list item 5:

I suspect the RFC Editor would work it out from the context, but suggest making the fix just to be sure.

[Ballot comment]
The OPS-DIR review by Jouni Korhonen raised a number of non-blocking issues, most of them of editorial nature, which should be considered if a new revision of the  document is spun out:

The document mentions that there are system specific issues that need to be taken into account; see Sections 4.2.1 and 4.3. Those are merely bypassed stating being "out of scope". While this is true, from operational and management perspective it would be nice to see even references here for further reading if any of those "out of scope" things have been solved or discussed somewhere. For example Section 4.2.1 depends on LMA discovery to work properly within the same administrative domain. There are solutions for this documented in IETF in PMIPv6 context. Another related nit to point out is that the document could actually mention that the separate HA/LMA functions actually would benefit from a shared subscriber database (e.g. AAA
server) to work properly. The text seems to hint that anyway.


Few editorial comments:

o Section 2 should also say that it uses acronyms from RFC5213 and RFC3775.

o Section 3 add a reference to HMIPv6-MIPv6.

o Sequence number based ordering is possible (optional) for PMIPv6 in
RFC5213 unlike stated in Section 3.2, step 1) first bullet. Not that it would help to solve the issue described here, but using sequence numbers in
PMIPv6 is possible in general as an option.

o Section 3.2 step 4) last bullet I do not understand why it mentions "both host-based and network-based security associations are used to update the same binding cache entry at the HA/LMA" as earlier the scenario has been scoped so that HA & LMA binding caches are separate.

o Section 3.2 -> s/(or binging cache)./(or binding cache).
              -> s/RFC4832, section 2.2/RFC4832, Section 2.2
              -> add a reference to IKEv2 [RFC5996]

o Section 3.3 says the ".. advertising the home link prefix to the MN in a unicast Router Advertisement message." While it makes sense and is typical behavior when a MAG receives a Router Solicitation, it is not necessarily the case always. The MAG can send multicast Router Advertisements when it so decides or send it before receiving a Router Solicitation.

o Section 4.2.1 -> s/MN-HoA.For/MN-HoA. For

o Section 4.2.2 -> s/MAG. the/MAG. The

o Section 4.2.2 could reference to draft-ietf-netlmm-lma-discovery when it discusses about LMA discovery and it not being defined in RFC5213.

o Section 5 reference [pmipv6-draft] should be [RFC5213].

o The document uses both (P)MIPv6 and (Proxy) Mobile IPv6 interchangeably.
It should stick with one style.

o The document uses both BCE and binding cache entry interchangeably. It should stick with one style.

o The document uses both HA and Home Agent interchangeably. It should stick with one style.

o The document uses both HA/LMA and LMA/HA interchangeably. It should stick with one style.

o Most of the acronyms are not expanded on the first use.

[Ballot discuss]
I found the document very difficult to read for the reasons cited in point 1 of the GENART review.

This issue needs to be addressed before publication.

[Ballot comment]
I support Tim's DISCUSS positions.

Some nits:

Section 3, second sentence:
OLD
                                              This document does not
                                                            ^^^^
  only focus on scenarios where the two protocols are used by the same
  mobile node to manage local and global mobility, but it investigates
                                                        ^^
  also more complex scenarios where the protocols are more tightly
  ^^^^
NEW
                                                This document not
  only focuses on scenarios where the two protocols are used by the same
  mobile node to manage local and global mobility, but also investigates
  more complex scenarios where the protocols are more tightly


Section 3, page 9, line 4:
OLD
  depicted in the figure.  However, the LMA and HA can be also
                                                        ^^^^^^^
NEW
  depicted in the figure.  However, the LMA and HA can also be

[Ballot comment]
Nit, in section 3.1: s/regardless/regardless of/

Nit, in section 3.2, list item 3: s/access when/access where/
Also, can you reword "delay in the mobility signaling sent
          may imply adverse situations"; maybe "delay in the receipt
          mobility signaling may result in undesirable situations"?
Still in section 2, in the last bullet of list item 4, I don't understand
          "the threat described in [RFC4832] is worse"; worse than what?

[Ballot discuss]
I have some clarifications I'd like to see in the Security Considerations section.

I don't know exactly what this text means:
  Scenarios A.1 and B described in Section 3 do not introduce any
  security considerations in addition to those described in [pmipv6-
  draft] or [RFC3775].
Does it mean do not identify any security issues?

Des scenario A2 identify any security issues?

Do the solutions in section 4 introduce any security considerations?

[Ballot comment]
Nit, in section 3.1: s/regardless/regardless of/

Nit, in section 3.2, list item 3: s/access when/access where/
Also, can you reword "delay in the mobility signaling sent
          may imply adverse situations"; maybe "delay in the receipt
          mobility signaling may result in undesirable situations"?
Still in section 2, in the last bullet of list item 4, I don't understand
          "the threat described in [RFC4832] is worse"; worse than what?

[Ballot comment]
(1) Section 3.2, list item 4 bullet 3

s/binging/binding/

(2) The final sentence in Section 5 (Security Considerations) is considerably weaker  than the
text in Section 3.2, list item 4 bullet 4.

From section 3.2:
                              Based on this
          consideration, the threat described in [RFC4832] is worse as
          it affects also hosts that are using the LMA/HA as MIPv6 HA
          and are not using PMIPv6.
From section 5:
    Note that the compromised MAG threat described in [RFC4832]
  applies also here.

I suggest that the text in the security considerations be strengthened...

[Ballot discuss]
(1) The security considerations seem incomplete:

(A) there was considerably more detail in the security considerations for one of the five
IDs combined into this draft.  See:

  http://tools.ietf.org/html/draft-giaretta-netlmm-mip-interactions-00#page-21

These issues seem to be relevant.  Perhaps this text should be incorporated?

(B) The text states that there were no new security considerations for Scenarios A.1 or B.
Does the subsequent text pertain to A.2?  It would be good to clarify this.

(2) The security considerations refer to [pmipv6-draft] but this does not appear in the
references section.  It looks like that should be RFC 5213.

[Ballot comment]
Please consider the comments from the Gen-ART Review by Enrico
  Marocco on 12 May 2010.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-netlmm-mip-interactions-06-marocco.txt

[Ballot comment]
(1) Section 3.2, list item 4 bullet 3

s/binging/binding/

(2) The final sentence in Section 5 (Security Considerations) is considerably weaker  than the
text in Section 3.2, list item 4 bullet 4.

From section 3.2:
                              Based on this
          consideration, the threat described in [RFC4832] is worse as
          it affects also hosts that are using the LMA/HA as MIPv6 HA
          and are not using PMIPv6.
From section 5:
    Note that the compromised MAG threat described in [RFC4832]
  applies also here.

I suggest that the text in the security considerations be strengthened...

I have finally made my AD review of this document. Apologies for the delay. Overall, the document was easy to read and I had no major problems. I do want you to revise the document for the following issues, however:

The document should state that the list of scenarios is not exhaustive. (Or convince the reader that the given scenarios are the only possible ones.)

Section 3.2 should talk about how you can identify nodes that get PMIP service and those that don't. This does not seem like a trivial exercise. You can make a policy lookup, but then you rely on the operator knowing what software your device has. I realize that you rule this out of scope later, and I do not ask you to explain the specific mechanisms. I am asking you to outline the implications of having a mechanism.

I would also like the authors to respond to Christian Vogt's review (posted October 1st). I did not see a response, but maybe I missed it.

What about Basavaraj Patil's question in the mailing list on October 21st? Is there a need to add something to the document about his scenario?

>    The solution for this scenario may depend on the access network being
>    able to determine that a particular mobile node wants to use Mobile
>    IPv6. 
Only a "may depend"? How would it otherwise work? I would suggest /s/may depend/depend/

> As described in
> [RFC4877], the identifier of the MN is known by the Home Agent
> after the IKEv2 exchange, but this is not used in the MIPv6
> signaling, nor as a lookup key for the binding cache.

Maybe you should bring that if authentication is performed at the MIP layer (authentication option) then this information is available. In other words, authentication mechanisms differ with respect to the ease that the identifier will be available.

> Since all these steps must be performed by the mobile node before
> sending the Binding Update, they have an impact on the handover
> latency experienced by the MN.  For this reason it is recommended
> that the mobile node establishes the IPsec security association (and
> consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
> still attached to the PMIPv6 domain.

But the steps are configuration tasks, and there is no need to perform them on a per-movement basis. A far better recommendation would be to move the steps to mobile node initialization time or to a periodic process.

> The MAG needs to discover the
> HA/LMA; however the current version of [RFC5213] assumes that the LMA
> is assigned to the MAG or discovered by the MAG when the mobile node
> attaches to the MAG. the exact mechanism is not specified in
> [RFC5213].

I think it would be fair to state somewhere that in configurations where there is just one of these nodes, the discovery is not an issue.

> This document requires that the a home agent that also implements the
> PMIPv6 LMA functionality should allow both the mobile node and the
> authorized MAGs to modify the binding cache entries for the mobile
> node.  Note that the compromised MAG threat described in [RFC4832]
> applies also here.

I would like to see a discussion of what the security policy database entries need to look like in this situation. For instance, is it possible to have such a configuration?

> The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
> (MIPv6) protocols are both deployed in a network require some
> analysis and considerations.  This document describes all identified
> possible scenarios, which require an interaction between PMIPv6 and
> MIPv6 and discusses all issues related to these scenarios.  Solutions
> and recommendations to enable these scenarios are also described.

Clumsy language. Maybe "The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions ..."


>    Some SDOs are also investigating more complex scenarios where the
Expand the term SDO or use some other phrase.

> However, in case there are nodes that implement Mobile IPv6 and want
> to use this protocol, the network must offer MIPv6 service to them.

There is no "MIPv6 service" in this case. It would be better to say, e.g., "must offer plain IP connectivity service without proxy mobility".

>    advertising the HNP, the MAG should advertise the topologically

The term HNP has not appeared before (at least not outside "MN-HNP" which is presumably another term).

> This section highlights some considerations that are applicable to
> scenario C where the LMA and HA are logically collocated and need to
> be evaluated when selecting the technical approach to be chosen.

Complex sentence that seems to be repeating the same thing.

> based on the base specification [RFC3775]

I'm sure there's a better way to write this...

>          ordered by a timestamp option. .

Garbage at the end.

> If a different LMA is
> assigned to the MAG, the mobile node will not be on the home
> link but will still have an active MIPv6 binding cache entry
> and this may be not desirable in some deployments..

Garbage at the end. Please also explain why this is not desirable.

>    LMA hss changed, and therefore the mobile node sends a MIPv6 Binding

s/hss/has/

>    o  The downlink packets in the case where both the MIPv6 binding
>      cache entry and PMIPv6 binding cache entry exist are processed as
>      follows:
>
>    o
>
>      1.  The MIPv6 binding cache entry is processed first.  If the

Odd indentation & bullet style.

Shepherd Write-Up for draft-ietf-netlmm-mip-interactions:

# (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, # does he or she believe this version is ready for forwarding to the IESG for # publication?

Document Shepherd is Vidya Narayanan. I have personally reviewed the document and I believe the document is ready for publication.


# (1.b) Has the document had adequate review both from key WG members and from # key non-WG members? Does the Document Shepherd have any concerns about the # depth or breadth of the reviews that have been performed?

The document has had extensive reviews within the WG. I do not have any concerns about the depth or breadth of reviews received.


# (1.c) Does the Document Shepherd have concerns that the document needs more # review from a particular or broader perspective, e.g., security, operational # complexity, someone familiar with AAA, internationalization or XML?

I have no concerns about the reviews for this document.


# (1.d) Does the Document Shepherd have any specific concerns or issues with # this document that the Responsible Area Director and/or the IESG should be # aware of? For example, perhaps he or she is uncomfortable with certain parts # of the document, or has concerns whether there really is a need for it. In # any event, if the WG has discussed those issues and has indicated that it # still wishes to advance the document, detail those concerns here. Has an # IPR disclosure related to this document been filed? If so, please include a # reference to the disclosure and summarize the WG discussion and conclusion # on this issue.

I have no concerns on the document. There have been no IPR disclosures filed on this document.


# (1.e) How solid is the WG consensus behind this document? Does it # represent the strong concurrence of a few individuals, with others # being silent, or does the WG as a whole understand and agree with it?

There is a strong consensus behind the document.


# (1.f) Has anyone threatened an appeal or otherwise indicated extreme # discontent? If so, please summarise the areas of conflict in separate # email messages to the Responsible Area Director. (It should be in a # separate email because this questionnaire is entered into the ID Tracker.)

Nobody has threatened to appeal and the document is a product of the WG as a whole.


# (1.g) Has the Document Shepherd personally verified that the document # satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and # http://tools.ietf.org/tools/idnits/). Boilerplate checks are not # enough; this check needs to be thorough. Has the document met all formal # review criteria it needs to, such as the MIB Doctor, media type and URI # type reviews?

No ID nit errors are present on the document and the document meets the review criteria.

# (1.h) Has the document split its references into normative and informative?
# Are there normative references to documents that are not ready for # advancement or are otherwise in an unclear state? If such normative # references exist, what is the strategy for their completion? Are there # normative references that are downward references, as described in # [RFC3967]? If so, list these downward references to support the Area # Director in the Last Call procedure for them [RFC3967].

There is a split to normative and informative references. The document has draft-ietf-mip6-bootstrapping-integrated-dhc as a normative reference. This draft is in the RFC editor queue and is expected to be published soon. So, there is no concern on having normative references in an unclear state. There are no downward references in the document.

# (1.i) Has the Document Shepherd verified that the document IANA # consideration section exists and is consistent with the body of the # document? If the document specifies protocol extensions, are reservations # requested in appropriate IANA registries? Are the IANA registries clearly # identified? If the document creates a new registry, does it define the # proposed initial contents of the registry and an allocation procedure for # future registrations? Does it suggest a reasonable name for the new # registry? See [RFC2434]. If the document describes an Expert Review # process has Shepherd conferred with the Responsible Area Director so that # the IESG can appoint the needed Expert during the IESG Evaluation?

There are no actions for IANA in this document. However, an IANA considerations section stating that does exist.


# (1.j) Has the Document Shepherd verified that sections of the document that # are written in a formal language, such as XML code, BNF rules, MIB # definitions, etc., validate correctly in an automated checker?

No formal language segments exist.


# (1.k) The IESG approval announcement includes a Document Announcement # Write-Up. Please provide such a Document Announcement Write-Up? Recent # examples can be found in the "Action" announcements for approved documents.
# The approval announcement contains the following sections:

Technical Summary
The Proxy Mobile IPv6 specification in RFC 5213 describes network based mobility management for IPv6 hosts across IPv6 network domains. This document describes the possible interactions between Proxy Mobile IPv6 and Mobile IPv6. It provides some guidelines on the best practices to use when combining these two protocols to provide mobility for end hosts.

Working Group Summary
There is a consensus in the NETLMM WG for publication as an informational RFC.

Document Quality
The document has gone through various reviews and a successful WGLC.

Personnel
Responsible AD is Jari Arkko and the document shepherd is Vidya Narayanan.