Re: Evaluation: draft-ietf-mobileip-ipv6 - Mobility Support in IPv6 to Proposed Standard

[Erik Nordmark <Erik.Nordmark@sun.com>]

                    Yes    No-Objection  Discuss *  Abstain  
Erik Nordmark       [   ]     [   ]       [ X ]      [   ] 

I'd like to finish reading it thus I have both a discuss and a defer :-)


Comments on draft-ietf-mobileip-ipv6-21.txt

I've so far only read about half the spec, but overall, especially
given its size, it looks very well written. (I was expecting to see
lots of inconsistencies but find very few.)


Substantial:

Section 2:
   o  The movement detection mechanism in Mobile IPv6 provides
      bidirectional confirmation of a mobile node's ability to
      communicate with its default router in its current location.

But this is not sufficient when there are more than one router
on the visited link. In many cases each of those routers will
be used to forward inbound packets towards the MNs COA.
Thus the fact that the MN knows that it has bidirectional connectivity
with one router on the link is no guarantee for it to be able to
communicate when there are more than one router on the link.
So unless the purpose of this detection in section 11.5.1
is to provide an indication to the MN to do a handover to a different link
I don't see the benefit of this.
The mechanism adds complexity to the notion of reachability beyond what
is done in RFC 2461.

I haven't seen any discussion of the duplicate address detection
changes in section 7.6 in the IPv6 WG.
While these changes seem harmless I'm concerned about them being
included in such a huge specification which makes them less likely
to receive careful review. Can't this be handled separately by a small
specification?

Minor:

The abstract and introduction have text of the flavour:
   This document specifies the operation of the IPv6 Internet with
   mobile computers. 
I think the scope of the specification is quite narrower for instance
it doesn't specify any operational procedures for the Internet.
I think it is more accurate to say e.g.
	This document specifies a protocol which allows IPv6 nodes
	to move around in the Internet while remaining reachable at
	a fixed IPv6 address.

It makes sense to make it more clear that the specification doesn't
prevent a MN from having multiple home addresses.
I suggest clarifying this in the definitions section by:
   home address

      A unicast routable address assigned to a mobile node, used as the
      permanent address of the mobile node.  This address is within the
      mobile node's home link.  Standard IP routing mechanisms will
      deliver packets destined for a mobile node's home address to its
      home link.
ADD   When there are multiple home prefixes on the home link the mobile
      node will have multiple home addresses.

   care-of address

      A unicast routable address associated with a mobile node while
      visiting a foreign link; the subnet prefix of this IP address is a
      foreign subnet prefix.  Among the multiple care-of addresses that
      a mobile node may have at any given time (e.g., with different
      subnet prefixes), the one registered with the mobile node's home
      agent is called its "primary" care-of address.
Change "home agent" to "home agent for a given home address".

Section 5.2.5 says:
      For
      improved security, the data passed between the home agent and the
      mobile node can be made immune to inspection and passive attacks.
      Such protection can be gained by encrypting the home keygen token
      as it is tunneled from the home agent to the mobile node as
      specified in Section 10.4.6.
which reads like an optional thing 
but in 10.4.6 the support for this is mandatory.
Suggest rewording the above by s/can be/is/ in two places in the text.

Section 7.2 and 7.5 are inconsistent.
The former says that routers MAY and the latter says they SHOULD
include at least one R-bit prefix.


Nits:

The document uses the term "byte" about 5 times, and otherwise uses
"octet". Why not use "octet" throughout?

The definition of "registration" vs. "binding procedure" seem confusing.
Are they intended to mean exactly the same thing or something slightly
different? Perhaps the term "registration" isn't needed or the relationship
between the terms can be clarified somehow.

Section 4.1 says:
   Mobile IPv6 also provides support for multiple home agents, and the
   reconfiguration of the home network.

Given that the security aspects of renumbering the home link are not
worked out it makes sense to tone down the language somehow.

Section 4.2 says:
      These four messages are used to initiate the return routability
      procedure from the mobile node to a correspondent node.
I thought "perform" would be more accurate than "initiate"
since the 4 messages is the entirety of the RR procedure, right?

Section 4.2:
   Binding Refresh Request
      A Binding Refresh Request is used to request a mobile node to
      re-establish its binding with the correspondent node.
Hard for a new reader to understand that only CN send BRs (and not e.g.
a HA). Change "used"  to "used by a correspondent node".

Section 4.6:
   Mobile nodes may not be aware of which site they are currently on, it
s/on/in/


Section 6.7 doesn't state whether or not ICMP Mobile Prefix Solicitation 
Messages can carry options. I think RFC 2461 router solicitations can which
is why I think it makes sense to be explicit on this point.

It would be useful to state in section 6.7 and 6.8 respectively
that these are just slightly modified router solicitation and
router advertisement messages to make it more obvious
that they use the RFC 2461 option format etc.

---