Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis

[[e-mail] (Arnaud Ebalard)]

Hi,

"Laganier, Julien" <[e-mail]> writes:

> There was only one review of the draft RFC3775bis so far and we need
> more to send this document to IESG thus we decided to extend the
> WGLC. 
>
> Please review the specification and post a message to the mailing list
> if you think the document is ready to be forwarded to IESG before
> 2009-09-11 6:00PM EST.

Below is a complete review of draft-ietf-mext-rfc3775bis-04. This took
me longer than expected ... maybe due to the size of the document ;-)

Even if I would have liked an explicit reference to MIGRATE mechanism
(useful to understand the need and give an example of possible
solution), some changes on the K-bit and some more words on the lack of 
security of Home Link Detection mechanism ... I think the draft is ready
to be forwarded to IESG.

There are many typos and small additional issues raised in the
review. Most of them will probably be there for the records, though. 

> 3.2.  Mobile IPv6 Terms
> 
> [snip]
>
>    L2 handover
> 
>       A process by which the mobile node changes from one link-layer
>       connection to another.  For example, a change of wireless access
>       point is an L2 handover.

     s/an L2 handover/a L2 handover/ ?

>    L3 handover
> 
>       Subsequent to an L2 handover, a mobile node detects a change in an

     s/an L2 handover/a L2 handover/ ?

>       on-link subnet prefix that would require a change in the primary
>       care-of address.  For example, a change of access router
>       subsequent to a change of wireless access point typically results
>       in an L3 handover.

     s/an L3 handover/a L3 handover/ ?

> 4.1.  Basic Operation
> 
>    A mobile node is always expected to be addressable at its home
>    address, whether it is currently attached to its home link or is away
>    from home.  The "home address" is an IP address assigned to the
>    mobile node within its home subnet prefix on its home link.  While a
>    mobile node is at home, packets addressed to its home address are
>    routed to the mobile node's home link, using conventional Internet
>    routing mechanisms.
> 
>    While a mobile node is attached to some foreign link away from home,
>    it is also addressable at one or more care-of addresses.  A care-of
>    address is an IP address associated with a mobile node that has the
>    subnet prefix of a particular foreign link.  The mobile node can
>    acquire its care-of address through conventional IPv6 mechanisms,
>    such as stateless or stateful auto-configuration.  As long as the
>    mobile node stays in this location, packets addressed to this care-of
>    address will be routed to the mobile node.  The mobile node may also
>    accept packets from several care-of addresses, such as when it is
>    moving but still reachable at the previous link.
> 
>    The association between a mobile node's home address and care-of
>    address is known as a "binding" for the mobile node.  While away from
>    home, a mobile node registers its primary care-of address with a
>    router on its home link, requesting this router to function as the
>    "home agent" for the mobile node.  The mobile node performs this
>    binding registration by sending a "Binding Update" message to the
>    home agent.  The home agent replies to the mobile node by returning a
>    "Binding Acknowledgement" message.  The operation of the mobile node
>    is specified in Section 11, and the operation of the home agent is
>    specified in Section 10.
> 
>    Any node communicating with a mobile node is referred to in this
>    document as a "correspondent node" of the mobile node, and may itself
>    be either a stationary node or a mobile node.  Mobile nodes can
>    provide information about their current location to correspondent
>    nodes.  This happens through the correspondent registration.  As a
>    part of this procedure, a return routability test is performed in
>    order to authorize the establishment of the binding.  The operation
>    of the correspondent node is specified in Section 9.
> 
>    There are two possible modes for communications between the mobile
>    node and a correspondent node.  The first mode, bidirectional
>    tunneling, does not require Mobile IPv6 support from the
>    correspondent node and is available even if the mobile node has not
>    registered its current binding with the correspondent node.  Packets
>    from the correspondent node are routed to the home agent and then
>    tunneled to the mobile node.  Packets to the correspondent node are
>    tunneled from the mobile node to the home agent ("reverse tunneled")
>    and then routed normally from the home network to the correspondent
>    node.  In this mode, the home agent uses proxy Neighbor Discovery to
>    intercept any IPv6 packets addressed to the mobile node's home
>    address (or home addresses) on the home link.  Each intercepted
>    packet is tunneled to the mobile node's primary care-of address.
>    This tunneling is performed using IPv6 encapsulation [9].
> 
>    The second mode, "route optimization", requires the mobile node to
>    register its current binding at the correspondent node.  Packets from
>    the correspondent node can be routed directly to the care-of address
>    of the mobile node.  When sending a packet to any IPv6 destination,
>    the correspondent node checks its cached bindings for an entry for
>    the packet's destination address.  If a cached binding for this
>    destination address is found, the node uses a new type of IPv6
>    routing header [8] (see Section 6.4) to route the packet to the
>    mobile node by way of the care-of address indicated in this binding.
> 
>    Routing packets directly to the mobile node's care-of address allows
>    the shortest communications path to be used.  It also eliminates
>    congestion at the mobile node's home agent and home link.  In
>    addition, the impact of any possible failure of the home agent or
>    networks on the path to or from it is reduced.

not any, only a temporary failure.

> 4.2.  New IPv6 Protocol
> 
>    Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
>    (see Section 6.1).  This Header is used to carry the following
>    messages:
> 
>    Home Test Init
> 
>    Home Test
> 
>    Care-of Test Init
> 
>    Care-of Test
> 
>       These four messages are used to perform the return routability
>       procedure from the mobile node to a correspondent node.  This
>       ensures authorization of subsequent Binding Updates, as described
>       in Section 5.2.5.
> 
>    Binding Update
> 
>       A Binding Update is used by a mobile node to notify a
>       correspondent node or the mobile node's home agent of its current
>       binding.  The Binding Update sent to the mobile node's home agent
>       to register its primary care-of address is marked as a "home
>       registration".
> 
>    Binding Acknowledgement
> 
>       A Binding Acknowledgement is used to acknowledge receipt of a
>       Binding Update, if an acknowledgement was requested in the Binding
>       Update, the binding update was sent to a home agent, or an error
>       occurred.

As a binding update sent to a Home Agent must have the A bit set
(i.e. "an acknowledgement was requested in the Binding Update" as
stated above), a BA is always sent by the HA. This means the "the
binding update was sent to a home agent" is redundant in previous
paragraph.

> 4.6.  Unique-Local Addressability
> 
>    This specification requires that home and care-of addresses MUST be
>    unicast routable addresses.  Unique-local IPv6 unicast addresses
>    RFC4193 [22] may be usable on networks that use such non-globaly

                                            s/non-globaly/non-globally/

>    routable addresses but this specification does not define when such
>    usage is safe and when it is not.  Mobile nodes may not be aware of
>    which site they are currently making it hard to prevent accidental

                       s/currently/currently in/

>    attachment to other sites, resulting in possible unrechability
>    between the MN and the HA, when unique-local IPv6 routable addresses
>    are used as care-of addresses.  Also, CNs outside the MN's own site
>    are not going to be reachable when unique-local IPv6 routable
>    addresses are used as home addresses.  Therefore, unique-local IPv6
>    unicast addresses SHOULD NOT be used as home or care-of addresses.

If this is the only address usable as a CoA for the node, it is worth
trying to use it. I tried and found some discussion on the list about
this topic but failed (I thought it had been discussed). Can someone
give me some feedback on the reason it is that way?

> 5.1.  Binding Updates to Home Agents
> 
>    The mobile node and the home agent MUST use an IPsec security
>    association to protect the integrity and authenticity of the Binding
>    Updates and Acknowledgements.  Both the mobile nodes and the home
>    agents MUST support and SHOULD use the Encapsulating Security Payload
>    (ESP) [4] header in transport mode and MUST use a non-NULL payload
>    authentication algorithm to provide data origin authentication,
>    connectionless integrity and optional anti-replay protection.  Note
>    that Authentication Header (AH) [3] is also possible but for brevity
>    not discussed in this specification.
> 
>    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 having the home agent check that the given home address has been
>    used with the right security association.  Such a check is provided
>    in the IPsec processing, by having the security policy database
>    entries unequivocally identify a single security association for
>    protecting Binding Updates between any given home address and home
>    agent.  In order to make this possible, it is necessary that the home
>    address of the mobile node is visible in the Binding Updates and
>    Acknowledgements.  The home address is used in these packets as a
>    source or destination, or in the Home Address Destination option or
>    the type 2 routing header.
> 
>    As with all IPsec security associations in this specification, manual
>    configuration of security associations MUST be supported.  The used
>    shared secrets MUST be random and unique for different mobile nodes,
>    and MUST be distributed off-line to the mobile nodes.
> 
>    Automatic key management with IKE [7] MAY be supported.  When IKE

Any reason not to add a link to IKEv2 spec?

>    Reference [15] contains a more detailed description and examples on
>    using IPsec to protect the communications between the mobile node and
>    the home agent.

What about adding a link to 4877 too?

> 5.2.5.  Return Routability Procedure
> 
> [snip]
>
>        home keygen token :=
>             First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
> 
> 
>       where | denotes concatenation.  The final "0" inside the HMAC_SHA1
>       function is a single zero octet, used to distinguish home and
>       care-of cookies from each other.
> 
>       The home keygen token is formed from the first 64 bits of the MAC.
>       The home keygen token tests that the mobile node can receive were 
>       messages sent to its home address.

The 'were' in previous sentence should be removed, i.e. it should be
"can receive messages sent to its home address".

> 5.3.  Dynamic Home Agent Address Discovery
> 
>    No security is required for dynamic home agent address discovery.

May be it is the way I understanded it but this sounds like "no security
is needed". It should sounds like "No security is provided for that
mechanism". 

> 5.5.  Payload Packets
> 
>    Payload packets exchanged with mobile nodes can be protected in the
>    usual manner, in the same way as stationary hosts can protect them.
>    However, Mobile IPv6 introduces the Home Address destination option,
>    a routing header, and tunneling headers in the payload packets.  In
>    the following we define the security measures taken to protect these,
>    and to prevent their use in attacks against other parties.
> 
>    This specification limits the use of the Home Address destination
>    option to the situation where the correspondent node already has a
>    Binding Cache entry for the given home address.  This avoids the use
>    of the Home Address option in attacks described in Section 15.1.
> 
>    Mobile IPv6 uses a Mobile IPv6 specific type of a routing header.

                                                s/of a/of/

>    This type provides the necessary functionality but does not open
>    vulnerabilities discussed in Section 15.1.

What about adding a link to RFC5095 here, i.e. "Section 15.1 and
[RFC5095]".

> 6.1.7.  Binding Update Message
> 
>    The Binding Update (BU) message is used by a mobile node to notify
>    other nodes of a new care-of address for itself.  Binding Updates are
>    sent as described in Section 11.7.1 and Section 11.7.2.
> 
>    The Binding Update uses the MH Type value 5.  When this value is
>    indicated in the MH Type field, the format of the Message Data field
>    in the Mobility Header is as follows:
> 
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |          Sequence #           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |A|H|L|K|        Reserved       |           Lifetime            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        .                                                               .
>        .                        Mobility options                       .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Acknowledge (A)
> 
>       The Acknowledge (A) bit is set by the sending mobile node to
>       request a Binding Acknowledgement (Section 6.1.8) be returned upon
>       receipt of the Binding Update.
> 
>    Home Registration (H)
> 
>       The Home Registration (H) bit is set by the sending mobile node to
>       request that the receiving node should act as this node's home
>       agent.  The destination of the packet carrying this message MUST
>       be that of a router sharing the same subnet prefix as the home
>       address of the mobile node in the binding.

This prevents the MN to communicates with the HA on another
interface. Is there any reason for that limitation, i.e. not having a
SHOULD here instead of a MUST. Or I should ask, what is the reason to
have a MUST here.

For instance, the main connectivity of the home agent can be provided by
a given provided (symmetric line) while the MN are on a subnet for which
the prefix is provided by another provider. That way, the download
bandwidth used by the MNs is not shared with the upload bandwidth:

     ISP1 -- home subnet ---[HA]--- ISP2

>    Link-Local Address Compatibility (L)
> 
>       The Link-Local Address Compatibility (L) bit is set when the home
>       address reported by the mobile node has the same interface
>       identifier as the mobile node's link-local address.
> 
>    Key Management Mobility Capability (K)

For the records, I still think K-bit is just a way to prevent user to be
guaranteed to have an IKE daemon which is not half-modified to support
MIPv6 (bootstrapping of transport SA setup but no support for IKE SA 
endpoints update upon movement).

>       If this bit is cleared, the protocol used for establishing the
>       IPsec security associations between the mobile node and the home
>       agent does not survive movements.  It may then have to be rerun.
>       (Note that the IPsec security associations themselves are expected
>       to survive movements.)  If manual IPsec configuration is used, the
>       bit MUST be cleared.
> 
>       This bit is valid only in Binding Updates sent to the home agent,
>       and MUST be cleared in other Binding Updates.  Correspondent nodes
>       MUST ignore this bit.
> 
>    Reserved
> 
>       These fields are unused.  They MUST be initialized to zero by the
>       sender and MUST be ignored by the receiver.
> 
>    Sequence #
> 
>       A 16-bit unsigned integer used by the receiving node to sequence
>       Binding Updates and by the sending node to match a returned
>       Binding Acknowledgement with this Binding Update.
> 
>    Lifetime
> 
>       16-bit unsigned integer.  The number of time units remaining
>       before the binding MUST be considered expired.  A value of zero
>       indicates that the Binding Cache entry for the mobile node MUST be
>       deleted.  (In this case the specified care-of address MUST also be
>       set equal to the home address.)  One time unit is 4 seconds.
> 
>    Mobility Options
> 
>       Variable-length field of such length that the complete Mobility
>       Header is an integer multiple of 8 octets long.  This field
>       contains zero or more TLV-encoded mobility options.  The encoding
>       and format of defined options are described in Section 6.2.  The
>       receiver MUST ignore and skip any options which it does not
>       understand.
> 
>       The following options are valid in a Binding Update:
> 
>       *  Binding Authorization Data option (this option is mandatory in
>          Binding Updates sent to a correspondent node)
> 
>       *  Nonce Indices option.
> 
>       *  Alternate Care-of Address option
> 
>    If no options are present in this message, 4 octets of padding are
>    necessary and the Header Len field will be set to 1.
> 
>    The care-of address is specified either by the Source Address field
>    in the IPv6 header or by the Alternate Care-of Address option, if
>    present.  The care-of address MUST be a unicast routable address.
>    IPv6 Source Address MUST be a topologically correct source address.
>    Binding Updates for a care-of address which is not a unicast routable
>    address MUST be silently discarded.  Similarly, the Binding Update
>    MUST be silently discarded if the care-of address appears as a home
>    address in an existing Binding Cache entry, with its current location
>    creating a circular reference back to the home address specified in
>    the Binding Update (possibly through additional entries).
> 
>    The deletion of a binding can be indicated by setting the Lifetime
>    field to 0 and by setting the care-of address equal to the home
>    address.  In deletion, the generation of the binding management key
>    depends exclusively on the home keygen token, as explained in
>    Section 5.2.5.  (Note that while the senders are required to set both
>    the Lifetime field to 0 and the care-of address equal to the home
>    address, Section 9.5.1 rules for receivers are more liberal, and
>    interpret either condition as a deletion.)

For the records: 

There is no rationale for explicitly providing different behavior for
senders and receivers. The various rules associated with what can and
should be done on that aspects are spread at various places in the
spec. I already discussed that in draft-ebalard-mext-hld-security-00.

> 6.1.8.  Binding Acknowledgement Message
> 
>    The Binding Acknowledgement is used to acknowledge receipt of a
>    Binding Update (Section 6.1.7).  This packet is sent as described in
>    Section 9.5.4 and Section 10.3.1.
> 
>    The Binding Acknowledgement has the MH Type value 6.  When this value
>    is indicated in the MH Type field, the format of the Message Data
>    field in the Mobility Header is as follows:
> 
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |    Status     |K|  Reserved   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |           Sequence #          |           Lifetime            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        .                                                               .
>        .                        Mobility options                       .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Key Management Mobility Capability (K)
> 
>       If this bit is cleared, the protocol used by the home agent for
>       establishing the IPsec security associations between the mobile
>       node and the home agent does not survive movements.  It may then
>       have to be rerun.  (Note that the IPsec security associations
>       themselves are expected to survive movements.)
> 
>       Correspondent nodes MUST set the K bit to 0.
> 
>    Reserved
> 
>       These fields are unused.  They MUST be initialized to zero by

        This field is unused. It MUST be 

> 6.1.9.  Binding Error Message
> 
>    The Binding Error (BE) message is used by the correspondent node to
>    signal an error related to mobility, such as an inappropriate attempt
>    to use the Home Address destination option without an existing
>    binding; see Section 9.3.3 for details.
> 
>    The Binding Error message uses the MH Type value 7.  When this value
>    is indicated in the MH Type field, the format of the Message Data
>    field in the Mobility Header is as follows:
> 
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |     Status    |   Reserved    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                          Home Address                         +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                               .
>        .                        Mobility Options                       .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Status
> 
>       8-bit unsigned integer indicating the reason for this message.
>       The following values are currently defined:
> 
>            1  Unknown binding for Home Address destination option
> 
>            2  Unrecognized MH Type value
> 
>    Reserved
> 
>       A 8-bit field reserved for future use.  The value MUST be
>       initialized to zero by the sender, and MUST be ignored by the
>       receiver.
> 
>    Home Address
> 
>       The home address that was contained in the Home Address
>       destination option.  The mobile node uses this information to
>       determine which binding does not exist, in cases where the mobile
>       node has several home addresses.
> 
>    Mobility Options
> 
>       Variable-length field of such length that the complete Mobility
>       Header is an integer multiple of 8 octets long.  This field
>       contains zero or more TLV-encoded mobility options.  The receiver
>       MUST ignore and skip any options which it does not understand.
> 
>       There MAY be additional information, associated with this Binding
>       Error message that need not be present in all Binding Error
>       messages sent.  Mobility options allow future extensions to the
>       format of the format of the Binding Error message to be defined.

      s/format of the format/format/

>       The encoding and format of defined options are described in
>       Section 6.2.  This specification does not define any options valid
>       for the Binding Error message.
> 
>    If no actual options are present in this message, no padding is
>    necessary and the Header Len field will be set to 2.
> 
> 6.2.  Mobility Options
> 
>    Mobility messages can include zero or more mobility options.  This
>    allows optional fields that may not be needed in every use of a
>    particular Mobility Header, as well as future extensions to the
>    format of the messages.  Such options are included in the Message
>    Data field of the message itself, after the fixed portion of the
>    message data specified in the message subsections of Section 6.1.
> 
>    The presence of such options will be indicated by the Header Len of
>    the Mobility Header.  If included, the Binding Authorization Data
>    option (Section 6.2.7) MUST be the last option and MUST NOT have
>    trailing padding.  Otherwise, options can be placed in any order.
> 
> 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
> 
>       8-bit identifier of the type of mobility option.  When processing
>       a Mobility Header containing an option for which the Option Type
>       value is not recognized by the receiver, the receiver MUST quietly
>       ignore and skip over the option, correctly handling any remaining
>       options in the message.
> 
>    Option Length
> 
>       8-bit unsigned integer, representing the length in octets of the
>       mobility option, not including the Option Type and Option Length
>       fields.
> 
>    Option Data
> 
>       A variable length field that contains data specific to the option.
> 
>    The following subsections specify the Option types which are
>    currently defined for use in the Mobility Header.
> 
>    Implementations MUST silently ignore any mobility options that they
>    do not understand.
> 
>    Mobility options may have alignment requirements.  Following the
>    convention in IPv6, these options are aligned in a packet so that
>    multi-octet values within the Option Data field of each option fall
>    on natural boundaries (i.e., fields of width n octets are placed at
>    an integer multiple of n octets from the start of the header, for n =
>    1, 2, 4, or 8) [8].
> 
> 6.2.2.  Pad1
> 
>    The Pad1 option does not have any alignment requirements.  Its format
>    is as follows:
> 
>         0
>         0 1 2 3 4 5 6 7
>        +-+-+-+-+-+-+-+-+
>        |   Type = 0    |
>        +-+-+-+-+-+-+-+-+
> 
>    NOTE! the format of the Pad1 option is a special case - it has
>    neither Option Length nor Option Data fields.
> 
>    The Pad1 option is used to insert one octet of padding in the
>    Mobility Options area of a Mobility Header.  If more than one octet
>    of padding is required, the PadN option, described next, should be
>    used rather than multiple Pad1 options.
> 
> 6.2.3.  PadN
> 
>    The PadN option does not have any alignment requirements.  Its format
>    is as follows:
> 
>         0                   1
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
>        |   Type = 1    | Option Length | Option Data
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
> 
>    The PadN option is used to insert two or more octets of padding in
>    the Mobility Options area of a mobility message.  For N octets of
>    padding, the Option Length field contains the value N-2, and the
>    Option Data consists of N-2 zero-valued octets.  PadN Option data
>    MUST be ignored by the receiver.
> 
> 6.2.4.  Binding Refresh Advice
> 
>    The Binding Refresh Advice option has an alignment requirement of 2n.
>    Its format is 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
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = 2    |   Length = 2  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       Refresh Interval        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The Binding Refresh Advice option is only valid in the Binding
>    Acknowledgement, and only on Binding Acknowledgements sent from the
>    mobile node's home agent in reply to a home registration.  The
>    Refresh Interval is measured in units of four seconds, and indicates
>    remaining time until the mobile node SHOULD send a new home
>    registration to the home agent.  The Refresh Interval MUST be set to
>    indicate a smaller time interval than the Lifetime value of the
>    Binding Acknowledgement.
> 
> 6.2.5.  Alternate Care-of Address
> 
>    The Alternate Care-of Address option has an alignment requirement of
>    8n+6.  Its format is 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
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = 3    |  Length = 16  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                   Alternate Care-of Address                   +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Normally, a Binding Update specifies the desired care-of address in
>    the Source Address field of the IPv6 header.  However, this is not
>    possible in some cases, such as when the mobile node wishes to
>    indicate a care-of address which it cannot use as a topologically
>    correct source address (Section 6.1.7 and Section 11.7.2) or when the
>    used security mechanism does not protect the IPv6 header
>    (Section 11.7.1).
> 
>    The Alternate Care-of Address option is provided for these
>    situations.  This option is valid only in Binding Update.  The
>    Alternate Care-of Address field contains an address to use as the
>    care-of address for the binding, rather than using the Source Address
>    of the packet as the care-of address.
> 
> 6.2.6.  Nonce Indices
> 
>    The Nonce Indices option has an alignment requirement of 2n.  Its
>    format is 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
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = 4    |   Length = 4  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Home Nonce Index      |     Care-of Nonce Index       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The Nonce Indices option is valid only in the Binding Update message
>    sent to a correspondent node, and only when present together with a
>    Binding Authorization Data option.  When the correspondent node
>    authorizes the Binding Update, it needs to produce home and care-of
>    keygen tokens from its stored random nonce values.
> 
>    The Home Nonce Index field tells the correspondent node which nonce
>    value to use when producing the home keygen token.
> 
>    The Care-of Nonce Index field is ignored in requests to delete a
>    binding.  Otherwise, it tells the correspondent node which nonce
>    value to use when producing the care-of keygen token.
> 
> 6.2.7.  Binding Authorization Data
> 
>    The Binding Authorization Data option does not have alignment
>    requirements as such.  However, since this option must be the last
>    mobility option, an implicit alignment requirement is 8n + 2.  The
>    format of this option is 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
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = 5    | Option Length |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                         Authenticator                         |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The Binding Authorization Data option is valid in the Binding Update
>    and Binding Acknowledgement.
> 
>    The Option Length field contains the length of the authenticator in
>    octets.
> 
>    The Authenticator field contains a cryptographic value which can be
>    used to determine that the message in question comes from the right
>    authority.  Rules for calculating this value depends on the used
>    authorization procedure.
> 
>    For the return routability procedure, this option can appear in the
>    Binding Update and Binding Acknowledgements.  Rules for calculating
>    the Authenticator value are the following:
> 
>      Mobility Data = care-of address | correspondent | MH Data
>      Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
> 
>    Where | denotes concatenation.  "Care-of address" is the care-of
>    address which will be registered for the mobile node if the Binding
>    Update succeeds, or the home address of the mobile node if this
>    option is used in de-registration.  Note also that this address might
>    be different from the source address of the Binding Update message,
>    if the Alternative Care-of Address mobility option is used, or when
>    the lifetime of the binding is set to zero.
> 
>    The "correspondent" is the IPv6 address of the correspondent node.
>    Note that, if the message is sent to a destination which is itself
>    mobile, the "correspondent" address may not be the address found in
>    the Destination Address field of the IPv6 header; instead the home
>    address from the type 2 Routing header should be used.
> 
>    "MH Data" is the content of the Mobility Header, excluding the
>    Authenticator field itself.  The Authenticator value is calculated as
>    if the Checksum field in the Mobility Header was zero.  The Checksum
>    in the transmitted packet is still calculated in the usual manner,
>    with the calculated Authenticator being a part of the packet
>    protected by the Checksum.  Kbm is the binding management key, which
>    is typically created using nonces provided by the correspondent node
>    (see Section 9.4).  Note that while the contents of a potential Home
>    Address destination option are not covered in this formula, the rules
>    for the calculation of the Kbm do take the home address in account.
>    This ensures that the MAC will be different for different home
>    addresses.
> 
>    The first 96 bits from the MAC result are used as the Authenticator
>    field.
> 
> 6.3.  Home Address Option
> 
>    The Home Address option is carried by the Destination Option
>    extension header (Next Header value = 60).  It is used in a packet
>    sent by a mobile node while away from home, to inform the recipient
>    of the mobile node's home address.
> 
>    The Home Address option is encoded in 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 |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                          Home Address                         +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Option Type
> 
>       201 = 0xC9
> 
>    Option Length
> 
>       8-bit unsigned integer.  Length of the option, in octets,
>       excluding the Option Type and Option Length fields.  This field
>       MUST be set to 16.
> 
>    Home Address
> 
>       The home address of the mobile node sending the packet.  This
>       address MUST be a unicast routable address.
> 
>    The alignment requirement [8] for the Home Address option is 8n+6.
> 
>    The three highest-order bits of the Option Type field are encoded to
>    indicate specific processing of the option [8]; for the Home Address
>    option, these three bits are set to 110.  This indicates the
>    following processing requirements:
> 
>    o  Any IPv6 node that does not recognize the Option Type must discard
>       the packet, and if the packet's Destination Address was not a
>       multicast address, return an ICMP Parameter Problem, Code 2,
>       message to the packet's Source Address.  The Pointer field in the
>       ICMP message SHOULD point at the Option Type field.  Otherwise,
>       for multicast addresses, the ICMP message MUST NOT be sent.
> 
>    o  The data within the option cannot change en route to the packet's
>       final destination.
> 
>    The Home Address option MUST be placed as follows:
> 
>    o  After the routing header, if that header is present
> 
>    o  Before the Fragment Header, if that header is present
> 
>    o  Before the AH Header or ESP Header, if either one of those headers
>       are present
> 
>    For each IPv6 packet header, the Home Address Option MUST NOT appear
>    more than once.  However, an encapsulated packet [9] MAY contain a
>    separate Home Address option associated with each encapsulating IP
>    header.
> 
>    The inclusion of a Home Address destination option in a packet
>    affects the receiving node's processing of only this single packet.
>    No state is created or modified in the receiving node as a result of
>    receiving a Home Address option in a packet.  In particular, the
>    presence of a Home Address option in a received packet MUST NOT alter
>    the contents of the receiver's Binding Cache and MUST NOT cause any
>    changes in the routing of subsequent packets sent by this receiving
>    node.
> 
> 6.4.  Type 2 Routing Header
> 
>    Mobile IPv6 defines a new routing header variant, the type 2 routing
>    header, to allow the packet to be routed directly from a
>    correspondent to the mobile node's care-of address.  The mobile
>    node's care-of address is inserted into the IPv6 Destination Address
>    field.  Once the packet arrives at the care-of address, the mobile
>    node retrieves its home address from the routing header, and this is
>    used as the final destination address for the packet.
> 
>    The new routing header uses a different type than defined for
>    "regular" IPv6 source routing, enabling firewalls to apply different
>    rules to source routed packets than to Mobile IPv6.  This routing
>    header type (type 2) is restricted to carry only one IPv6 address.
>    All IPv6 nodes which process this routing header MUST verify that the
>    address contained within is the node's own home address in order to
>    prevent packets from being forwarded outside the node.  The IP
>    address contained in the routing header, since it is the mobile
>    node's home address, MUST be a unicast routable address.
>    Furthermore, if the scope of the home address is smaller than the
>    scope of the care-of address, the mobile node MUST discard the packet
>    (see Section 4.6).
> 
> 6.4.1.  Format
> 
>    The type 2 routing header has the following format:
> 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Next Header  | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                            Reserved                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                         Home Address                          +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Next Header
> 
>       8-bit selector.  Identifies the type of header immediately
>       following the routing header.  Uses the same values as the IPv6
>       Next Header field [8].
> 
>    Hdr Ext Len
> 
>       2 (8-bit unsigned integer); length of the routing header in
>       8-octet units, not including the first 8 octets.
> 
>    Routing Type
> 
>       2 (8-bit unsigned integer).
> 
>    Segments Left
> 
>       1 (8-bit unsigned integer).
> 
>    Reserved
> 
>       32-bit reserved field.  The value MUST be initialized to zero by
>       the sender, and MUST be ignored by the receiver.
> 
>    Home Address
> 
>       The Home Address of the destination Mobile Node.
> 
>    For a type 2 routing header, the Hdr Ext Len MUST be 2.  The Segments
>    Left value describes the number of route segments remaining; i.e.,
>    number of explicitly listed intermediate nodes still to be visited
>    before reaching the final destination.  Segments Left MUST be 1.  The
>    ordering rules for extension headers in an IPv6 packet are described
>    in Section 4.1 of RFC 2460 [8].  The type 2 routing header defined
>    for Mobile IPv6 follows the same ordering as other routing headers.
>    If both a type 0 and a type 2 routing header are present, the type 2
>    routing header should follow the other routing header.  A packet
>    containing such nested encapsulation should be created as if the
>    inner (type 2) routing header was constructed first and then treated
>    as an original packet by the outer (type 0) routing header
>    construction process.

Considering deprecation of RH0 by RFC 5095, it may be worth modifying
this paragraph to reflect that, for instance by stating that except
otherwise specified, the RH2 should be the last one in the set of RH
(i.e. removing the reference to the specific 'Type 0').

> 6.7.  ICMP Mobile Prefix Solicitation Message Format
> 
>    The ICMP Mobile Prefix Solicitation Message is sent by a mobile node
>    to its home agent while it is away from home.  The purpose of the
>    message is to solicit a Mobile Prefix Advertisement from the home
>    agent, which will allow the mobile node to gather prefix information
>    about its home network.  This information can be used to configure
>    and update home address(es) according to changes in prefix
>    information supplied by the home agent.
> 
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Code      |          Checksum             |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |          Identifier           |            Reserved           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    IP Fields:
> 
>    Source Address
> 
>       The mobile node's care-of address.
> 
>    Destination Address
> 
>       The address of the mobile node's home agent.  This home agent must
>       be on the link that the mobile node wishes to learn prefix
>       information about.
> 
>    Hop Limit
> 
>       Set to an initial hop limit value, similarly to any other unicast
>       packet sent by the mobile node.
> 
>    Destination Option:
> 
> 
> 
>       A Home Address destination option MUST be included.

Newline to be removed above.

> 
>    ESP header:
> 
> 
> 
>       IPsec headers MUST be supported and SHOULD be used as described in
>       Section 5.4.

Same here.

> 6.8.  ICMP Mobile Prefix Advertisement Message Format
> 
>    A home agent will send a Mobile Prefix Advertisement to a mobile node
>    to distribute prefix information about the home link while the mobile
>    node is traveling away from the home network.  This will occur in
>    response to a Mobile Prefix Solicitation with an Advertisement, or by
>    an unsolicited Advertisement sent according to the rules in
>    Section 10.6.
> 
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Code      |          Checksum             |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |          Identifier           |M|O|        Reserved           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           Options ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    IP Fields:
> 
>    Source Address
> 
>       The home agent's address as the mobile node would expect to see it
>       (i.e., same network prefix).
> 
>    Destination Address
> 
>       If this message is a response to a Mobile Prefix Solicitation,
>       this field contains the Source Address field from that packet.
>       For unsolicited messages, the mobile node's care-of address SHOULD
>       be used.  Note that unsolicited messages can only be sent if the
>       mobile node is currently registered with the home agent.
> 
>    Routing header:
>
>
> 
>       A type 2 routing header MUST be included.
> 
>    ESP header:
> 
> 
> 
>       IPsec headers MUST be supported and SHOULD be used as described in
>       Section 5.4.

Same here.

> 7.  Modifications to IPv6 Neighbor Discovery
> 
> 7.1.  Modified Router Advertisement Message Format
> 
>    Mobile IPv6 modifies the format of the Router Advertisement message
>    [20] by the addition of a single flag bit to indicate that the router
>    sending the Advertisement message is serving as a home agent on this
>    link.  The format of the Router Advertisement message is 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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Code      |          Checksum             |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Cur Hop Limit |M|O|H| Reserved|       Router Lifetime         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Reachable Time                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                          Retrans Timer                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   Options ...
>       +-+-+-+-+-+-+-+-+-+-+-+-
> 
>    This format represents the following changes over that originally
>    specified for Neighbor Discovery [20]:
> 
>    Home Agent (H)
> 
>       The Home Agent (H) bit is set in a Router Advertisement to
>       indicate that the router sending this Router Advertisement is also
>       functioning as a Mobile IPv6 home agent on this link.
> 
>    Reserved
> 
>       Reduced from a 6-bit field to a 5-bit field to account for the
>       addition of the above bit.
> 
> 7.2.  Modified Prefix Information Option Format
> 
>    Mobile IPv6 requires knowledge of a router's global address in
>    building a Home Agents List as part of the dynamic home agent address
>    discovery mechanism.
> 
>    However, Neighbor Discovery [20] only advertises a router's link-
>    local address, by requiring this address to be used as the IP Source
>    Address of each Router Advertisement.
> 
>    Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
>    its global address, by the addition of a single flag bit in the
>    format of a Prefix Information option for use in Router Advertisement
>    messages.  The format of the Prefix Information option is 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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     | Prefix Length |L|A|R|Reserved1|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Valid Lifetime                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                       Preferred Lifetime                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                           Reserved2                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                            Prefix                             +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    This format represents the following changes over that originally
>    specified for Neighbor Discovery [20]:
> 
>    Router Address (R)
> 
>       1-bit router address flag.  When set, indicates that the Prefix
>       field contains a complete IP address assigned to the sending
>       router.  The indicated prefix is the first Prefix Length bits of
>       the Prefix field.  The router IP address has the same scope and
>       conforms to the same lifetime values as the advertised prefix.
>       This use of the Prefix field is compatible with its use in
>       advertising the prefix itself, since Prefix Advertisement uses
>       only the leading bits.  Interpretation of this flag bit is thus
>       independent of the processing required for the On-Link (L) and
>       Autonomous Address-Configuration (A) flag bits.
> 
>    Reserved1
> 
>       Reduced from a 6-bit field to a 5-bit field to account for the
>       addition of the above bit.
> 
>    In a Router Advertisement, a home agent MUST, and all other routers
>    MAY, include at least one Prefix Information option with the Router
>    Address (R) bit set.  Neighbor Discovery specifies that, if including
>    all options in a Router Advertisement causes the size of the
>    Advertisement to exceed the link MTU, multiple Advertisements can be
>    sent, each containing a subset of the options [20].  Also, when
>    sending unsolicited multicast Router Advertisements more frequently
>    than the limit specified in RFC 4861 [20], the sending router need

s/RFC 4861 [20]/Neighbor Discovery [20]/

IMHO, this is easier to read. Note that there are various places in the
document where the replacement should be done.

> 8.3.  All IPv6 Routers
> 
>    All IPv6 routers, even those not serving as a home agent for Mobile
>    IPv6, have an effect on how well mobile nodes can communicate:
> 
>    o  Every IPv6 router SHOULD be able to send an Advertisement Interval
>       option (Section 7.3) in each of its Router Advertisements [20], to
>       aid movement detection by mobile nodes (as in Section 11.5.1).
>       The use of this option in Router Advertisements SHOULD be
>       configurable.
> 
>    o  Every IPv6 router SHOULD be able to support sending unsolicited
>       multicast Router Advertisements at the faster rate described in
>       Section 7.5.  If the router supports a faster rate, the used rate
>       MUST be configurable.
> 
>    o  Each router SHOULD include at least one prefix with the Router
>       Address (R) bit set and with its full IP address in its Router
>       Advertisements (as described in Section 7.2).
> 
>    o  Routers supporting filtering packets with routing headers SHOULD
>       support different rules for type 0 and type 2 routing headers (see
>       Section 6.4) so that filtering of source routed packets (type 0)
>       will not necessarily limit Mobile IPv6 traffic which is delivered
>       via type 2 routing headers.

Even with deprecation of RH0 via RFC 5095, I think this item should be
kept as is.

> 8.4.  IPv6 Home Agents
> 
>    In order for a mobile node to operate correctly while away from home,
>    at least one IPv6 router on the mobile node's home link must function
>    as a home agent for the mobile node.  The following additional
>    requirements apply to all IPv6 routers that serve as a home agent:
> 
>    o  Every home agent MUST be able to maintain an entry in its Binding
>       Cache for each mobile node for which it is serving as the home
>       agent (Section 10.1 and Section 10.3.1).
> 
>    o  Every home agent MUST be able to intercept packets (using proxy
>       Neighbor Discovery [20]) addressed to a mobile node for which it

No opinion on whether this is a good idea or not, but probably worth
asking: what about also adding a reference to RFC 4389 (experimental
doc)? 

> 8.5.  IPv6 Mobile Nodes
> 
>    Finally, the following requirements apply to all IPv6 nodes capable
>    of functioning as mobile nodes:
> 
>    o  The node MUST maintain a Binding Update List (Section 11.1).
> 
>    o  The node MUST support sending packets containing a Home Address
>       option (Section 11.3.1), and follow the required IPsec interaction
>       (Section 11.3.2).
> 
>    o  The node MUST be able to perform IPv6 encapsulation and
>       decapsulation [9].
> 
>    o  The node MUST be able to process type 2 routing header as defined
>       in Section 6.4 and Section 11.3.3.
> 
>    o  The node MUST support receiving a Binding Error message
>       (Section 11.3.6).
> 
>    o  The node MUST support receiving ICMP errors (Section 11.3.5).
> 
>    o  The node MUST support movement detection, care-of address
>       formation, and returning home (Section 11.5).
> 
>    o  The node MUST be able to process Mobility Headers as described in
>       Section 11.2.
> 
>    o  The node MUST support the return routability procedure
>       (Section 11.6).
> 
>    o  The node MUST be able to send Binding Updates, as specified in
>       Section 11.7.1 and Section 11.7.2.
> 
>    o  The node MUST be able to receive and process Binding
>       Acknowledgements, as specified in Section 11.7.3.
> 
>    o  The node MUST support receiving a Binding Refresh Request
>       (Section 6.1.2), by responding with a Binding Update.
> 
>    o  The node MUST support receiving Mobile Prefix Advertisements
>       (Section 11.4.3) and reconfiguring its home address based on the
>       prefix information contained therein.
> 
>    o  The node SHOULD support use of the dynamic home agent address
>       discovery mechanism, as described in Section 11.4.1.
> 
>    o  The node MUST allow route optimization to be administratively
>       enabled or disabled.  The default SHOULD be enabled.
> 
>    o  The node MAY support the multicast address listener part of a
>       multicast group membership protocol as described in
>       Section 11.3.4.  If this support is provided, the mobile node MUST
>       be able to receive tunneled multicast packets from the home agent.
> 
>    o  The node MAY support stateful address autoconfiguration mechanisms
>       such as DHCPv6 [32] on the interface represented by the tunnel to
>       the home agent.

How is that supposed to happen/work? Is that to support provisioning of
*additional* addresses (not HoA) from the Home Network? It is unclear.

> 9.  Correspondent Node Operation
> 
> 9.1.  Conceptual Data Structures
> 
>    IPv6 nodes with route optimization support maintain a Binding Cache
>    of bindings for other nodes.  A separate Binding Cache SHOULD be
>    maintained by each IPv6 node for each of its unicast routable
>    addresses.  The Binding Cache MAY be implemented in any manner
>    consistent with the external behavior described in this document, for
>    example by being combined with the node's Destination Cache as
>    maintained by Neighbor Discovery [20].  When sending a packet, the
>    Binding Cache is searched before the Neighbor Discovery conceptual
>    Destination Cache [20].
> 
>    Each Binding Cache entry conceptually contains the following fields:
> 
>    o  The home address of the mobile node for which this is the Binding
>       Cache entry.  This field is used as the key for searching the
>       Binding Cache for the destination address of a packet being sent.
> 
>    o  The care-of address for the mobile node indicated by the home
>       address field in this Binding Cache entry.
> 
>    o  A lifetime value, indicating the remaining lifetime for this
>       Binding Cache entry.  The lifetime value is initialized from the
>       Lifetime field in the Binding Update that created or last modified
>       this Binding Cache entry.

Lifetime may be the one sent in the BA in fact or am i missing sth?

> 9.2.  Processing Mobility Headers
> 
>    Mobility Header processing MUST observe the following rules:
> 
>    o  The checksum must be verified as per Section 6.1.  Otherwise,

                                              s/Otherwise/If invalid/

> 9.3.  Packet Processing
> 
>    This section describes how the correspondent node sends packets to
>    the mobile node, and receives packets from it.
> 
> 9.3.1.  Receiving Packets with Home Address Option
> 
>    Packets containing a Home Address option MUST be dropped if the given
>    home address is not a unicast routable address.
> 
>    Mobile nodes can include a Home Address destination option in a
>    packet if they believe the correspondent node has a Binding Cache
>    entry for the home address of a mobile node.  If the Next Header
>    value of the Destination Option is one of the following: {50 (ESP),
>    51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
>    normally.  Otherwise, the packet MUST be dropped if there is no
>    corresponding Binding Cache entry.  A corresponding Binding Cache
>    entry MUST have the same home address as appears in the Home Address
>    destination option, and the currently registered care-of address MUST
>    be equal to the source address of the packet.
> 
>    If the packet is dropped due the above tests, the correspondent node

                           s/due/due to/

> 9.4.1.  Receiving Home Test Init Messages
> 
>    Upon receiving a Home Test Init message, the correspondent node
>    verifies the following:
> 
>    o  The packet MUST NOT include a Home Address destination option.
> 
>    Any packet carrying a Home Test Init message which fails to satisfy
>    all of these tests MUST be silently ignored.

     s/all of these tests/this test/

>    Otherwise, in preparation for sending the corresponding Home Test
>    Message, the correspondent node checks that it has the necessary
>    material to engage in a return routability procedure, as specified in
>    Section 5.2.  The correspondent node MUST have a secret Kcn and a
>    nonce.  If it does not have this material yet, it MUST produce it
>    before continuing with the return routability procedure.
> 
>    Section 9.4.3 specifies further processing.
> 
> 9.4.2.  Receiving Care-of Test Init Messages
> 
>    Upon receiving a Care-of Test Init message, the correspondent node
>    verifies the following:
> 
>    o  The packet MUST NOT include a Home Address destination option.
> 
>    Any packet carrying a Care-of Test Init message which fails to
>    satisfy all of these tests MUST be silently ignored.

     s/all of these tests/this test/

> 9.5.1.  Receiving Binding Updates
> 
>    Before accepting a Binding Update, the receiving node MUST validate
>    the Binding Update according to the following tests:
> 
>    o  The packet MUST contain a unicast routable home address, either in
>       the Home Address option or in the Source Address, if the Home
>       Address option is not present.
> 
>    o  The Sequence Number field in the Binding Update is greater than
>       the Sequence Number received in the previous valid Binding Update
>       for this home address, if any.
> 
>       If the receiving node has no Binding Cache entry for the indicated
>       home address, it MUST accept any Sequence Number value in a
>       received Binding Update from this mobile node.
> 
>       This Sequence Number comparison MUST be performed modulo 2**16,
>       i.e., the number is a free running counter represented modulo
>       65536.  A Sequence Number in a received Binding Update is
>       considered less than or equal to the last received number if its
>       value lies in the range of the last received number and the
>       preceding 32768 values, inclusive.  For example, if the last
>       received sequence number was 15, then messages with sequence
>       numbers 0 through 15, as well as 32783 through 65535, would be
>       considered less than or equal.
> 
>    When the Home Registration (H) bit is not set, the following are also
>    required:
> 
>    o  A Nonce Indices mobility option MUST be present, and the Home and
>       Care-of Nonce Index values in this option MUST be recent enough to
>       be recognized by the correspondent node.  (Care-of Nonce Index
>       values are not inspected for requests to delete a binding.)
> 
>    o  The correspondent node MUST re-generate the home keygen token and
>       the care-of keygen token from the information contained in the
>       packet.  It then generates the binding management key Kbm and uses
>       it to verify the authenticator field in the Binding Update as
>       specified in Section 6.1.7.
> 
>    o  The Binding Authorization Data mobility option MUST be present,
>       and its contents MUST satisfy rules presented in Section 5.2.6.
>       Note that a care-of address different from the Source Address MAY
>       have been specified by including an Alternate Care-of Address
>       mobility option in the Binding Update.  When such a 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.
> 
>    o  The Binding Authorization Data mobility option MUST be the last
>       option and MUST NOT have trailing padding.
> 
>    If the Home Registration (H) bit is set, the Nonce Indices mobility
>    option MUST NOT be present.

The binding auth data must not be present either in that case.

> 
>    If the mobile node sends a sequence number which is not greater than
>    the sequence number from the last valid Binding Update for this home
>    address, 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.
> 
>    If a binding already exists for the given home address and the home
>    registration flag has a different value than the Home Registration
>    (H) bit in the Binding Update, then the receiving node MUST send back
>    a Binding Acknowledgement with status code 139 (registration type
>    change disallowed).  The home registration flag stored in the Binding
>    Cache entry MUST NOT be changed.
> 
>    If the receiving node no longer recognizes the Home Nonce Index
>    value, Care-of Nonce Index value, or both values from the Binding
>    Update, then the receiving node MUST send back a Binding
>    Acknowledgement with status code 136, 137, or 138, respectively.
> 
>    Packets carrying Binding Updates that fail to satisfy all of these
>    tests for any reason other than insufficiency of the Sequence Number,
>    registration type change, or expired nonce index values, MUST be
>    silently discarded.
> 
>    If the Binding Update is valid according to the tests above, then the
>    Binding Update is processed further as follows:
> 
>    o  The Sequence Number value received from a mobile node in a Binding
>       Update is stored by the receiving node in its Binding Cache entry
>       for the given home address.
> 
>    o  If the Lifetime specified in the Binding Update is zero, then this
>       is a request to delete the cached binding for the home address.
>       If the Home Registration (H) bit is set in the Binding Update, the
>       Binding Update is processed according to the procedure specified
>       in Section 10.3.1; otherwise, it is processed according to the
>       procedure specified in Section 9.5.2.


That item deals with *deletion* but points to sections associated with
requests to cache a binding (10.3.1 and 9.5.2). The first sentence
should be "If the Lifetime specified in the Binding Update is *not*
zero, then this is a request to *cache a binding* for the home
address". Otherwise, it does not make sense and is duplicate w/ next
item 

>    o  If the Lifetime specified in the Binding Update is zero or the
>       specified care-of address matches the home address for the
>       binding, then this is a request to delete the cached binding for
>       the home address.  In this case, the Binding Update MUST include a
>       valid home nonce index, and the care-of nonce index MUST be
>       ignored by the correspondent node.  The generation of the binding
>       management key depends then exclusively on the home keygen token
>       (Section 5.2.5).  If the Home Registration (H) bit is set in the
>       Binding Update, the Binding Update is processed according to the
>       procedure specified in Section 10.3.2; otherwise, it is processed
>       according to the procedure specified in Section 9.5.3.
>    The specified care-of address MUST be determined as follows:
>
>
> [snip]
>
>
> 9.5.4.  Sending Binding Acknowledgements
> 
>    A Binding Acknowledgement may be sent to indicate receipt of a
>    Binding Update as follows:
> 
>    o  If the Binding Update was discarded as described in Section 9.2 or
>       Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
>       Otherwise the treatment depends on the following rules.
> 
>    o  If the Acknowledge (A) bit set is set in the Binding Update, a

                         s/bit set is set/bit is set/


> 10.3.1.  Primary Care-of Address Registration
> 
>    When a node receives a Binding Update, it MUST validate it and
>    determine the type of Binding Update according to the steps described
>    in Section 9.5.1.  Furthermore, it MUST authenticate the Binding
>    Update as described in Section 5.1.  An authorization step specific
>    for the home agent is also needed to ensure that only the right node
>    can control a particular home address.  This is provided through the
>    home address unequivocally identifying the security association that
>    must be used.
> 
>    This section describes the processing of a valid and authorized
>    Binding Update when it requests the registration of the mobile node's
>    primary care-of address.
> 
>    To begin processing the Binding Update, the home agent MUST perform
>    the following sequence of tests:
> 
>    o  If the node implements only correspondent node functionality, or
>       has not been configured to act as a home agent, then the node MUST
>       reject the Binding Update.  The node MUST also return a Binding
>       Acknowledgement to the mobile node, in which the Status field is
>       set to 131 (home registration not supported).
> 
>    o  Else, if the home address for the binding (the Home Address field
>       in the packet's Home Address option) is not an on-link IPv6
>       address with respect to the home agent's current Prefix List, then
>       the home agent MUST reject the Binding Update and SHOULD return a
>       Binding Acknowledgement to the mobile node, in which the Status
>       field is set to 132 (not home subnet).
> 
>    o  Else, if the home agent chooses to reject the Binding Update for
>       any other reason (e.g., insufficient resources to serve another
>       mobile node as a home agent), then the home agent SHOULD return a
>       Binding Acknowledgement to the mobile node, in which the Status
>       field is set to an appropriate value to indicate the reason for
>       the rejection.
> 
>    o  A Home Address destination option MUST be present in the message.
>       It MUST be validated as described in Section 9.3.1 with the
>       following additional rule.

When coming back home, the Home Address destination option may be
omitted in fact.

> 10.4.1.  Intercepting Packets for a Mobile Node
> 
>    While a node is serving as the home agent for mobile node it MUST

                                          s/mobile node/a mobile node/

>    attempt to intercept packets on the mobile node's home link that are
>    addressed to the mobile node.
> 
>    In order to do this, when a node begins serving as the home agent it
>    MUST multicast onto the home link a Neighbor Advertisement message
>    [20] on behalf of the mobile node.

As specified in section 10.3.1:

   Unless this home agent already has a binding for the given home
   address, the home agent MUST perform Duplicate Address Detection [21]
   on the mobile node's home link before returning the Binding
   Acknowledgement.

So, the last sentence should be modified to indicate that the NA is sent
only after that initial DAD.

>   For the home address specified in
>    the Binding Update, the home agent sends a Neighbor Advertisement
>    message [20] to the all-nodes multicast address on the home link to
>    advertise the home agent's own link-layer address for this IP address
>    on behalf of the mobile node.  If the Link-Layer Address
>    Compatibility (L) flag has been specified in the Binding Update, the
>    home agent MUST do the same for the link-local address of the mobile
>    node.
> 
>    All fields in each Neighbor Advertisement message SHOULD be set in
>    the same way they would be set by the mobile node if it was sending
>    this Neighbor Advertisement [20] while at home, with the following
>    exceptions:
> 
>    o  The Target Address in the Neighbor Advertisement MUST be set to
>       the specific IP address for the mobile node.
> 
>    o  The Advertisement MUST include a Target Link-layer Address option
>       specifying the home agent's link-layer address.
> 
>    o  The Router (R) bit in the Advertisement MUST be set to zero.
> 
>    o  The Solicited Flag (S) in the Advertisement MUST NOT be set, since
>       it was not solicited by any Neighbor Solicitation.
> 
>    o  The Override Flag (O) in the Advertisement MUST be set, indicating
>       that the Advertisement SHOULD override any existing Neighbor Cache
>       entry at any node receiving it.
> 
>    o  The Source Address in the IPv6 header MUST be set to the home
>       agent's IP address on the interface used to send the
>       advertisement.
> 
>    Any node on the home link that receives one of the Neighbor
>    Advertisement messages (described above) will update its Neighbor
>    Cache to associate the mobile node's address with the home agent's
>    link layer address, causing it to transmit any future packets
>    normally destined to the mobile node to the mobile node's home agent.
>    Since multicasting on the local link (such as Ethernet) is typically
>    not guaranteed to be reliable, the home agent MAY retransmit this
>    Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see
>    [20]) times to increase its reliability.  It is still possible that
>    some nodes on the home link will not receive any of the Neighbor
>    Advertisements, but these nodes will eventually be able to detect the
>    link-layer address change for the mobile node's address through use
>    of Neighbor Unreachability Detection [20].
> 
>    While a node is serving as a home agent for some mobile node, the
>    home agent uses IPv6 Neighbor Discovery [20] to intercept unicast
>    packets on the home link addressed to the mobile node.  In order to
>    intercept packets in this way, the home agent MUST act as a proxy for
>    this mobile node and reply to any received Neighbor Solicitations for
>    it.  When a home agent receives a Neighbor Solicitation, it MUST
>    check if the Target Address specified in the message matches the
>    address of any mobile node for which it has a Binding Cache entry
>    marked as a home registration.

Need for a link to 4389 here too?

> 10.4.2.  Processing Intercepted Packets
> 
>    For any packet sent to a mobile node from the mobile node's home
>    agent (in which the home agent is the original sender of the packet),
>    the home agent is operating as a correspondent node of the mobile
>    node for this packet and the procedures described in Section 9.3.2
>    apply.  The home agent then uses a routing header to route the packet
>    to the mobile node by way of the primary care-of address in the home
>    agent's Binding Cache.
> 
>    While the mobile node is away from home, the home agent intercepts
>    any packets on the home link addressed to the mobile node's home
>    address, as described in Section 10.4.1.  In order to forward each
>    intercepted packet to the mobile node, the home agent MUST tunnel the
>    packet to the mobile node using IPv6 encapsulation [9].  When a home
>    agent encapsulates an intercepted packet for forwarding to the mobile
>    node, the home agent sets the Source Address in the new tunnel IP
>    header to the home agent's own IP address and sets the Destination
>    Address in the tunnel IP header to the mobile node's primary care-of
>    address.  When received by the mobile node, normal processing of the
>    tunnel header [9] will result in decapsulation and processing of the
>    original packet by the mobile node.
> 
>    However, packets addressed to the mobile node's link-local address
>    MUST NOT be tunneled to the mobile node.  Instead, these packets MUST
>    be discarded and the home agent SHOULD return an ICMP Destination
>    Unreachable, Code 3, message to the packet's Source Address (unless
>    this Source Address is a multicast address).

I am certainly missing something here, but what is the point for the HA
in defending the IP then?

> 10.6.2.  Scheduling Prefix Deliveries
> 
>    A home agent serving a mobile node will schedule the delivery of the
>    new prefix information to that mobile node when any of the following
>    conditions occur:
> 
>    MUST:
> 
>    o  The state of the flags changes for the prefix of the mobile node's
>       registered home address.
> 
>    o  The valid or preferred lifetime is reconfigured or changes for any
>       reason other than advancing real time.
> 
>    o  The mobile node requests the information with a Mobile Prefix
>       Solicitation (see Section 11.4.2).
> 
>    SHOULD:
> 
>    o  A new prefix is added to the home subnet interface(s) of the home
>       agent.
> 
>    MAY:
> 
>    o  The valid or preferred lifetime or the state of the flags changes
>       for a prefix which is not used in any Binding Cache entry for this
>       mobile node.
> 
>    The home agent uses the following algorithm to determine when to send
>    prefix information to the mobile node.
> 
>    o  If a mobile node sends a solicitation, answer right away.
> 
>    o  If no Mobile Prefix Advertisement has been sent to the mobile node
>       in the last MaxMobPfxAdvInterval seconds (see Section 13), then
>       ensure that a transmission is scheduled.  The actual transmission
>       time is randomized as described below.
> 
>    o  If a prefix matching the mobile node's home registration is added
>       on the home subnet interface or if its information changes in any
>       way that does not deprecate the mobile node's address, ensure that
>       a transmission is scheduled.  The actual transmission time is
>       randomized as described below.
> 
>    o  If a home registration expires, cancel any scheduled
>       advertisements to the mobile node.
> 
>    The list of prefixes is sent in its entirety in all cases.
> 
>    If the home agent has already scheduled the transmission of a Mobile
>    Prefix Advertisement to the mobile node, then the home agent will
>    replace the advertisement with a new one to be sent at the scheduled
>    time.
> 
>    Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY
>    which offsets from the current time for the scheduled transmission.
>    First calculate the maximum delay for the scheduled Advertisement:
> 
>      MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
> 
>    where MaxMobPfxAdvInterval is as defined in Section 12.  Then compute
>    the final delay for the advertisement:
> 
> 
>      RAND_ADV_DELAY = MinMobPfxAdvInterval +
>            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
> 
>    Here rand() returns a random integer value in the range of 0 to the
>    maximum possible integer value.  This computation is expected to
>    alleviate bursts of advertisements when prefix information changes.
>    In addition, a home agent MAY further reduce the rate of packet
>    transmission by further delaying individual advertisements, when
>    necessary to avoid overwhelming local 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.

seems weird.

> 11.  Mobile Node Operation
> 
> 11.1.  Conceptual Data Structures
> 
>    Each mobile node MUST maintain a Binding Update List.
> 
>    The Binding Update List records information for each Binding Update
>    sent by this mobile node, in which the lifetime of the binding has
>    not yet expired.  The Binding Update List includes all bindings sent
>    by the mobile node either to its home agent or correspondent nodes.
>    It also contains Binding Updates which are waiting for the completion
>    of the return routability procedure before they can be sent.
>    However, for multiple Binding Updates sent to the same destination
>    address, the Binding Update List contains only the most recent
>    Binding Update (i.e., with the greatest Sequence Number value) sent
>    to that destination.  The Binding Update List MAY be implemented in
>    any manner consistent with the external behavior described in this
>    document.
> 
>    Each Binding Update List entry conceptually contains the following
>    fields:
> 
>    o  The IP address of the node to which a Binding Update was sent.
> 
>    o  The home address for which that Binding Update was sent.
> 
>    o  The care-of address sent in that Binding Update.  This value is
>       necessary for the mobile node to determine if it has sent a
>       Binding Update while giving its new care-of address to this
>       destination after changing its care-of address.
> 
>    o  The initial value of the Lifetime field sent in that Binding
>       Update.
> 
>    o  The remaining lifetime of that binding.  This lifetime is
>       initialized from the Lifetime value sent in the Binding Update and
>       is decremented until it reaches zero, at which time this entry
>       MUST be deleted from the Binding Update List.

Updated by the BA.

> 11.3.1.  Sending Packets While Away from Home
> 
>    While a mobile node is away from home, it continues to use its home
>    address, as well as also using one or more care-of addresses.  When
>    sending a packet while away from home, a mobile node MAY choose among
>    these in selecting the address that it will use as the source of the
>    packet, as follows:
> 
>    o  Protocols layered over IP will generally treat the mobile node's
>       home address as its IP address for most packets.

                        /IP address/source IP address/

>       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.
> 
>    o  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.  Using the mobile node's care-of address as the source for
>       such queries will generally have a lower overhead than using the
>       mobile node's home address, since no extra options need be used

                                                 s/need be/need to be/

> 11.3.2.  Interaction with Outbound IPsec Processing
> 
>    This section sketches the interaction between outbound Mobile IPv6
>    processing and outbound IP Security (IPsec) processing for packets
>    sent by a mobile node while away from home.  Any specific
>    implementation MAY use algorithms and data structures other than
>    those suggested here, but its processing MUST be consistent with the
>    effect of the operation described here and with the relevant IPsec
>    specifications.  In the steps described below, it is assumed that
>    IPsec is being used in transport mode [2] and that the mobile node is
>    using its home address as the source for the packet (from the point
>    of view of higher protocol layers or applications, as described in
>    Section 11.3.1):
> 
>    o  The packet is created by higher layer protocols and applications
>       (e.g., by TCP) as if the mobile node were at home and Mobile IPv6
>       were not being used.
> 
>    o  Determine the outgoing interface for the packet.  (Note that the
>       selection between reverse tunneling and route optimization may
>       imply different interfaces, particularly if tunnels are considered
>       interfaces as well.)
> 
>    o  As part of outbound packet processing in IP, the packet is
>       compared against the IPsec security policy database to determine
>       what processing is required for the packet [2].
> 
>    o  If IPsec processing is required, the packet is either mapped to an
>       existing Security Association (or SA bundle), or a new SA (or SA
>       bundle) is created for the packet, according to the procedures
>       defined for IPsec.
> 
>    o  Since the mobile node is away from home, the mobile is either
>       using reverse tunneling or route optimization to reach the
>       correspondent node.
> 
>       If reverse tunneling is used, the packet is constructed in the
>       normal manner and then tunneled through the home agent.
>
>       If route optimization is in use, the mobile node inserts a Home
>       Address destination option into the packet, replacing the Source
>       Address in the packet's IP header with the care-of address used
>       with this correspondent node, as described in Section 11.3.1.  The
>       Destination Options header in which the Home Address destination
>       option is inserted MUST appear in the packet after the routing
>       header, if present, and before the IPsec (AH [3] or ESP [4])
>       header, so that the Home Address destination option is processed
>       by the destination node before the IPsec header is processed.
> 
>       Finally, once the packet is fully assembled, the necessary IPsec
>       authentication (and encryption, if required) processing is
>       performed on the packet, initializing the Authentication Data in
>       the IPsec header.
> 
>       RFC 2402 treatment of destination options is extended as follows.
>       The AH authentication data MUST be calculated as if the following
>       were true:
> 
>       *  the IPv6 source address in the IPv6 header contains the mobile
>          node's home address,
> 
>       *  the Home Address field of the Home Address destination option
>          (Section 6.3) contains the new care-of address.
> 
>    o  This allows, but does not require, the receiver of the packet
>       containing a Home Address destination option to exchange the two
>       fields of the incoming packet to reach the above situation,
>       simplifying processing for all subsequent packet headers.
>       However, such an exchange is not required, as long as the result
>       of the authentication calculation remains the same.
> 
>    When an automated key management protocol is used to create new
>    security associations for a peer, it is important to ensure that the
>    peer can send the key management protocol packets to the mobile node.
>    This may not be possible if the peer is the home agent of the mobile
>    node and the purpose of the security associations would be to send a
>    Binding Update to the home agent.  Packets addressed to the home
>    address of the mobile node cannot be used before the Binding Update
>    has been processed.  For the default case of using IKE [7] as the
>    automated key management protocol, such problems can be avoided by
>    the following requirements when communicating with its home agent:
> 
>    o  When the mobile node is away from home, it MUST use its care-of
>       address as the Source Address of all packets it sends as part of
>       the key management protocol (without use of Mobile IPv6 for these
>       packets, as suggested in Section 11.3.1).
> 
>    o  In addition, for all security associations bound to the mobile
>       node's home address established by IKE, the mobile node MUST
>       include an ISAKMP Identification Payload [6] in the IKE phase 2
>       exchange, giving the mobile node's home address as the initiator
>       of the Security Association [5].
> 
>    The Key Management Mobility Capability (K) bit in Binding Updates and
>    Acknowledgements can be used to avoid the need to rerun IKE upon
>    movements.

Considering the mechanism is implemented and such an interface needed to
support that, 3775bis could at least point MIGRATE doc given below as an
informational reference document. This clarifies the need and gives a
possible solution.

 http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

> 11.3.4.  Routing Multicast Packets
> 
>    A mobile node that is connected to its home link functions in the
>    same way as any other (stationary) node.  Thus, when it is at home, a
>    mobile node functions identically to other multicast senders and
>    receivers.  Therefore, this section describes the behavior of a
>    mobile node that is not on its home link.
> 
>    In order to receive packets sent to some multicast group, a mobile
>    node must join that multicast group.  One method, in which a mobile
>    node MAY join the group, is via a (local) multicast router on the
>    foreign link being visited.  In this case, the mobile node MUST use
>    its care-of address and MUST NOT use the Home Address destination
>    option when sending MLD packets [11].
> 
>    Alternatively, a mobile node MAY join multicast groups via a bi-
>    directional tunnel to its home agent.  The mobile node tunnels its
>    multicast group membership control packets (such as those defined in
>    [11] or in [40]) to its home agent, and the home agent forwards
>    multicast packets down the tunnel to the mobile node.  A mobile node
>    MUST NOT tunnel multicast group membership control packets until (1)
>    the mobile node has a binding in place at the home agent, and (2) the
>    latter sends at least one multicast group membership control packet
>    via the tunnel.  Once this condition is true, the mobile node SHOULD
>    assume it does not change as long as the binding does not expire.
> 
>    A mobile node that wishes to send packets to a multicast group also
>    has two options:
> 
>    1.  Send directly on the foreign link being visited.
> 
>        The application uses the care-of address as a source address for
>        multicast traffic, just like it would use a stationary address.
>        This requires that the application either knows the care-of
>        address, or uses an API such as the IPv6 Socket API for Source
>        Address Selection specification [24]. to request the stack to

                                    s/[24]./[24]/

> 11.4.3.  Receiving Mobile Prefix Advertisements
> 
>    Section 10.6 describes the operation of a home agent to support boot
>    time configuration and renumbering a mobile node's home subnet while
>    the mobile node is away from home.  The home agent sends Mobile
>    Prefix Advertisements to the mobile node while away from home, giving
>    "important" Prefix Information options that describe changes in the
>    prefixes in use on the mobile node's home link.
> 
>    The Mobile Prefix Solicitation is similar to the Router Solicitation
>    used in Neighbor Discovery [20], except it is routed from the mobile
>    node on the visited network to the home agent on the home network by
>    usual unicast routing rules.
> 
>    When a mobile node receives a Mobile Prefix Advertisement, it MUST
>    validate it according to the following test:
> 
>    o  The Source Address of the IP packet carrying the Mobile Prefix
>       Advertisement is the same as the home agent address to which the
>       mobile node last sent an accepted home registration Binding Update
>       to register its primary care-of address.  Otherwise, if no such
>       registrations have been made, it SHOULD be the mobile node's
>       stored home agent address, if one exists.  Otherwise, if the
>       mobile node has not yet discovered its home agent's address, it
>       MUST NOT accept Mobile Prefix Advertisements.
> 
>    o  The packet MUST have a type 2 routing header and SHOULD be
>       protected by an IPsec header as described in Section 5.4 and
>       Section 6.8.
> 
>    o  If the ICMP Identifier value matches the ICMP Identifier value of
>       the most recently sent Mobile Prefix Solicitation and no other
>       advertisement has yet been received for this value, then the
>       advertisement is considered to be solicited and will be processed
>       further.
> 
>       Otherwise, the advertisement is unsolicited, and MUST be
>       discarded.  In this case the mobile node SHOULD send a Mobile
>       Prefix Solicitation.

I tried and raise a clarification on that point:

See   http://permalink.gmane.org/gmane.ietf.mip6/9433

but got no response. IMHO, clarifying things a bit would help.

>    Any received Mobile Prefix Advertisement not meeting these tests MUST
>    be silently discarded.
> 
>    For an accepted Mobile Prefix Advertisement, the mobile node MUST
>    process Managed Address Configuration (M), Other Stateful
>    Configuration (O), and the Prefix Information Options as if they
>    arrived in a Router Advertisement [20] on the mobile node's home
>    link.  (This specification does not, however, describe how to acquire
>    home addresses through stateful protocols.)  Such processing may
>    result in the mobile node configuring a new home address, although
>    due to separation between preferred lifetime and valid lifetime, such
>    changes should not affect most communications by the mobile node, in
>    the same way as for nodes that are at home.
> 
>    This specification assumes that any security associations and
>    security policy entries that may be needed for new prefixes have been
>    pre-configured in the mobile node.  Note that while dynamic key
>    management avoids the need to create new security associations, it is

                                s/create/configure/
> 11.5.2.  Home Link Detection
> 
>    When an MN detects that it has arrived on a new link using the
>    movement detection algorithm in use (Section Section 11.5.1,) it
>    performs the following steps to determine if it is on the home link.
> 
>    o  The MN performs the procedure described in Section 11.5.2x and

                                                    s/11.5.2x/11.5.2/

Then, it seems that 11.5.2 is current section. Weird.

>       configures an address.  It also keeps track of all the on-link
>       prefix(es) received in the RA along with their prefix lengths.
> 
>    o  If the home prefix has not been statically configured the MN uses
>       some form of bootstrapping procedure (e.g.  RFC5026 [25]) to
>       determine the home prefix.
> 
>    o  Given the availability of the home prefix, the MN checks whether
>       or not the home prefix matches one of the prefixes received in the
>       RA.  If it does, the MN concludes that it has returned home.

It should be stated here or in the "Security Considerations" section
that this procedure is insecure and may have security impact, as we rely
on basic ND and undergo associated threats. This is documented:

http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00

> 11.5.5.  Returning Home
> 
>    A mobile node detects that it has returned to its home link through
>    the movement detection algorithm in use (Section 11.5.2), when the
>    mobile node detects that its home subnet prefix is again on-link.  To
>    be able to send and receive packets using its home address from the
>    home link, the mobile node MUST send a Binding Update to its home
>    agent to instruct its home agent to no longer intercept or tunnel
>    packets for it.  Until the mobile node sends such a de-registration
>    Binding Update, it MUST NOT attempt to send and receive packets using
>    its home address from the home link.  The home agent will continue to
>    intercept all packets sent to the mobile's home address and tunnel to

                                                  s/tunnel/tunnel them/

>    the previously registered care-of address.
> 
>    In this home registration, the mobile node MUST set the Acknowledge
>    (A) and Home Registration (H) bits, set the Lifetime field to zero,
>    and set the care-of address for the binding to the mobile node's own
>    home address.  The mobile node MUST use its home address as the
>    source address in the Binding Update.

Processing for receiver allows either lft=0 or CoA == HoA; so what's the
point in that MUST. 

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

            s/Duplicate Address Detection (DAD)/Proxy ND/

> 11.7.4.  Receiving Binding Refresh Requests
> 
>    When a mobile node receives a packet containing a Binding Refresh
>    Request message, the mobile node has a Binding Update List entry

           s/message,/message, if/

> 15.  Security Considerations

Considering this is documented:

http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00

the possible specific insecurity of the Home Link Detection mechanism
could be referenced in that section.

> 15.6.  Mobile Prefix Discovery
> 
>    The mobile prefix discovery function may leak interesting information
>    about network topology and prefix lifetimes to eavesdroppers; for
>    this reason, requests for this information has to be authenticated.

                                              s/has/have/ 

> 15.7.  Tunneling via the Home Agent
> 
>    Tunnels between the mobile node and the home agent can be protected
>    by ensuring proper use of source addresses, and optional
>    cryptographic protection.  These procedures are discussed in
>    Section 5.5.
> 
>    Binding Updates to the home agents are secure.  When receiving
>    tunneled traffic, the home agent verifies that the outer IP address
>    corresponds to the current location of the mobile node.  This acts as
>    a weak form of protection against spoofing packets that appear to
>    come from the mobile node.  This is particularly useful, if no end-
>    to-end security is being applied between the mobile and correspondent
>    nodes.  The outer IP address check prevents attacks where the
>    attacker is controlled by ingress filtering.  It also prevents
>    attacks when the attacker does not know the current care-of address
>    of the mobile node.  Attackers who know the care-of address and are
>    not controlled by ingress filtering could still send traffic through
>    the home agent.  This includes attackers on the same local link as
>    the mobile node is currently on.  But such attackers could send
>    packets that appear to come from the mobile node without attacking
>    the tunnel; the attacker could simply send packets with the source
>    address set to the mobile node's home address.  However, this attack
>    does not work if the final destination of the packet is in the home
>    network, and some form of perimeter defense is being applied for
>    packets sent to those destinations.  In such cases it is recommended
>    that either end-to-end security or additional tunnel protection be
>    applied, as is usual in remote access situations.
> 
>    Home agents and mobile nodes may use IPsec ESP to protect payload
>    packets tunneled between themselves.  This is useful for protecting
>    communications against attackers on the path of the tunnel.
> 
>    When site local home addresses are used, reverse tunneling can be
>    used to send site local traffic from another location.
>    Administrators should be aware of this when allowing such home
>    addresses.  In particular, the outer IP address check described above
>    is not sufficient against all attackers.  The use of encrypted
>    tunnels is particularly useful for these kinds of home addresses.

In previous paragraph, reference to site local (deprecated) should be
replaced by a reference to Unique Local Addresses (RFC4193).

> 16.  Contributors
> 
>    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
>    and Michael Thomas worked on the return routability protocols
>    eventually led to the procedures used in this protocol.

In previous sentence, s/worked/work/ 

Cheers,

a+