Subject: [mobile-ip] AD (mostly) editorial comments on draft-ietf-mobileip-ipv6-19.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 11 Nov 2002 16:32:31 -0500

The following are my raw comments on the document. Warning: the list
is very long. :-) Some of the comments may also not make sense, so
please ask before spending too much time scratching your head. But, I
want to get them out ASAP, and it will take me too long I suspect if I
try to make another pass over them in order to wordsmith them better
before sending them here.

>    In order to protect messages exchanged between the mobile node and
>    the home agent with IPsec, appropriate security policy database
>    entries must be created.  A mobile node must be prevented from
>    using its security association to send a Binding Update on behalf
>    of another mobile node using the same home agent.  This MUST be
>    achieved by checking that the given home address has been used with
>    the right security association.  Such a check can be provided in

make clear that this MUST be checked by the HA? (implicit, but better
to say).

>    key management with IKE [9] MAY be supported.  When dynamic keying
>    is used, either the security policy database entries or the MIPv6
>    processing MUST unequivocally identify the IKE phase 1 credentials
>    which can be used to create security associations for a particular
>    home address.

Doesn't the above MUST apply to the spec, i.e., the spec must ensure
the rules are there? Is this the case? :-)  (MUST seems wrong in this
document if it refers to a requirement that this document must
fulfill. )

>   this avoid the need for secure persistent key storage.  Procedures
s/avoid/avoids/

>    The mobile node should use a newly generated random number for each
>    request that carries a home init or care-of init cookie.  The cookies

Random number for what? Are you talking about specific things here,
like a nonce?

>    The care-of address may be set equal to the home address in order to
>    delete a previously established binding In this case, generation of

s/binding/binding./

>   correspondent node keeps track of how long time ago the nonces were

s/time/a time/

> 5.4. Prefix Discovery
> 
>    The mobile node and the home agent must have a security association
>    to protect prefix discovery.  IPsec AH or ESP SHOULD be supported and
>    used for integrity protection.  For ESP, a non-null authentication
>    algorithm MUST be applied.

not MUST? I thought it was MUST be supported, optional to use.

> 6.1. Mobility Header
> 
>    The Mobility Header is an extension header used by mobile nodes,
>    correspondent nodes, and home agents in all messaging related to
>    the creation and management of bindings.  The subsections within
>    this section describe the message types that may be sent using the
>    Mobility Header.

is this a "destination option"? If so, say so.

>          Binding Cache.  A value of all one bits (0xffff) indicates
>          infinity.

Is it wise to allow an infinity value?  Not sure for arbitrary
CNs. But I guess its the CN that is chosing...

> 6.2.1. Format
> 
>    Mobility options are encoded within the remaining space of the
>    Message Data field of a mobility message, using a type-length-value
>    (TLV) format as follows:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Option Type  | Option Length |   Option Data...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       Option Type

Does it make sense to split the option type space into ranges, where <
128 means silently ignore, >=128 send back an error? This might be
useful in the future ...

>    Option Data consists of N-2 zero-valued octets.  Option data MUST be
						     ^
>    ignored by the receiver.

insert "PadN" above.

>          IPsec headers SHOULD be supported and used as described in
>          Section 5.4.

MUST be supported?

>       Home Agent Preference
> 
>          16-bit signed, two's complement integer.  The preference for

Don't see two's complement used that much in on-the-wire
fields... Sure you want to do this, as opposed to making this
unsigned?

>          Agent (H) bit is set, the preference value for this home agent
>          SHOULD be considered to be 0.  Values greater than 0 indicate a
>          home agent more preferable than this default value, and values

seems like a MUST is better for interoperability.

> 8.1. All IPv6 Nodes
> 
>    Any IPv6 node may at any time be a correspondent node of a mobile
>    node, either sending a packet to a mobile node or receiving a packet
>    from a mobile node.  There are no Mobile IPv6 specific requirements
>    for such nodes, and standard IPv6 techniques are sufficient.

Would be good to say (here?) how a node that does MIP RO determines
that a CN doesn't do any MIP extensions. I assume there is a parameter
problem type error, and that the MN needs to respect that response?

> 8.1. All IPv6 Nodes
> 
>    Any IPv6 node may at any time be a correspondent node of a mobile
>    node, either sending a packet to a mobile node or receiving a packet
>    from a mobile node.  There are no Mobile IPv6 specific requirements
>    for such nodes, and standard IPv6 techniques are sufficient.

This is misleading. There are a bunch of SHOULDs (like do RO). It
would be good to say no MUSTs, but there are SHOULDs.

> 9.3.1. Receiving Packets with Home Address Destination Option
> 
>    If the correspondent node has a Binding Cache entry for the home
>    address of a mobile node, packets sent by the mobile node MAY include
>    a Home Address destination option.

MAY is weird. the IF is for something on the CN, but the implication
is for the MN. I'd reword it to say something like the MN is only
allowed to send the Home Address option if the CN has a BCE, as it
will discard it otherwise.

Also, MAY seems wrong. If the MN knows the CN has a BCE, it should
send packets directly. Why MAY?

>    Packets containing a Home Address option MUST also be dropped if
>    there is no corresponding Binding Cache entry for the given home
>    address.  A corresponding Binding Cache entry MUST have the currently
>    registered care-of address equal to the source address of the packet.
>    These tests MUST NOT be done for packets that contain a Binding
>    Update and a Home Address option.

Hmm.

Question. What is the exact algorithm here. Lookup based on HA? Or
lookup based on COA? I.e., can you have multiple HAs using different
COAs? Text should be clear here.

>    Address field there.  After all IPv6 options have been processed, it
>    MUST be possible to process the packet without the knowledge that it
		       ^
>    came originally from a care-of address or that a Home Address option
>    was used.

insert "for upper layers"? And also add, that the information that a
HAO must still be accessible to higher layers that want it, as there
are upper layers that will need access to that information?

>    the presence of a Home Address option.  When attempting to verify
>    authentication data in a packet that contains a Home Address option,
>    the receiving node MUST make the calculation as if the care-of
>    address were present in the Home Address option, and the home address
>    were present in the source IPv6 address field of the IPv6 header.
>    This conforms with the calculation specified in Section 11.3.2.

wording doesn't seem right.

>    Such routers SHOULD be configured with a smaller MinRtrAdvInterval
>    value and MaxRtrAdvInterval value, to allow sending of unsolicited
>    multicast Router Advertisements more often.  Recommended values for
>    these limits are:
> 
>     -  MinRtrAdvInterval       0.05 seconds
> 
>     -  MaxRtrAdvInterval       1.5 seconds

Seems aggressive. MAY would be OK, but not SHOULD.

Might be better to remove the movement detection stuff completely and
put in its own draft.

sectoins 7.5-7.7 are updates to ND. Might be better to pull these out
into their own draft and then reviewed more closely by IPv6. None of
these seem critical to the base MIP spec.

>    of its care-of address.  Assuming there are no additional routing
>    headers in this packet beyond those needed by Mobile IPv6, the mobile
>    node sets the fields in the packet's IPv6 header and routing header
>    as follows:

This description seems overly prescriptive about internal
implementation details. I think it would be better to somehow say
these are the conceptual steps, rather than implying this is what
implementations do. There are other ways of creating the correct
on-the-wire packet.

>    to the correspondent node.  If the correspondent node receives
>    persistent ICMP Destination Unreachable messages after sending
>    packets to a mobile node based on an entry in its Binding Cache, the
>    correspondent node SHOULD delete this Binding Cache entry.

I wonder if more guidance here is useful. It might make more sense to
not discard the entry, but to send both ways. Or do something else
less drastic than delete the entry. But this can probably be added
later easily, so maybe best to just leave this for now. Or add some
words saying more experience is needed here in order to learn what
works well.

> 9.4.1. Receiving Home Test Init Messages
> 
>    Upon receiving a Home Test Init message, the correspondent node
>    verifies the following:

Might be good to add some words here pointing out what a CN does if it
doesn't implement any of this stuff. Presumably, it generates a param
problem message.

Or put this at the very start of the section so that the text covers
all the MIP-specific messages.

> 9.4.2. Receiving Care-of Test Init Messages
> 
>    Upon receiving a Care-of Test Init message, the correspondent node
>    verifies the following:

ditto

>    Any packet carrying a Care-of Test Init message which fails to
>    satisfy all of these tests MUST be silently ignored.

huh? why not an ICMP error of some kind? (Silence will cause the MN to
retransmit with the same message...)

>        mobility option in the Binding Update.  When such message is

s/such/such a/

>        mobility option in the Binding Update.  When such message is
>        received and the return routability procedure is used as an
>        authorization method, the correspondent node MUST verify the
>        authenticator by using the address within the Alternate Care-of
>        Address in the calculations.

is it worth also saying "and in particular MUST NOT use the address in
the source address field".

>    If the mobile node sends a sequence number which is not greater than
>    the sequence number from the last successful Binding Update, then the
>    receiving node MUST send back a Binding Acknowledgement with status
>    code 135, and the last accepted sequence number in the Sequence
>    Number field of the Binding Acknowledgement.

what does the MN do with this info? Can it be used to shrink the
window of acceptable sequence numbers in order to make the tests more
meaningful?

>    Packets carrying Binding Updates that fail to satisfy all of these
>    tests for any reason other than insufficiency of the Sequence Number
>    or expired nonce index values MUST be silently discarded.

why? (I'm concerned about systematic errors where the MN continues to
retransmit a bogus message because it gets no response).

> 9.5.3. Requests to Delete a Binding
> 
>    This section describes the processing of a valid Binding Update that
>    requests a node to delete a mobile node's binding from its Binding
>    Cache, for which the Home Registration (H) bit is not set in the
>    Binding Update.

Note: this section doesn't actually say what message type deletes a
binding. There is a forward reference to this section from elsewhere,
but when I got to this section, I'd  already forgotten the details of
what the messages were like.

>    A Binding Acknowledgement may be sent to indicate receipt of a
>    Binding Update as follows:
> 
>     -  If the Binding Update was silently discarded as described in
>        Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
> 
>     -  Otherwise, if the Acknowledge (A) bit set is set in the Binding
>        Update, a Binding Acknowledgement MUST be sent.
> 
>     -  Otherwise, if the node rejects the Binding Update, a Binding
>        Acknowledgement MUST be sent.
> 
>     -  Otherwise, if the node accepts the Binding Update, a Binding
>        Acknowledgement SHOULD NOT be sent.

I found the above hard to parse. Could it be rewritten to be more
clear when and when not to send BAs?

>    If the Source Address field of the IPv6 header that carried the
>    Binding Update does not contain a unicast address, the Binding
>    Acknowledgement MUST NOT be sent, and the Binding Update packet MUST
>    be silently discarded.  Otherwise, the acknowledgement MUST be sent
>    to the Source Address.  Unlike the treatment of regular packets, this
>    addressing procedure does not use information from the Binding Cache.
> 
>    If the Source Address is the home address of the mobile node, i.e.,
>    the Binding Update did not contain a Home Address destination option,
>    then the Binding Acknowledgement MUST be sent to that address,
>    and the routing header MUST NOT be used.  Otherwise, the Binding
>    Acknowledgement MUST be sent using a type 2 routing header which
>    contains the mobile node's home address.

These two paragraphs are odd. The first one says "don't use the
Binding Cache". the second one says use routing header. But the
routing header is only used in conjunction with the BC. So I think
some more words might be appropriate here...

>    The correspondent node MAY retransmit Binding Refresh Request
>    messages provided that rate limitation is applied.  The correspondent
>    node SHOULD stop retransmitting when it receives a Binding Update.

why not MUST?

>    The rules for maintaining a Binding Cache are same for home

s/are/are the/

>        Agent Lifetime field in the option; otherwise, the lifetime is

s/option/option (if present)/

>    Update as described in Section 5.1.  This includes authorization of
>    the particular node to control a particular home address, as the home
>    address unequivocally identifies the security association that must
>    be used.

Use of the term authorization here is interesting. What is the
authorization step?  Is this oriented  only towards HAs? If so, might
be good to say that.

>    If the Single Address Only (S) bit in the Binding Update is zero,
>    the home agent creates Binding Cache entries for each of possibly
>    several home addresses.  The set of such home addresses is formed
>    by replacing the routing prefix for the given home address with
>    all other routing prefixes on the mobile node's home link that are
>    supported by the home agent processing the Binding Update.  The home
>    agent creates such a separate primary care-of address registration
>    for each such home address.  Note that the same considerations for
>    Duplicate Address Detection apply for each affected home address.
>    The value of the Single Address Only (S) bit field is examined only
>    for new registrations.  Its value is ignored on de-registrations and
>    re-registrations of the same addresses.

The HA can easily know which home addresses a MN has and there is no
need (in general) to continually exchange them. So I'm not sure what
the optimization is aiming to do.

>     -  However, if the Single Address Only (S) bit field in the Binding
>        Update is zero, the lifetime for that Binding Cache entry MUST
>        NOT be greater than the minimum remaining valid lifetime for all
>        subnet prefixes on the mobile node's home link.  If the value of
>        the Lifetime field specified by the mobile node in its Binding
>        Update is greater than this prefix lifetime, the home agent MUST
>        decrease the binding lifetime to less than or equal to the prefix
>        valid lifetime.

Seems like this might play havoc with renumbering, where the lifetime
of a specific prefix is intended to go to 0.

>    field in the Binding Acknowledgement is greater than or equal to 128
>    and the Source Address of the Binding Update is on the home link, the
>    home agent MUST send it to the same link-layer address as the Binding
>    Update came from.

More words above. Sounds like what you want to have  happen is flush
the ND cache and re-run ND. But the words don't say it that way. If
the implication is that you have to kepp the source LL address of the
packet of the  request, that has implications for implementations that
need to be spelled out more.

>     1. The home agent examines the value of the Single Address Only (S)
>        bit in the received Binding Update.  If this bit is nonzero, the
>        next step is carried out only for the individual home address
>        specified for this binding.  If, instead, this bit is zero, then
>        the next step is carried out for one address for each one of the
>        subnet prefixes currently considered by the home agent to be
>        on-link the mobile node.  Each address is formed by replacing,
>        in turn, the configured subnet prefix in the mobile node's home
>        address.  For this purpose, the set of on-link prefixes includes
>        both the link-local and site-local prefix.

the "generate an address for this prefix" bit in the prefix option
seems to be ignored with the wording above (and used throughout). Is
this just an oversight? I.e., one only generates address if the option
has the right bits set to 1.

>    has a Binding Cache entry marked as a home registration.  Note that
>    Binding Update with the Single Address Only (S) bit set to zero will

s/note that/note that a/

>    (after delivering to other local multicast recipients).  Multicast
>    packets addressed to a multicast address with scope larger
>    than link-local but smaller than global (e.g., site-local and
>    organization-local [3]), to which the mobile node is subscribed,
>    SHOULD be tunneled to the mobile node by default.  This behavior MUST

How does a HA know which mcast group a MN has joined?

>     -  When a home agent decapsulates a tunneled packet from the mobile
>        node, the home agent MUST verify that the Source Address in the
>        tunnel IP header is the mobile node's primary care-of address.
>        Otherwise any node in the Internet could send traffic through the
>        home agent and escape ingress filtering limitations.

what other attacks are left open?

>    node.  These messages and the return routability messages employ the
>    same protocol from the point of view of the security policy database,
>    the Mobility Header.  The security policy database entries MUST be

sentence doesn't parse.

>        Agents List.  If it does, delete the corresponding entry.  In any
>        case all of the following steps are skipped.

better: s/entry .../ entry and skip the following steps.../ or somethign

>     -  The Home Agent Addresses field SHOULD contain one global IP
>        address for each home agent currently listed in this home agent's
>        own Home Agents List (Section 10.1).  However, if this home
>        agent's own global IP address would be placed as the first entry
>        in the list (as described below), then this home agent SHOULD NOT

It's architecturally questionable if only one of the routers addresses
should be publicized. If there are multiple global prefixes, there are
reasons for this.

>     -  The Home Agent Addresses field SHOULD contain one global IP
>        address for each home agent currently listed in this home agent's
>        own Home Agents List (Section 10.1).  However, if this home
>        agent's own global IP address would be placed as the first entry
>        in the list (as described below), then this home agent SHOULD NOT
>        include its own address in the Home Agent Addresses field in the
>        Reply message.  Not placing this home agent's own IP address in
>        the list will cause the receiving mobile node to consider this
>        home agent as the most preferred home agent; otherwise, this home
>        agent will be considered to be preferred in its order given by
>        its place in the list returned.

yet another questionable micro-optimization...

>     -  The IP addresses in the Home Agent Addresses field SHOULD
>        be listed in order of decreasing preference values, based
>        either on the respective advertised preference from a Home
>        Agent Information option or on the default preference of 0 if
>        no preference is advertised (or on the configured home agent
>        preference for this home agent itself).

SHOULD should be MUST?? The protocol should require that MNs try in
order, which means the provided order needs to match the requested
preferences. Why would this be a SHOULD?

>     -  For each entry in this home agent's Home Agents List, if more
>        than one global IP address is associated with this list entry,
>        then one of these global IP addresses SHOULD be selected to
>        include in the Home Agent Addresses field in the Reply message.
> 
>        The selected global IP address for each home agent to include in
>        forming the Home Agent Addresses field in the Reply message MUST
>        be the global IP address of the respective home agent sharing a
>        prefix with the Destination IP address of the Request message.
>        If no such global IP address is known for some home agent, an
>        entry for that home agent MUST NOT be included in the Home Agent
>        Addresses field in the Reply message.

This seems broken. By definition, one always shares a prefix. it may
only be the first three bits... But this whole thing above (select one
address, and try to pick the best one) is bad to wire into the base
protocol. 

>     -  If the Reply message packet must be truncated to fit within the
>        minimum IPv6 MTU, and the home agent sending the message is
>        not the highest priority, then its address MUST appear in the
>        list sent to avoid implying that it is the highest priority.
>        Therefore, if this home agent would not appear in the truncated
>        list because it is of lower priority than the last entry, this
>        home agent's address must be substituted for the last entry.

a kludge because of the earlier micro-optimzation...

>    A mobile node on a remote network SHOULD autoconfigure all of the
>    global IP addresses, which it would autoconfigure if it were attached
>    to its home network and which are from prefixes served by home
>    agents.  Site-local addresses MAY be autoconfigured if the mobile
>    node is roaming in a network on the same site as its home addresses.
>    Site-local addresses and addresses not served by a home agent MUST
>    NOT be autoconfigured, since they are unusable in the remote network.

The wording would be much better if it were:

 the messages relayed to the MN are the ones learned via ND on the
 home link. The prefix options are processed as defined in ND (no
 SHOULD about whether  to do this...)

 Site-local stuff is broken, since there is no way of knowing what
 site a node is currently on. Right?

 Addresses not served by the HA should not be autoconfigured? Huh? why
 is the MN learning of addresses not supported by the HA?

>     -  Copy prefix information defined in the home agent's AdvPrefixList
>        on the home subnet's interfaces to the aggregate list.  Also
>        apply any changes made to the AdvPrefixList on the home agent to
>        the aggregate list.
> 
>     -  Check valid prefixes received in Router Advertisements from the
>        home network for consistency with the home agent's AdvPrefixList,
>        as specified in Section 6.2.7 of RFC 2461 [12].  Do not update
>        the aggregate list with any information from received prefixes
>        that fail this check.

Is this enough? It may be that some routers only advertise some of the
info. Does that info also need to get proxied to the MN? (Note: maybe
the ND spec should say different nodes can advertise different things,
but all nodes should be configured to advertise the same info over
time, in case one of the other rouers goes down. I.e., you could have
alternating advertisements with every second message advertising
information X, the other Y. Then you could proxy based entirely on
configured information. This probably ought to be discussed in the
IPv6 WG ...)

>     -  Do not perform consistency checks on valid prefixes received
>        in Router Advertisements on the home network that do not exist
>        in the home agent's AdvPrefixList.  Instead, if the prefixes
>        already exist in the aggregate list, update the prefix lifetime
>        fields in the aggregate list according to the rules specified for
>        hosts in Section 6.3.4 of RFC 2461 [12] and Section 5.5.3 of RFC
>        2462 [13].

seems like info from the routers own AdvPrefixList should not be
overridden by RAs from other routers. If nothing else, there will be
inconsistencies related to lifetimes and clock syncronization issues.

>     -  If the L flag is set on valid prefixes received in a Router
>        Advertisement, and that prefix already exists in the aggregate
>        list, set the flag in the aggregate list.  Ignore the flag if it
>        is clear.

Override info from the routers own config files? Doesn't seem wise.

>    MAY:
> 
>     -  A new prefix is added to the aggregate list.

why not SHOULD or MUST?

>    Suppose that the home agent already has scheduled the transmission
>    of a Mobile Prefix Advertisement to the mobile node.  The home agent
>    deletes the previously scheduled transmission event and schedules
>    another advertisement to the mobile node.

Deletes and reschedules? Seems like "replaces" is what you want, with
the message still going out at the same time as the previously
scheduled one (if not earlier).

>      RAND_ADV_DELAY = MinMobPfxAdvInterval +
>            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))

rand() returns a value between what and what?? (isn't stated).

>    network resources.  The home agent SHOULD periodically continue to
>    retransmit an unsolicited Advertisement to the mobile node, until it
>    is acknowledged by the receipt of a Mobile Prefix Solicitation from
>    the mobile node.

advertisements are acknowledged?

>    If some condition as described above occurs on the home link causes
s/home link/home link and/?
>    another Prefix Advertisement to be sent to the mobile node, before
>   the mobile node acknowledges a previous transmission the home agent

s/transmission/transmission,/

>    -  IPsec headers SHOULD be supported and used.

MUST be supported?? If "supported" means implemented. Need to be sure
MUST implement SHOULD/MAY use.

>     -  Protocols layered over IP will generally treat the mobile node's
>        home address as its IP address for most packets.  For packets
>        sent that are part of transport-level connections established
>        while the mobile node was at home, the mobile node MUST use
>        its home address.  Likewise, for packets sent that are part of
>        transport-level connections that the mobile node may still be
>        using after moving to a new location, the mobile node SHOULD use
>        its home address in this way.  If a binding exists, the mobile
>        node SHOULD send the packets directly to the correspondent node.
>        Otherwise, if a binding does not exist, the mobile node MUST use
>        reverse tunneling.  Detailed operation for both of these cases is
>        described later in this section.

No mention of default-addr-select?

>     -  The mobile node MAY choose to directly use one of its care-of
>        addresses as the source of the packet, not requiring the use
>        of a Home Address option in the packet.  This is particularly
>        useful for short-term communication that may easily be retried
>        if it fails.  An example of this type of communication might
>        be DNS queries sent by the mobile node [27, 28].  Using the

actually, DNS queries may be a bad example, if two-faced DNS is
used...

This document should say that which address to  use is a topic of
future work, as the choices of appropriate address may be application
specific. APIs will need to be developed to give applications better
control over which addresses to use by default....

>     -  While not at its home link, the mobile node MUST NOT use its home
>        address (or the home address destination option) in Neighbor
>        Discovery messages on the visited link.  The mobile node also
>        MUST NOT use its home address when communicating with link-local
>        or site-local peers on the visited link, if the scope of the home
>        address is larger than the scope of the peer's address.

this business about special-casing SL handling seems broken. How do you
know if you are  communicating with a SL address on the local site or
the home site?

>          This is manner of delivering packets does not require going
>          through the home network, and typically will enable faster and

s/This is/This/

>              typically be the mobile node's current primary care-of
>              address, but MUST be a care-of address with a subnet prefix
>              that is on-link on the network interface on which the
>              mobile node will transmit the packet.

Reword to not say "on link" but to say "an address assigned to the
interface on the link being used" or something like that.

>          Reverse tunneled packets MAY be protected using a AH or ESP
>          header, depending on the security policies used by the home
>          agent.  The support for encrypted reverse tunneling allows
>          mobile nodes to defeat certain kinds of traffic analysis, and
>          provides a mechanism by which routers on the home network can
>          distinguish authorized traffic from other possibly malicious
>          traffic.

Is it MAY for data, but SHOULD for RR stuff? The wording could be more
clear. (Or remove the MAY.)

>    For packets received by either the first or last of these three
>    methods, the mobile node SHOULD send a Binding Update to the original
>    sender of the packet, as described in Section 11.7.2, subject to

There are only two methods listed not three...

>     -  The segments left field in the routing header is either 0 or 1.
>        (Values on the wire are always 1.  But implementations may
>        process the routing header so that the value may become 0 after
>        the routing header has been processed, but before the rest of the
>        packet is processed.)

Might be better to reword to say that "verify segments left was 1 on
the packet that comes off the wire...", without going into
implementation specifics.

>    recognize Home Address options.  If a mobile node receives an ICMP
>    Parameter Problem, Code 2, message from some node indicating that it
>    does not support the Home Address option, the mobile node SHOULD log
>    the error and then discard the ICMP message.

Actually, if this happens, shouldn't the MN mark the CN as not
supporting RO at this point?

>    from a new CCoA on each new foreign link.  Any such mechanism,

what's CCoA???

>    its registration is accepted by one of these home agents.  The mobile
>    node MUST, however, wait at least 1.5 times longer than (RetransTimer
>    * DupAddrDetectTransmits) before sending a Binding Update to the next
>    home agent.  In trying each of the returned home agent addresses, the

seems odd to base this off DupAddrDetectTransmits... And the values
here are link-specific, so the MN needs to know what kind of link the
HA is on in order to get these right. Seems like a tall order...

>     -  The packet MUST have a type 2 routing header and SHOULD be
>        protected by an IPsec header as described in Sections 5.4
>        and 6.8.

For received Mobile Prefix Advertisement, why MUST it have a routing
header? Seems like IP in IP tunneling (like for normal packets) would
be acceptable too. Is this the only place where  a HA MUST use a RH?
I.e., if RH is optional for all nodes anyway, why should a HA use them
if tunneling  also does the trick adequately? (Just asking...)

>    Any received Mobile Prefix Advertisement not meeting this test MUST
>    be silently discarded.  For advertisements that do not contain the
>    same ICMP Identifier value as in a recently sent solicitation, the
>    mobile node MUST send a solicitation and expect an advertisement with
>    a matching Identifier before further processing.

reword to say "silently drop" of wrong identifier? Presumably a
retransmission will take place as normal to restart the process...

>    transmitting.  In addition, if the method used for this new home
>    address configuration would require the mobile node to perform
>    Duplicate Address Detection [13] for the new address if the mobile
>    node were located at home, then the mobile node MUST set the
>    Duplicate Address Detection (D) bit in this Binding Update to its
>    home agent, to request the home agent to perform this Duplicate
>    Address Detection on behalf of the mobile node.

Thought: the HA could do DAD on an address in anticipation of it being
configured by a MN. It needn't wait for the MN to say "run DAD". Would
this be a useful optimization?

Also, what happens if DAD fails? Is an ack for the BU delayed until
DAD completes?

>    Since the router SHOULD be sending periodic unsolicited multicast
>    Router Advertisements, the mobile node will have frequent opportunity
>    to check if it is still reachable from its default router, even
>    in the absence of other packets to it from the router.  If Router

not true. there gap between advertisement can be very long. like 30
minutes.

Section 11.5 (movement detection) may be better off in a separate ID.

>    After detecting that it has moved from one link to another (i.e., its
>    current default router has become unreachable and it has discovered
>    a new default router), a mobile node SHOULD form a new primary
>    care-of address using one of the on-link subnet prefixes advertised
>    by the new router.  A mobile node MAY form a new primary care-of

reword. New addresses should be generated using normal mechanisms
(e.g., stateless addrconf, dhc). Nothing more should need to be said.

>    by the new router.  A mobile node MAY form a new primary care-of
>    address at any time, except that it MUST NOT do so too frequently.

Now there is a useful MUST NOT... (not).

>    In addition, after discovering a new on-link subnet prefix, a mobile
>    node MAY form a new (non-primary) care-of address using that subnet
>    prefix, even when it has not switched to a new default router.  A

wording is bad. You can't just generate addresses because they are
onlink. See the addrconf spec.

>    In some cases, a mobile node may already know a (constant) IPv6
>    address that has been assigned to it for its use only while
>    visiting a specific foreign link.  For example, a mobile node may be
>    statically configured with an IPv6 address assigned by the system
>    administrator of some foreign link, for its use while visiting that
>    link.  If so, rather than using Address Autoconfiguration to form a
>    new care-of address using this subnet prefix, the mobile node MAY use
>    its own pre-assigned address as its care-of address on this link.

So, explain to me how the device knows when it is connected to the
specific foreign link where it is allowed to use a particular address,
as opposed to some random link where that address would not work....

>    A mobile node, after forming a new care-of address, MAY begin
>    using the new care-of address without performing Duplicate Address
>    Detection.  Furthermore, the mobile node MAY continue using the
>    address without performing Duplicate Address Detection, although
>    it SHOULD in most cases.  begin Duplicate Address Detection
>    asynchronously when it begins use of the address.  This allows the

Sigh. This is out of scope for this document/WG, I think.

Also, last sentence is not complete.

>    In addition, normal processing for Duplicate Address Detection
>    specifies that, in certain cases, the node SHOULD delay sending the
>    initial Neighbor Solicitation message of Duplicate Address Detection
>    by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13];
>    however, in this case, the mobile node SHOULD NOT perform such a
>    delay in its use of Duplicate Address Detection, unless the mobile
>    node is initializing after rebooting.

Grumble. This should all be in a separate document where it can be
reviewed carefully and done generally.

>    When sending this Binding Update to its home agent, the mobile node
>    must be careful in how it uses Neighbor Solicitation [12] (if needed)
>    to learn the home agent's link-layer address, since the home agent
>    will be currently configured to defend the mobile node's home address
>    for Duplicate Address Detection (DAD). In particular, a Neighbor

not that I know of. DAD allows the DAD initiator to detect
duplicates. Nodes already using an address won't normally detect if
someone else is now trying to use their address.

>    Solicitation from the mobile node using its home address as the
>    Source Address would be detected by the home agent as a duplicate
>    address.  In many cases, Neighbor Solicitation by the mobile node
>    for the home agent's address will not be necessary, since the mobile
>    node may have already learned the home agent's link-layer address,
>    for example from a Source Link-Layer Address option in the Router
>    Advertisement from which it learned that its home address was on-link
>    and that the mobile node had thus returned home.

Not clear. What words in the ND spec would lead to this conclusion?

And what is the HA specifically supposed to do in this case?

>    If the mobile node does Neighbor Solicitation to learn the home
>    agent's link-layer address, in this special case of the mobile node
>    returning home, the mobile node MUST multicast the packet, and in
>    addition set the Source Address of this Neighbor Solicitation to the
>    unspecified address (0:0:0:0:0:0:0:0).  The target of the Neighbor
>    Solicitation MUST be set to the home agent's IPv6 address, which is
>    known to the mobile node.  The destination IP address MUST be set to
>    the Solicited-Node multicast address [3].  The home agent will be
>    unable to distinguish this solicitation from a similar packet that
>    would only be used for DAD, and it will respond as if for DAD. The
>    home agent will send a multicast Neighbor Advertisement back to the
>    mobile node with the Solicited flag (S) set to zero.  The mobile node
>    SHOULD accept this advertisement, and set the state of the Neighbor
>    Cache entry for the home agent to REACHABLE.

I must not understand what all this is about, as it seems to be a bad
idea to me for the MN to need to do the above.

>    After the Mobile Node sends the Binding Update, the Home Agent MUST
>    remove the Proxy Neighbor Cache entry for the Mobile Node and MAY
>    learn its link-layer address based on the link-layer packet or cached
>    information, or if that is not available, it SHOULD send a Neighbor
>    Solicitation with the target address equal to the Binding Update's
>    source IP address.  The Mobile Node MUST then reply with a unicast

why say anything about the LL address? Why doesn't normal ND just
handle this transparently? (especially if the MN does normal ND before
sending the BU to the HA.)

>    Neighbor Advertisement to the Home Agent with its link-layer address.
>    While the Mobile Node is waiting for a Binding Acknowledgement, it
>    MUST NOT respond to any Neighbor Solicitations for its Home Address
>    other than those originating from the IP address to which it sent the
>    Binding Update.

I'm also not sure this is really needed.

>    A mobile node that initiates a return routability procedure MUST
>    send (in parallel) a Home Test Init message and a Care-of Test Init
>    messages.  However, if the mobile node has recently received one or
>    both home or care-of keygen tokens, and associated nonce indices for
>    the desired addresses, it MAY reuse them.  Therefore, the return
>    routability procedure may in some cases be completed with only one
>    message pair.  It may even be completed without any messages at

why a MAY? seems like the client should have sufficient knowledge to
know when to reuse old tokens and when not. Thus, a SHOULD would be
better.

>     -  The home address of the mobile node.  This value will appear in
>        the Source Address field of the Home Test Init message.  When
>        sending the Care-of Test Init message, this address does not
>        appear in the message, but represents the home address for which
>        the binding is desired.

COTI doesn't include Home Address. Does this lead to vulnerabilities?

>    Correspondent nodes from the time before this specification was
>    published may not support the Mobility Header protocol.  These nodes
>    will respond to Home Test Init and Care-of Test Init messages with
>    an ICMP Parameter Problem code 1.  The mobile node SHOULD take such
>    messages as an indication that the correspondent node cannot provide
>    route optimization, and revert back to the use of bidirectional
>    tunneling.

s/SHOULD/MUST/?

>     -  The care-of address for the binding MUST be used as the Source
>        Address in the packet's IPv6 header, unless an Alternate Care-of
>        Address mobility option is included in the Binding Update.  This
>        option MAY be included when the mobile node so desires, and

"This Option" refers to "alternate coa"?

>        MUST be included if the mobile node cannot be assured that the
>        IPsec AH protocol is used to secure the Binding Update.  The ESP

Odd wording. What is mean by "if MN cannot be assured". The MN
certainly knows whether it is using IPsec AH. Right?

>        protocol will not be able to protect care-of addresses in the
>        IPv6 header.  Mobile IPv6 implementations which are unaware of
>        how IPsec secures their messaging will therefore need to use the
>        Alternate Care-of Address option.

>    The Acknowledge (A) bit in the Binding Update requests the home agent
>    to return a Binding Acknowledgement in response to this Binding
>    Update.  As described in Section 6.1.8, the mobile node SHOULD
>    retransmit this Binding Update to its home agent until it receives
>    a matching Binding Acknowledgement.  Once reaching a retransmission
>    timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
>    the process of delivering the Binding Update, but trying instead the
>    next home agent returned during dynamic home agent address discovery
>    (see Section 11.4.1).  If there was only one home agent, the mobile
>    node instead SHOULD continue to periodically retransmit the Binding
>    Update at this rate until acknowledged (or until it begins attempting
>    to register a different primary care-of address).  See Section 11.8
>    for information about retransmitting Binding Updates.

What happens if the HA one is using doens't respond (due to temporary
failure), then the MN starts using another HA. Do the two HAs sync up
with each other?  If so, how (or is this just assumed to magically
happen?)

>    As the set of on-link subnet prefixes on the home link changes over
>    time, the home agent changes the set of home addresses for this
>    mobile node for which it is serving as the home agent.

I hope this means that the MN changes the address it is using and
tells the HA about this. NOt that the HA just does this directly.

>    The last Sequence Number value sent to the home agent in a Binding
>    Update is stored by the mobile node.  If the sending mobile node has
>    no knowledge of the right Sequence Number value, it may start at any
>    value.  If the home agent rejects the value, it sends back a Binding
>    Acknowledgement with status code 135, and the last accepted sequence
>    number in the Sequence Number field of the Binding Acknowledgement.
>    The mobile node MUST store this information and use the next Sequence
>    Number value for the next Binding Update it sends.

So the MN can be forced to use an arbitrary sequence number? Sounds
like a way to defeat anti-replay.

>    While the mobile node is away from home, it relies on the home
>    agent to participate in Duplicate Address Detection (DAD) to defend
>    its home address against stateless autoconfiguration performed by
>    another node.  Therefore, the mobile node SHOULD set the Duplicate
>    Address Detection (D) bit based on any requirements for DAD that
>    would apply to the mobile node if it were at home [12, 13].  If the

why SHOULD vs. MUST? Seems like if you have a node at home using the
same address as a MN, you have a big problem. Why should the MN  be
allowed to disable DAD here?

>    mobile node's recent Binding Update was accepted by the home agent,
>    and the lifetime for that Binding Update has not yet expired, the
>    mobile node SHOULD NOT set the Duplicate Address Detection (D) bit in
>    the new Binding Update; the home agent will already be defending the
>    home address(es) of the mobile node and does not need to perform DAD
>    again.

Are the semantics here right? Are the semantics "do DAD right now" or
are they "Do DAD at all times, including now if you haven't recently"?

Seems complicated to have the MN set DAD sometimes, but sometimes not.

>    The home agent will only perform DAD for the mobile node's home
>    address when the mobile node has supplied a valid binding between
>    its home address and a care-of address.  If some time elapses during
>    which the mobile node has no binding at the home agent, it might
>    be possible for another node to autoconfigure the mobile node's
>    home address.  Therefore, the mobile node MUST treat creation of
>    a new binding with the home agent using an existing home address
>    the same as creation of a new home address.  In the unlikely event
>    that the mobile node's home address is autoconfigured as the IPv6
>    address of another network node on the home network, the home agent
>    will reply to the mobile node's subsequent Binding Update with a
>    Binding Acknowledgement containing a Status of 134 (Duplicate Address
>    Detection failed).  In this case, the mobile node MUST NOT attempt to
>    re-use the same home address.  It SHOULD continue to register care-of
>    addresses for its other home addresses, if any.  The mobile node MAY
>    also attempt to acquire a new home address to replace the one for
>    which Status 134 was received, for instance by using the techniques
>    described in Appendix B.5.

Again, it sounds like the MN is in charge of telling the HA when it
should run DAD. It would seem better for the MN to say "I am assuming
you are doing DAD as appropriate for me" and then let the HA decide
when and when not to run DAD.

>    return routability procedure.  Upon successful return routability
>    procedure and after receiving a successful Binding Acknowledgement

s/succesful/succesful completion of the/

>    After the mobile node has sent a Binding Update to its home
>    agent to register a new primary care-of address (as described in
>    Section 11.7.1), the mobile node SHOULD send a Binding Update to each
>    other node for which an entry exists in the mobile node's Binding
>    Update List, as detailed below.  Typically this requires starting a

Too aggressive.

>    In addition, when a mobile node receives a packet for which the
>    mobile node can deduce that the original sender of the packet either
>    has no Binding Cache entry for the mobile node, or a stale entry
>    for the mobile node in its Binding Cache, the mobile node SHOULD
>    initiate a return routability procedure with the sender, in order to

ditto

>    If the mobile node wants to ensure that its new care-of address
>    has been entered into a correspondent node's Binding Cache, the
>    mobile node MAY request an acknowledgement by setting the Acknowledge
>    (A) bit in the Binding Update.  In this case, however, the mobile
>    node SHOULD NOT continue to retransmit the Binding Update once the
>    retransmission timeout period has reached MAX_BINDACK_TIMEOUT.

why wouldn't a MN retransmit until it either got an ACK, started
receiving packets with an approriate RH, or ICMP param problem?  Seems
odd to have a specific "don't retransmit longer than foo" here. The
implication is that there may be reasons legit why one one wouldn't
get back ANY response, which I hope is not the case.

>    Each Binding Update MUST a Sequence Number greater than the Sequence
>    Number value sent in the previous Binding Update (if any) to the same

missing words

>        Mobile nodes SHOULD send a new Binding Update well before the
>        expiration of this period in order to extend the lifetime.
>        This helps to avoid disruptions in communications, which might
>        otherwise be caused by network delays or clock drift.

Is this enough? Or should there really be more words to be sure that
folk implement sensible policies here...

>     -  If the Status field indicates that the Binding Update was
>        rejected (the Status field is greater than or equal to 128), then
>        the mobile node MUST delete the corresponding Binding Update List
>        entry, and it MUST also stop retransmitting the Binding Update.
>        Optionally, the mobile node MAY then take steps to correct the
>        cause of the error and retransmit the Binding Update (with a new
>        Sequence Number value), subject to the rate limiting restriction
>        specified in Section 11.8.

A lot of the > 128 codes are hard errors. Saying 'delete" the BUL
seems insufficient the MN needs to keep state that no more BUs are to
be sent. Either forever, or for a very very long time (long enough
that its probably better to just say forever, modulo cache cleanup
issues).

>    SHOULD NOT respond Binding Refresh Requests from previously unknown
>    correspondent nodes due to Denial-of-Service concerns.

s/respond/respond to/

>       Binding Update List
> 
>          This list is maintained by each mobile node.  The list has an
>          item for every binding that the mobile node has or is trying
>          to establish with a specific other node.  Both correspondent
>          and home registrations are included in this list.  Entries from
>          the list are deleted as the Lifetime sent in the Binding Update
>          expires.  See Section 11.1.

Does the BUL really contain an item "for every binding that the MN
has", or is it just the ones that are "in progress".

I.e., is BUL a superset of Binding Cache?

I ask because:

> 11.7.4. Receiving Binding Refresh Requests
> 
>    When a mobile node receives a packet containing a Binding Refresh
>    Request message and there already exists a Binding Update List entry
>    for the source of the Binding Refresh Request, it MAY start a return
>    routability procedure.  The mobile node MAY also choose to either

I.e, shouldn't the MB initiate the RR procedure if it gets a request
but also has a BCE for that CN?

>    routability procedure.  The mobile node MAY also choose to either
>    ignore the Binding Refresh Request or to delete its binding from the
>    sender of the Binding Refresh Request.  Note that the mobile node
>    SHOULD NOT respond Binding Refresh Requests from previously unknown
>    correspondent nodes due to Denial-of-Service concerns.

Why would the MB delete an existing binding when it is asked to
refresh it? I can understand that a MN can always delete an entry at
any time, but having words suggesting this  is OK in response to this
message seems rather odd.

>    Instead, if the mobile node chooses to delete its binding from the
>    sender of the Binding Refresh Request, the mobile node SHOULD return
>    a Binding Update to the sender with the Lifetime specified as zero
>    and specify a Care-of Address that matches the home address for the
>    binding.

Again, why  would a MN be doing this? Is the concern that the MN isn't
sending data, so would just as soon expire the entry,  but when it
gets a request to update, it says "sorry"? This seems like an odd
case. Whey would the CN send such a request if it wasn't communicating
with the MN?

11.7.5. Receiving Binding Error Messages

>    When a mobile node receives a packet containing a Binding Error
>    message, it should first check if the mobile node has a Binding
>    Update List entry for the source of the Binding Error message.  If
>    the mobile node does not have such entry, it MUST ignore the message.

s/such entry/such an entry/

>    If the message Status field was 2 (unrecognized MH Type value), the
>    mobile node should perform one of the following two actions:
> 
>     -  If the mobile node is not expecting an acknowledgement or
>        response from the correspondent node, the mobile node SHOULD
>        ignore this message.

Seems like it would be better to (in one place) talk about how to deal
with error messages, that include ICMP param problem. If you get one,
assume CN doesn't speak RO. But ignore these if you aren't actualing
runnin RR with the node, in order to avoid DOS. And never create state
saying "don't do RO" if you aren't already talking to the node? This
stuff is scattered about a bit.

>     -  If the mobile node is sending a Binding Update and it does not
>        have an existing binding at the home agent, it SHOULD use a value
>        for the initial retransmission timer that is at least 1.5 times
>        longer than (RetransTimer * DupAddrDetectTransmits).  This value

where are these defined (should cite ND here I think)? and 1.5 times
this sounds odd. Should be based on RTT between HA and MN (not known)
plus max DAD time. 1.5 times the latter would likely be much larger
than the desired time.

>       HomeRtrAdvInterval       3,600 seconds

What is rational for this number?

>       DHAAD_RETRIES            3 retransmissions

Seems pretty low. 4 transmissions and you lose?

send
wait 2 seconds
send
wait 4
send
wait 8
send
wait 16

total of 30 seconds;  routing hiccups last longer than that...

>       INITIAL_BINDACK_TIMEOUT  1 second

note: not in logical order

Why one second, when default timeout for finding HAs is 2? Seems inconsistent

>       INITIAL_DHAAD_TIMEOUT    2 seconds
>       INITIAL_SOLICIT_TIMER    2 seconds

>    This solicitation follows the same retransmission rules specified for
>    Router Solicitations [12], except that the initial retransmission
>    interval is specified to be INITIAL_SOLICIT_TIMER (see Section 12).

This doesn't seem right. RS solictiations are sent with a fixed
retranstimer. Assumption is local link. Same does not hold for the
above. Seems like one would want to use backoff, and retransmit over a
much longer time period.

Note also that this document sends solicitations under different
scenarios, i.e., when a prefix is about to expire. So it seems like
the MN should try harder and over a longer time period.

>       MAX_ADVERT_REXMIT        3 transmissions

isn't this the same as MAX_NEIGHBOR_ADVERTISEMENT in the ND spec? Why
have a different constant  here? Seems like normal ND rules could be used.

>       MAX_BINDACK_TIMEOUT      256 seconds
>       MaxMobPfxAdvInterval     86,400 seconds

seems like a high number. I don't intuitively understand why this is
so high.

>       MAX_NONCE_LIFE           240 seconds
>       MAX_TOKEN_LIFE           210 seconds
>       MAX_RR_BINDING_LIFE      420 seconds
>       MAX_UPDATE_RATE          once per second
>       MinDelayBetweenRAs       0.05 seconds

>    The value MinDelayBetweenRAs overrides the value of the protocol
>    constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12].

Ouch.

>       MinMobPfxAdvInterval     600 seconds

hmm

>       PREFIX_ADV_RETRIES       3 retransmissions
>       PREFIX_ADV_TIMEOUT       5 seconds

why 5 seconds?

Note: MN->home subnet initial RTTs above are 5, 2 and 1. Seems pretty
arbitrary to me...

>       SLOW_UPDATE_RATE         once per 10 second interval

Not used in the document?

> 13. IANA Considerations
> 
>    This document defines a new IPv6 protocol, the Mobility Header,
>    described in Section 6.1.  This protocol must be assigned a protocol
>    number.  The MH Type field in the Mobility Header is used to indicate
>    a particular type of a message.  The current message types are
>    described in Sections 6.1.2 through 6.1.9, and include the following:

It would be better wording to say "this document creates a new name
space for the Mobility Header Type, that IANA is to
maintain. ... Initial values for the types, as defined in Section
XXX, are:" Or something like that. The keywords are "new namespace"
(and give it a clear name to refer to) that IANA  is to maintain.

Ditto for the TLV option space. Give the name space a name, and make
clear that it is type values IANA is to register/maintain.

>    This document also defines a new IPv6 destination option, the Home
>    Address option, described in Section 6.3.  This option must be
>    assigned an Option Type value.
> 

Section 6.3 says:

>       Option Type
>          201 = 0xC9

Is this right? Has this been assigned? I suspect also that the iana
considerations should say what values for the 3 bits (change on route)
should be, and let IANA pick the other value.

>    This document also defines a new IPv6 type 2 routing header,
>    described in Section 6.4.  The value 2 is to be allocated by IANA
>    when this specification becomes an RFC.

MUST it be  2? Normally IANA assigns what it thinks is a
appropriate. Did you just suggest 2 because its next, or is there a
more compelling reason?

>    In addition, this document defines four ICMP message types, two used
>    as part of the dynamic home agent address discovery mechanism and
>    two used in lieu of Router Solicitations and Advertisements when the
>    mobile node is away from the home link:
> 
>     -  The Home Agent Address Discovery Request message, described in
>        Section 6.5;
> 
>     -  The Home Agent Address Discovery Reply message, described in
>        Section 6.6;
> 
>     -  The Mobile Prefix Solicitation, described in Section 6.7; and
> 
>     -  The Mobile Prefix Advertisement, described in Section 6.8.

out of which range of numbers? Note that the
draft-narten-ipv6-iana-considerations-00.txt says:

> 2.10.  ICMPv6
> 
>    The assignment of ICMPv6 values is defined in [ICMPV6]. (XXX text is
>    not in that ID yet, it also needs to talk about split between error
>    and info messages).

I.e, half the range is for error messages, the other for
request/response messages. IANA needs to know out of which space to
allocate.

>    build an authentication infrastructure on this scale.  Furthermore,
>    a traditional authentication infrastructure cannot be easily
>    used to authenticate IP addresses, because these change often.

s/these/IP addresses can/

   sequence numbers, replay attacks become possible.  he use of a key

s/he/The/

>    this specification limits restricts the generation of new home

extra word?

> 14.4.2. Offered Protection

Don't understand this heading.

>    This procedure protects Binding Updates against all attackers
>    who are unable to monitor the path between the home agent and the

What is "this procedure"?

>    attacker to become a MitM. (Since IPv6 communications are relatively
>    well protected against off-path attackers, it is important that
>    Mobile IPv6 prevents off-path attacks as well.)

This statement might raise some eyebrows... Kind of over general and
meaningless.. 

>    happens even if the attacker moves away from the link.  In regular
>    IPv6, the attacker generally has to be stay on the link in order to
>    continue the attack.  Note that in order to launch these new attacks,
>    the IP address of the victim must be known.  This makes this attack
>    feasible mainly in the context of well-known interface IDs, such as
>    those already appearing in the traffic on the link or registered in
>    the DNS.

I'm having trouble following what is meant here.

>        For this reason, this specification limits the creation of
>        bindings to at most MAX_TOKEN_LIFE seconds after the last
>        routability check has been performed, and limits the duration of
>        a binding to at most MAX_RR_BINDING_LIFE seconds.  With these
>        limitation, attackers cannot take practical advantages of this
>        vulnerability.  This limited vulnerability can also be compared
>        to similar vulnerabilities in IPv6 Neighbor Discovery, with
>        Neighbor Cache entries having a limited lifetime.

But the document also says:

>       Lifetime
> 
>          The granted lifetime, in time units of 4 seconds, for which
>          this node SHOULD retain the entry for this mobile node in its
>          Binding Cache.  A value of all one bits (0xffff) indicates
>          infinity.

>        routability procedure the easiest route for attackers.  For this
>        reason, this specification should have a protection mechanism for
>        selecting between return routability and potential other future
>        mechanisms.

But it doesn't ...

>    We also require that all implementations MUST allow route
>    optimization to be administratively enabled or disabled.  The default
>    SHOULD be enabled.

Is similar  text also given elsewhere (I don't recall seeing it). If
its only in the security considerations section, an implementor may
miss doing this...

NOte: this spec requires AH be used. First example where ESP with
authentication is not sufficient. This has implications on the AH
vs. ESP debate.

> Chairs' Addresses
> 
>    The Working Group can be contacted via its current chairs:

Not sure why some people put in this info. IN this case, gab isn't
mentioned...