[netlmm] Review of draft-ietf-netlmm-pmip6-ipv4-support-17

[Christian Vogt <christian.vogt at ericsson.com>]

Folks -

I have reviewed draft-ietf-netlmm-pmip6-ipv4-support-17, and I have a
set of comments that I believe should be addressed.  Below are the main
technical and editorial comments.  You find those, plus further and more
detailed comments, at the following link:

http://christianvogt.mailup.net/reviews/2009/draft-ietf-netlmm-pmip6-ipv4-support-17-review-cv.pdf

Main Technical Comments

- The lack of support for NATs on the external side of an LMA is a
   significant limitation, since the run-out of global IPv4 addresses
   will make such placement of NATs inevitable.  Of course, there are
   limitations with the support of NATs on the external side of an LMA,
   such as restricted reachability of mobile nodes.  But even though,
   enabling the support would be worthwhile given the foreseeable
   demand.

- The document is inconsistent with respect to the number of interfaces
   supported per mobile node.  Section 2.2 (“Terminology”) specifies
   that multiple interfaces are supported per mobile node, and that
   separate IPv4 home addresses are used for the interfaces.  However,
   many other parts of the document are written as if there could be
   at most one interface, and therefore one IPv4 home address, per
   mobile node.  This applies in particular to the binding cache
   extensions specified in section 3.1.1 and to the policy profile
   extensions specified in section 3.2.2.  Likewise, the failure code
   MULTI-PLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (“multiple IPv4
   home address assignment not supported”) should be renamed to
   “assignment of multiple IPv4 home addresses per interface not
   supported”.  Suggest revising the document such that it is more
   consistent with regards to the use of multiple interfaces per
   mobile node.

- Section 3 (“IPv4 Home Address Mobility Support”) is unclear on how a
   MAG determines whether a mobile node requires IPv4 home address
   support.  This holds in particular for the first part of section 3.
   Later, section 3 explains that the policy profile may tell whether a
   mobile node requires IPv4 home address support, but even then it is
   unclear whether the policy profile is the only means by which the
   need for IPv4 home address support can be determined.

- Section 3.1.2.4 (“Binding Lifetime Extension (After handoff)”)
   specifies, in its first bullet, that a refresh request for a home
   address of only one IP version must be considered a request to
   remove a home address of the other IP version, if any.  What is the
   motivation for this interpretation?  Wouldn’t it make more sense to
   enable separate refresh requests for home addresses of different IP
   versions?  This would be useful in cases where the home addresses of
   different IP versions have different lifetimes.  In those cases, the
   lifetime for IPv4 home addresses may be shorter than the lifetime
   for IPv6 home addresses -- to minimize the allocation of unused IPv4
   home addresses in the face of IPv4 address shortage --, but one may
   still not want to refresh the lifetime of the IPv6 home address
   every time the IPv4 home address is refreshed.

- Section 3.4. (“Supporting DHCP-Based Address Configuration”) enables
   the use of multiple DHCP servers inside a Proxy Mobile IP domain,
   but gives little guidance on how the DHCP servers are to be
   coordinated.  This coordination is not trivial, and insufficient
   coordination can jeopardize both the uniqueness, and the
   consistency across handovers, of a mobile host’s home address.  To
   ensure that a given mobile host always gets the same home address,
   and to ensure that this home address is not assigned to another
   host, the DHCP configuration profile for the mobile node must be
   static, and multiple DHCP servers need to have a consistent view of
   this profile.  The text touches upon this in a later bullet, but I
   believe that the matter should be given more emphasis.

Main Editorial Comments

- Section 1.1 (“Stated Assumptions”) describes protocol design
   assumptions as part of the protocol overview.  This is not an
   obvious place for the assumptions.  Consider moving the assumptions
   to a separate section.

- Section 3.1.2.2 (“Initial Binding Registration (New Mobility
   Session)”) specifies rules that local mobility anchors must observe
   for the registration of a new mobility session.  The current
   itemization of these rules as a simple list makes it difficult for
   the reader to see which rules must be processed together, and which
   rules are mutually exclusive.  For example, the rules for accepting a
   registration are, editorially, not clearly distinguished from the
   rules for rejecting a registration.  Consider more clearly
   identifying groups of rules, such as a group for accepting a
   registration and groups for the various failure cases.

- Section 3.1.2.4 (“Binding Lifetime Extension (After handoff)”) mixes
   three protocol tasks: registration refreshes, registration removals,
   and tunnel establishment, the latter of which should only be
   necessary in the case of an initial registration.  The specification
   would be easier to understand if those three protocol tasks where
   more clearly distinguished.

A lot of comments, I know, and it will take effort to address them.
But this document is important -- every Proxy Mobile IP deployment will
need it for quite some time to come.  So let's get it right.

- Christian