[MEXT] Review of draft-ietf-mip6-hareliability-06

[[e-mail] (Arnaud Ebalard)]

Hi,

I reread the document and find it in good shape already. I will try and
invest more time on the next version if I find the time. Some
comments/typos inline.

> 1.2.  Problem Statement and Requirements
> 
>    In Mobile IPv6 [RFC-3775, RFC-4877], a mobile node registers and
>    establishes a binding with only one home agent.  The home agent
>    represents the possibility of a single point of failure for Mobile
>    IPv6.  A home agent is responsible for multiple mobile nodes on its
>    home link.  The failure of the home agent may then result in the loss
>    of connectivity for numerous mobile nodes located throughout the
>    Internet.  To overcome this problem, Mobile IPv6 allows deployment of
>    multiple home agents on the home link so that upon the failure of a
>    home agent, a mobile node can re-establish its connection through a
>    new home agent.  However, the base Mobile IPv6 specification does not
>    address home agent fail-over and dynamic transfer of service from one
>    home agent to another.  This transfer of service from the failed home
>    agent to a new active home agent requires coordination or pre-
>    configuration among the home agents regarding security associations,
>    transfer of mobile node bindings, and other service information for
>    reliable Mobile IPv6 service in a deployment scenario.
> 
>    For the home agent reliability solution, we define the following
>    requirements:
> 
>    Reliable Home agent service
> 
>       Multiple home agents are available for a home prefix and one of
>       them actively serves the mobile nodes.  A standby home agent takes
>       over when the active home agent becomes unavailable.  The transfer
>       of the MN-HA association should be transparent to applications and
>       should not take longer than the care-of-addresses update procedure
>       described in Mobile IPv6 [RFC-3775].
> 
>    Availability of a redundant home agent set
> 
>       Availability of an active home agent address and a standby home
>       agent address at the bootstrapping period for the mobile node is
>       assumed.

Entries for "Active home agent address" and "standby home agent address"
may be added to the Terminology section.


>    State Synchronization
> 
>       The information for mobile nodes must be able to be synchronized
>       between an active home agent and standby home agents.  This
>       includes the Binding Cache, AAA information, other Mobile IPv6 and
>       NEMO related information.  Note that the Home Agent Reliability
>       protocol exchanges only running states of mobile nodes.
>       Therefore, we do not have any specific operation for synchronizing
>       the configuration information.  For instance, when Mobile IPv6 is
>       operated with Authentication protocol, synchronizing the

Add a reference to RFC 4285.

> 2.  Protocol Overview
> 
>    HARP assumes multiple home agents placement on a same home link or
>    different links and groups them into a redundant home agent set.  One
>    of home agents is selected as an active home agent and receives a
>    binding update from mobile nodes.  According to [RFC-3775, RFC-4877],
>    an active home agent maintains not only binding cache but also IPsec/
>    IKEv2 states per mobile node, because Mobile IP adapts IPsec as its

                                                     ^^^^^^
                                                 s/addapt/uses/  ?

>    security mechanism for signaling.
> 
>    If the active home agent fails, all these information per mobile node
>    is vanished.  As a result, all mobile nodes served by the failed home
>    agent will be disconnected.  In HARP, other home agents , named
>    standby home agent, exchange the required information with the active
>    home agent in case of failure of the active home agent.  HARP can let
>    standby home agent take over the failed home agent with such
>    information of the serving mobile nodes.
> 
> 
>      MN          HA1         HA2
>       |           |<-HA1-addr |<-HA2-addr
>       |           |           |
>       |        (active)    (standby)
>       |           |           |
>       |           |<--------->| 1. Hello exchanges
>       |<--------->|           | 2. Binding Registration to HA1
>       |           |<--------->| 3. State exchanges
>       |           |           |
>       |           X           |  HA1 FAILURE
>       |           X           |
>       |           X           | 4. Failure Detection
>       |<----------------------| 5. Sending Home Agent Switch message
>       |<--------------------->| 6. Binding Registration to HA2
>       |           X       (active) RECOVERY COMPLETE
>       |           X           |
> 
> 
>        Figure 1: Overview of Home Agent Reliability Protocol (HARP)
> 
>    Figure 1 shows an example of the HARP operations.  HA1 and HA2 belong
>    to the same redundant home agent set and are assigned with an
>    individual IP address (HA1 and HA2-addr) at the home link.  Each home
>    agent can be seen as an individual home agent by mobile nodes.  All
>    the home agents periodically send a hello message (named HA-HELLO) to
>    exchange the home agent information and also monitor the active home
>    agent's status (1).  The mobile node registers its binding only with
>    the active home agent (2).  The active home agent synchronizes the
>    serving mobile node information (i.e. home address) with the other
>    standby home agents periodically (3).
> 
>    HARP introduces the new HA-HELLO message for failure detection, but
>    it should use any types of information to detect that failure. After

        may ? 

>    detecting failure of the active home agent (4), a standby home agent
>    whose preference value is the highest takes over the failed home
>    agent.  For doing so, the standby home agent sends a Home Agent
>    Switch message to all the mobile nodes that were registered at the
>    failed home agent (5).  The standby Home Agent set its own address in

                                                 s/set/sets/ 

>    the Home Agent Address field in the Home Agent Switch message so that
>    it will receive the binding update from the mobile node as an
>    acknowledgment of the sent Home Agent Switch message.  The home agent
>    switch-over is complete when it receives binding updates from all the
>    mobile nodes (6).  For protecting the Home Agent Switch, the mobile
>    node should have IPsec Security Associations (SA) with the standby
>    home agent before any failover.  The mobile node may pre-establish
>    multiple IPsec SAs with all the home agents.
> 
>    Although the active home agent manages IPsec/IKEv2 states per mobile
>    node, HARP does not offer any recovery mechanism of these states by
>    itself.  IPsec/IKE states synchronization is out of scope in this
>    document.  However, some Virtual Private Network (VPN) products have
>    proprietary IPsec/IKEv2 state synchronization among multiple boxes.
>    If IPsec/IKEv2 states can be recovered from the active home agent to
>    standby one, HARP can be operated slightly in different manner named
>    Virtual-HARP (VHARP).  Unlike HARP, the standby home agents are an
>    exact copy of the active home agent.  It is similar to the virtual
>    router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281].  Note
>    that HARP is mandatory and VHARP is optional in this document.  VHARP
>    is shown in Figure 2.
> 
> 
>      MN          HA1         HA2
>       |           |<-HA-addr  :<-HA-addr'
>       |           |           :
>       |        (active)    (standby)
>       |<--------->|           : 1. Binding Registration to HA1
>       |           |<--------->: 2. State exchanges
>       |           |           :
>       |           X           :  HA1 FAILURE
>       |           X           :
>       |           X           : 3. Failure Detection
>       |           X           | 4. HA2 takes over the HA1
>       |           X       (active) RECOVERY COMPLETE
>       |           X           |
> 
> 
>    Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP)
> 
>    All the home agents (HA1 and HA2) in the redundant home agent set
>    share a virtual home agent address (HA-addr) and the routing will
>    ensure only the active home agent will be reachable using that
>    virtual home agent address.  After a mobile node's binding
>    registration (1), the active home agent pushes all the states of its
>    mobile nodes to the other standby home agents (2).  In VHARP, all the
>    states of a mobile node need to be synchronized.  The example
>    information such as Binding Cache and Authentication, Authorization,
>    and Accounting (AAA) information, etc.
> 
>    After detecting the active home agent has failed (3), the standby
>    home agent whose preference value is the highest takes over the
>    failed home agent.  The standby home agent activates the virtual home
>    agent address on its interface attached to the home link.  The
>    virtual home agent address's activation can be operated by VRRP.
>    Since all the necessary states of mobile nodes have already been
>    transferred to this standby home agent, the standby home agent can
>    immediately start acting as the active home agent (4).  Unlike HARP,
>    the mobile node is not required to re-register its binding to a new
>    active home agent.  The mobile node may use the IKEv2 resumption
>    mechanism [RFC-5723] to resume IPsec SA with the new active home
>    agent.
> 
>    This document offers a new management mechanism of an active and

                                                     s/an active/active/

>    standby home agents by using a new Mobility Header (MH) message named
>    a HARP message as shown in Figure 3.  This mechanism can be used in
>    both HARP and VHARP.  Each home agent exchanges own home agent
>    information with the other home agents in its redundancy home agent
>    set by a Home Agent HELLO message (HA-HELLO) (1).  The HA-HELLO
>    message can also be used to monitor the availability of the active
>    home agent.
> 
> 
>        HA1(active)  HA2    HA3 .. HAn
>            |        |      |      |
>            |<------>|<---->|<---->| 1. HELLO exchange
>            |------->|      |      | 2. HA1 sends SWB-REQ
>            |<-------|      |      | 3. HA2 sends SWB-REP
>            |------->|      |      | 4. HA2 sends SW-COMP
>        (standby) (active)  |      | HA2 BECOMES ACTIVE HA
>            |        |      |      |
>               SYSTEM MAINTENANCE, ETC.
>            |        |      |      |
>            |------->|      |      | 5. HA1 sends SWO-REQ
>            |<-------|      |      | 6. HA2 sends SWO-REP
>            |------->|      |      | 7. HA1 sends SW-COMP (optional)
>        (active) (standby)  |      | 8. HA1 returns to active HA
>            |        |      |      | HA1 BECOMES ACTIVE AGAIN
> 
> 
>                       Figure 3: Home Agent Management
> 
>    In some scenarios the active home agent may need to stop serving
>    mobile nodes for system maintenance.  This specification provides for
>    a manual home agent management.  As shown in Figure 3, the active
>    home agent (HA1) sends a SwitchBack Request message (SWB-REQ) to a
>    standby home agent (HA2) (2).  HA2 will acknowledge the message by
>    sending a SwitchBack Reply message (SWB-REP) to HA1 (3).  In the HARP
>    operation, it takes certain time to complete home agent fail-over by
>    mobile nodes' re-registration to the new home agent.  During this
>    fail-over operations, HA1 may continue serving the mobile nodes until
>    the switch over is completed.  When HA2 completes the switch-over, it
>    SHOULD send a SW-COMP to HA1 (4).  As soon as HA2 sends the SW-COMP,

Completion of the switch-over depends on the MNs, so it may never end or
take very long.

>    it becomes the active home agent.  HA1 becomes standby when it
>    receives SW-COMP.
> 
>    After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2
>    in order to become the active home agent again (5).  HA2
>    acknowledge

     s/acknwoledge/acknowledges/

>    it by sending a SwitchOver Reply (SWO-REP) to HA1 (6).  HA1 now
>    starts home agent fail-over operation.  After the completion of fail-
>    over, HA1 sends a SW-COMP to HA2 (7).  Then, HA1 returns to the
>    active home agent and HA2 fall back to a standby home agent (8).
> 
> 
> 3.  Home Agent Configuration
> 
> 3.1.  Network Configuration
> 
>    HARP supports two different configurations for standby home agents.
>    Standby home agents can be placed on the same home link or on a
>    different link.  Figure 4 depicts the configuration where home agents
>    serving the same home network are located on the same link as defined
>    in [RFC-3775].
> 
> 
>                  HA1    HA2    HA3    HA4 .... HAn
>                   |      |      |      |        |
>           --------+------+------+------+--------+---------
>                              Home Link
> 
> 
>                   Figure 4: Local Recovery Configuration
> 
>    Figure 5 illustrates when standby home agents are located on a
>    different link (illustrated as Recovery Link in Figure 5).  Most
>    large operators have a very stringent requirement on network
>    availability even in the worst type of disaster or outage.  This
>    configuration can achieve home agent recovery even if the entire home
>    link fails.  This is called geographic redundancy and a well-known
>    configuration for Telecommunications operators.  In Figure 5, home
>    agents (HA1-HA4) are placed in geographically separated regions
>    (region-1 and -2).  If region-1 suffers a down time due to any
>    reason, all the sessions will be seamlessly taken over by the nodes
>    in region-2.  Note that HA3 and HA4 cannot receive packets meant for
>    the home network until the route on the Routers is changed.  The
>    routing must be also updated to direct the packets meant for the home
>    link to the recovery link.
> 
> 
>            ---------IGP------>|<---BGP--->|<-----IGP---------
> 
>                 HA1    HA2                     HA3    HA4
>                  |      |                       |      |
>          --------+------+-----+ R---R---R +-----+------+-------
>                Home Link          Routers     Recovery Link
>               (region-1)                       (region-2)
> 
> 
>                   Figure 5: Global Recovery Configuration
> 
> 3.2.  Home Agent Address Configuration
> 
>    In HARP, each home agent obtains its individual IPv6 address from its
>    serving home prefix.  In VHARP, all the home agents use a virtual
>    home agent address generated from the home prefix.
> 
>    In addition, each home agent running VHARP need to obtain its

                                             s/need/needs/

>    individual IPv6 address from its attached link.  This IPv6 address is
>    used only for the VHARP operations between home agents and is not
>    revealed to mobile nodes for binding registration.
> 
>    All the home agents MUST join the ALL_HA_MULTICAST_ADDR.  In VHARP,
>    each home agent join the multicast group with its individual IPv6
>    address, but not with virtual home agent address.  This multicast
>    address can be used to exchange the HA-HELLO message among the home
>    agents.  On the other hand, if a home recovery link is separately
>    defined, each home agent always unicasts the HARP messages to home
>    agents configured at a geographically separated link.
> 
> 
> 4.  Home Agent Operations
> 
> 4.1.  Home Agent List Management
> 
>    In Mobile IPv6, each home agent periodically sends router
>    advertisements with the Home Address Information option [RFC-3775].
>    HARP introduces a HARP HA-HELLO message to replace the router
>    advertisement.  There are several reasons to use HA-HELLO message
>    instead of the Router Advertisement such as:
> 
>    o  A HA-HELLO message can be sent beyond the link, while a router
>       advertisement cannot be sent beyond the link.  In case of
>       geographic redundancy, router advertisements cannot be sent to the
>       recovery link unless the home link and the recovery link are
>       virtually connected by L2TP, etc.
> 
>    o  A HA-HELLO message is defined to manage additional information
>       such as Group ID and Active/Standby Status of the home agents in
>       the home agent list.
> 
>    o  A HA-HELLO message is exchange only between home agents, while a
>       router advertisement is also processed by mobile nodes attached to
>       a home link.  A HA-HELLO does not introduce any burden to the
>       mobile nodes even if it is frequently sent on the home link.
> 
>    When a HA-HELLO is used to exchange the home agent information, each
>    home agent SHOULD NOT process the Home Agent Information option
>    carried by a Router Advertisement.  A router advertisement is only
>    processed by mobile nodes.  Operators may define different
>    configuration values to the parameters of the home agent information
>    for a HA-HELLO and a Router Advertisement.
> 
>    This document requires additional information to the home agent list
>    defined in [RFC-3775].  The additional information is learned through
>    HA-HELLO message exchange.
> 
>    o  Group ID of a redundant home agent set.  It is learned through the
>       Group ID field of the HA-HELLO.
> 
>    o  HA-HELLO Interval.  This value is locally configured at every home
>       agent by operators and is learned through the Hello Interval field
>       of the HA-HELLO.
> 
>    o  An individual home agent address used in the VHARP operation.
>       This information is only required when VHARP is used in addition
>       to the virtual home agent address.  It is learned through the
>       Source Address of the HA-HELLO message.
> 
>    o  VHARP capability.  This information is learned through the V flag
>       of the HA-HELLO message.
> 
>    o  Current mode (HARP or VHARP).  This information is learned through
>       the M flag of the HA-HELLO message.
> 
>    o  Active status.  This information is learned through the A flag of
>       the HA-HELLO message.
> 
> 4.2.  Detecting Home Agent Failure
> 
>    An active and standby home agents can monitor each other in several
>    ways.  One method is to reuse other failure detection mechanisms
>    defined in VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281].  However,
>    VRRP and HSRP are not sufficient since they cannot detect the case
>    where the system is running but the Mobile IPv6 stack is not
>    operational.  Failure events used in HARP/VHARP are listed below.
> 
>    Loss of HA-HELLO
> 
>       HARP/VHARP is an extension to Mobile IPv6 and can monitor
>       availability of Mobile IPv6 stack on each home agent by
>       periodically sending a HA-HELLO as a heart-beat.  This HA-HELLO
>       can also be exchanged frequently enough to detect the failure
>       promptly without any additional overhead to mobile nodes attached
>       to the home link.  In the event that a standby home agent does not
>       receive any HA-HELLOs from its peer for a configurable duration,
>       the standby home agent assumes that home agent's failure.  The
>       detail of the Hello message is described in Section 4.3.2.
> 
>    Monitored Server Failure by the Active Home Agent
> 
>       There may be number of critical servers such as an AAA server in
>       the network that are essential for the ongoing Mobile IPv6
>       sessions at the home agent.  Operators can have a policy in place
>       that the active home agent is treated as a failed home agent upon
>       detecting that the link to such servers has failed.
> 
>    Routing Peer/Link Failure
> 
>       Operators may require the home agent to detect its next-hop
>       routing peer failure.  If the next-hop routing failure is fatal in
>       nature, or due to some other routing policies, the active home
>       agent is treated as a failed home gent and the recovering
>       operation should be started.
> 
> 4.3.  Processing the HARP Messages
> 
> 4.3.1.  IP field and Security Descriptions of HARP message
> 
>    The HARP message format is defined in Section 6.1.1.  If a HARP
>    message is unicasted, the destination address is one of Home Agent in
>    the same Redundant Home Agent set.  If it is HA-HELLO message (by
>    setting the type field to 4), it can be multicasted.  The destination
>    address MUST be set to ALL_HA_MULTICAST_ADDR.  The source address
>    MUST be set to the sender's home agent address.  Note that, in VHARP,
>    the virtual home agent address SHOULD NOT be set to source and

                                                               s/and/or/ ?
> 
>    destination address.  The IP address of the interface the packet is
>    being sent from SHOULD be used.
> 
>    If a HARP message is unicasted, it SHOULD be authenticated by IPsec
>    AH and MAY be encrypted by IPsec ESP.

     Does this mean AH alone as a SHOULD and AH+ESP as a MAY? It's not
     clear.

>   If a HA-HELLO message is
>    multicasted, multicast extensions to IPsec [RFC-5374] SHOULD be
>    applied.  If all the home agents are placed in a secure transport
>    network to exchange a HARP message, authentication and encryption MAY
>    be omitted.  Which security verification is used depends on
>    operational policy.  If security verification is failed for a
>    receiving HA-HELLO, the HA-HELLO MUST be discarded.
> 
>    The following operations MUST be performed when transmitting a HARP
>    message.
> 
>    o  The incremented latest Sequence Number MUST be set to the Sequence
>       Number field.  The Sequence Number SHOULD be initialized to zero
>       for the first Hello message.  To accomplish sequence number
>       rollover, if the sequence number has already been assigned to be
>       the largest possible number representable as a 16-bit unsigned
>       integer, then when it is incremented it will then have a value of
>       zero (0).
> 
>    o  The sender's Group ID MUST be set to the Group ID field.
> 
>    o  The V-flag MUST be set if the sender is capable of VHARP.
> 
>    o  The M-flag MUST be unset if the sender is operated with HARP.
> 
>    o  The M-flag MUST be set if the sender is operated with VHARP.
> 
>    o  The A-flag MUST be set if the sender is the active home agent.
> 
>    Performed the following functions when a HARP message is received.

Weird sentence.

> 
>    o  MUST verify the Group ID of the HARP message is equal to the
>       receiver's Group ID.
> 
>    o  MUST verify the sender of the HARP message belongs to the
>       receiver's same redundant home agent set
> 
>    o  MUST verify that the M flag is equal to the receiver's operating
>       mode.
> 
>    o  MUST verify the Sequence Number value in the HARP is larger than
>       the last received Sequence Number value.  When the sequence number
>       rollover is occurred, the sequence number value in the HA-HELLO is
>       zero.
> 
>    If any one of the above checks fails, the receiver SHOULD discard the
>    HARP message.
> 
> 4.3.2.  Processing Home Agent Hello (HA-HELLO)
> 
> 4.3.2.1.  Sending HA-Hello Message
> 
>    Each home agent MUST send a HA-HELLO in following case:
> 
>    o  UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO.
>       The interval time is configured locally at each home agent.
> 
>    o  UNSOLICITED: When a home agent detects its local information
>       change, it should immediately send a HA-HELLO.
> 
>    o  SOLICITED: when a home agent receives a HA-HELLO with the R-flag
>       set.  When the R-flag is set, the HA-HELLO can be requested to the
>       destination home agent.

weird sentence.

> 
>    A home agent can solicit a HA-HELLO to a particular home agent(s) in
>    the same redundant home agent set by unicasting or multicasting a HA-
>    HELLO with the R-flag set.  Soliciting HA-HELLO is operated when:
> 
>    o  A new home agent boots up.  The new home agent SHOULD solicit HA-
>       Hello messages by multicasting a HA-Hello message with the R-flag
>       set.
> 
>    o  A HA-HELLO has not been received after the specified hello
>       interval.  The HA-HELLO MAY be solicited to the home agent.
> 
>    o  A home agent entry in the redundant home agent set is about to be
>       removed due to home agent lifetime expiration.  The HA-HELLO
>       SHOULD be solicited to the home agent whose lifetime is soon
>       expired.
> 
>    In addition to Section 4.3.1, the following operations MUST be
>    performed when transmitting a HA-HELLO.
> 
>    o  The Type field MUST be set to 4.
> 
>    o  The R-flag MUST be set if the sender solicits a HA-HELLO to the
>       other home agent(s).
> 
>    o  The appropriate home agent configuration values MUST be copied to
>       the Home Agent Preference, the Home Agent Lifetime, and Hello
>       Interval fields.
> 
> 4.3.2.2.  Receiving Hello Message
> 
>    The receiver MUST perform the verification to the HA-HELLO described
>    in Section 4.3.1.  After the verification, the receiver copies the
>    value stored in the HA-HELLO message to the corresponding home agent
>    list entry according to Section 4.1.
> 
>    If the home agent lifetime field in the HA-HELLO is set to 0, the
>    receiver MUST remove the sender home agent from the home agents list.
> 
>    If the R-flag is set in the received HA-HELLO, the receiver MUST send
>    a new HA-HELLO to the originator as described in Section 4.3.2.1.
> 
> 4.3.3.  Processing Home Agent Switch Over (SWO-REQ/REP)
> 
>    When a standby home agent decides to become an active home agent, the
>    standby home agent sends a SwitchOver Request (SWO-REQ) to the
>    current active home agent with the following operations.
> 
>    o  MUST be unicasted only to the current active home agent
> 
>    o  MUST be sent from a standby home agent.  The active home Agent
>       MUST NOT generate this message.
> 
>    When an active home agent receives a SWO-REQ, it MUST operate the
>    following verification and operations in addition to Section 4.3.1:
> 
>    o  If the receiver of the SWO-REQ is not an active home agent, it
>       MUST send a SWO-REP with the Status field set to 130 (Not active
>       home agent).
> 
>    o  If the sender home agent does not belong to the same redundant
>       home agent set, a SWO-REP message MUST be sent to the sender with
>       the Status field set to 132 (Not in same redundant home agent
>       set).
> 
>    o  There is a case where the active home agent cannot be standby home
>       agent.  The active home agent MUST reply a SWO-REP with the Status
>       field set to 129 (Administratively prohibited).

Which case?

> 
>    o  Otherwise, the active home agent MUST become a standby home agent
>       and reply with a SWO-REP message with the Status field set to 0
>       (Success).
> 
>    When a standby home agent receives a SWO-REP, it MUST operate the
>    following verification and operations in addition to Section 4.3.1:
> 
>    o  If the receiver is an active home agent, the SWO-REP MUST be
>       discarded.
> 
>    o  If the standby home agent receives an unexpected SWO-REP which is
>       not in reply to its SWO-REQ, it MUST ignore the SWO-REP.
> 
>    o  Otherwise, if the Status field of the SWO-REP is 0 (Success), the
>       standby home agent (the receiver of SWO-REP) immediately becomes
>       an active home agent.
> 
>    o  If the value in the Status field is greater than 128 an error has
>       occurred.  In this case, the receiver MUST NOT attempt to be an
>       active home agent.
> 
> 4.3.4.  Processing Home Agent Switch Back (SWB-REQ/REP)
> 
>    When an active home agent decides to become a standby home agent, it
>    sends a SWB-REQ to one of standby home agents.  The reason for the
>    active home agent to send this message can be administrative
>    intervention, and events like Monitored Server Failure by the active
>    home agent or Routing Peer/Link Failure.  The following operations
>    MUST be performed when SWB-REQ is sent.
> 
>    o  MUST be unicasted only to one of standby home agents in the same
>       redundant home agent set
> 
>    o  MUST be sent from an active home agent.  The standby home Agent
>       MUST NOT generate this message.
> 
>    When a home agent receives a SWB-REQ message, it verifies the message
>    as follows.
> 
>    o  If the sender home agent of the SWB-REQ is not an active home
>       agent, the receiver MUST reply a SWB-REP with the Status field is
>       set to 130 (Not active home agent).

What's the purpose of replying?

> 
>    o  If the sending home agent does not belong to the same redundant
>       home agent set, a SWB-REP MUST be sent in which the Status field
>       set to 132 (Not in same redundant home agent set).
> 
>    o  Otherwise, the receiving home agent MUST send a SWB-REP with the
>       Status field is set to 0 (Success).

                   s/is set/set/
> 
>    o  After sending the SWB-REP, the standby home agent MUST NOT become
>       an active home agent immediately.  This is because the active home
>       agent is still active until it receives the SWB-REP which is
>       acknowledging the SWB-REQ.  The standby home agent SHOULD change
>       to active at least after LINK_TRAVERSAL_TIME.

Where does the constant (LINK_TRAVERSAL_TIME) comes from? Should be
possible to change it.

>    When a home agent receives a SWB-REP message, it verifies the message
>    as follows.
> 
>    o  If the standby home agent receives an unexpected SWB-REP which is
>       not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP.
> 
>    o  If the Status field of the SWB-REP is 0 (Success), the active home
>       agent immediately becomes a standby home agent.  The sender home
>       agent of SWB-REP becomes an active home agent after certain time,
>       LINK_TRAVERSAL_TIME.
> 
>    o  If the value in the Status field is greater than 128, the receiver
>       of SWB-REP (active home agent) cannot become a standby home agent
>       and MUST continue to be an active home agent.
> 
> 4.4.  State Synchronization
> 
>    A State Synchronization (SS) message format is defined in
>    Section 6.1.2.  It can carry several state information about a mobile
>    node by setting mobility options in the Mobility Options field.  The
>    following list shows examples of the mobility options which can be
>    specified in the state synchronization message.
> 
>    o  IPv6 Home Address (Binding Cache Option)
> 
>    o  Binding Cache Information (Binding Cache Option)
> 
>    o  NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC-
>       3963])
> 
>    o  IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555])
> 
>    o  IPv4 Home Address (IPv4 Home Address Option [RFC-5555])
> 
>    o  Binding Identifier (Binding Identifier Option [RFC-5648]
> 
>    o  AAA states (AAA Information Option)
> 
>    o  Miscellaneous states (Vendor Specific Mobility Option [RFC-5094])
> 
>    When a home agent need to send the state of multiple mobile nodes in

                     s/need/needs/

>    a single state synchronization message (SS-REQ or SS-REP), a Binding
>    Cache Information option is used as a separator.  For each mobile
>    node, a Binding Cache Information option is placed first, followed by
>    any other options related to the mobile node if necessary.
> 
>    In HARP, since a mobile node will re-register to the new active home
>    agent after home agent fail-over, it is not necessary for the standby
>    home agents to synchronize all the mobile nodes' state information.
>    The standby home agent only need to collect the home address
>    information of all the mobile nodes served by the active home agent.
>    The information is used to send the Home Agent Switch messages to all
>    the mobile node when the home agent failure is occurred.
> 
>    In VHARP, home agent fail-over is completed without mobile nodes'
>    binding re-registration.  Therefore, standby home agents need to copy
>    the complete state information of each mobile node registered with
>    the active home agent.
> 
> 4.4.1.  Binding Cache Information Management
> 
>    In HARP, each standby home agent learns the partial binding cache
>    information such as a pair of a home address and a mobile node's
>    registering home agent address.  This information is stored somewhere
>    in a standby home agent.
> 
>    In VHARP, a standby home agent ideally copies the received binding
>    cache information and other mobile node's information into the
>    appropriate database so that it can act as an active home agent as
>    soon as it takes over the failed home agent.
> 
> 4.4.2.  IP field and Security Descriptions of SS message
> 
>    A state synchronization message is only unicasted.  The destination
>    address MUST be one of home agents in the same Redundant Home Agent
>    set.  The source address MUST be set to the sender's home agent
>    address.  Note that, in VHARP, the virtual home agent address MUST
>    NOT be set to the source address.  IP address of the interface the
>    packet is being sent from SHOULD be used.
> 
>    If a state synchronization message is unicasted, it SHOULD be
>    authenticated by IPsec AH and MAY be encrypted by IPsec ESP. If all

Same questions as above. Does this mean AH as a SHOULD and AH+ESP as a
MAY? 

>    the home agents are placed in a secure transport network to exchange
>    the state synchronization message, authentication and encryption MAY
>    be omitted.  If security verification is failed for a receiving state
>    synchronization message, the message MUST be discarded.  Which
>    security mechanism is used depend on the operational policy.
> 
> 4.4.3.  Requesting State of Mobile Nodes (SS-REQ)
> 
>    When a home agent needs the state information for a particular mobile
>    node or a subset of mobile nodes, it sends a SS-REQ message
>    constructed as follows:
> 
>    o  MUST set the Type field to 0 (Request).
> 
>    o  MUST set a random value in the Identifier field that does not
>       coincide with any other currently pending Requests.
> 
>    o  MUST include a Binding Cache Information option(s) which Home
>       Address field is set to the target home address.  Other fields of
>       the Binding Cache Information option can be omitted.
> 
>    o  MUST set the unspecified address (::) in the Home Address field of
>       the Binding Cache Information option, if it solicits the state of
>       all the mobile nodes registering at the destination home agent of
>       the SS-REQ message.
> 
>    o  MUST include multiple binding cache information options in a SS-
>       REQ, if the sender requests multiple mobile nodes' information.
>       The sender SHOULD NOT send multiple SS-REQs per mobile node.
> 
>    o  MUST send a SS-REQ to the active home agent of the target mobile
>       node(s).
> 
>    When a home agent receives a SS-REQ, it MUST perform the verification
>    described in Section 4.4.2 and following:
> 
>    o  If the receiver does not know the binding cache for the target
>       mobile node(s) specified in the received Binding Cache Information
>       option(s), it MUST ignore the SS-REQ and MUST NOT reply a SS-REQ.
> 
>    o  Otherwise, the receiver MUST reply a SS-REP including all the
>       state information of the target mobile node(s).
> 
> 4.4.4.  Sending State Information (SS-REP)
> 
>    A SS-REP message(s) SHOULD be sent when:
> 
>    1.  The active home agent receives a SS-REQ.
> 
>    2.  The active home agent creates or deletes a binding cache entry
>        for a particular mobile node.
> 
>    The active home agent MAY additionally send a SS-REP message in
>    following cases:
> 
>    1.  The active home agent updates the state information for all
>        sessions that changed since the last update in a periodic
>        interval
> 
>    2.  Often in VHARP, the active home agent MAY update a binding cache
>        entry for a particular mobile node whenever the binding cache
>        entry is updated.  If an active home agent sends a SS-REP message
>        whenever the local state information changes, such as a binding
>        cache change, the number of the SS-REP messages can be quite
>        large.
> 
>    Following rules must be applied when the active home agent constructs
>    a SS-REP.
> 
>    o  MUST copy the Identifier field of the SS-REQ to the same field of
>       the SS-REP, if the SS-REP is sent in response to the SS-REQ.
> 
>    o  MUST set zero to the Identifier field if the SS-REP is sent
>       without solicitation (no SS-REQ).
> 
>    o  MUST include required mobility options in the SS-REP.
> 
>       *  In HARP, a partial Binding Cache Information Option (the Home
>          Address Field only) MUST be included in the SS-REP.
> 
>       *  In VHARP, a full Binding Cache Information Option and other
>          required options shown in Section 6.1.2 MUST be included in the
>          SS-REP.
> 
>    o  MUST include the state of all the active mobile nodes registering
>       in the active home agent by the SS-REP when the unspecified
>       address is found in the Home Address mobility option carried with
>       the SS-REQ.  The message may be fragmented depending on the total
>       size needed to carry all states.
> 
> 4.4.5.  Synchronizing State (SS-REP and SS-ACK)
> 
>    When a home agent receives a SS-REP, it MUST take the following
>    operations.
> 
>    o  If no options are carried in the SS-REP, the home agent MUST
>       ignore the SS-REP and MUST send SS-ACK with the Status
>       Synchronization Status option which status value is set to [131:
>       No Mobility Option]

What is the point in responding to that?

> 
>    o  If the sender of SS-REP is not in the same global home agent set,
>       the home agent MUST reject the SS-REP and MUST send SS-ACK with
>       the Status Synchronization Status option which status value is set
>       to [130: Not in same global home agent set]
> 
>    o  The receiver home agent MUST record the IPv6 address of the sender
>       as the active home agent of the mobile node in its local binding
>       cache.
> 
>    o  The receiver home agent MUST update its binding cache and all
>       other necessary information in a particular database(s).
> 
>    o  The receiver home agent MUST send a SS-ACK with state
>       synchronization status mobility options if A flag is set.
> 
>    If an active home agent requires an acknowledgment of a SS-REP, it
>    MUST set the Ack flag in the SS-REP.  The receiver of such SS-REP
>    will send back a SS-ACK.  The receiver MUST copy the Identifier value
>    received in the SS-REP into SS-ACK in order to match the SS-REP and
>    SS-ACK.
> 
> 4.5.  Switching the Active Home Agent
> 
>    In HARP, the standby home agent which is going to be active MUST send
>    a Home Agent Switch message [RFC-5142] to all the mobile nodes that
>    were being served by the failed home agent.  The following rules MUST
>    be applied when transmitting a Home Agent Switch message.
> 
>    o  MUST use IPsec ESP to the Home Agent Switch message.

                      s/to/to protect/

> 
>    o  MUST set only that standby home agent address in the Home Agent
>       Switch message
> 
>    If there are a large number of mobile nodes served by the failed home
>    agent, the overhead sending Home Agent Switch messages is high.  This
>    overhead cannot be avoided if the active home agent suddenly stop
>    serving mobile node because of unexpected reasons (crash, network
>    trouble, etc).  However, if this switch over is operated under the
>    administrative operation (maintenance, etc), the previous active home
>    agent may continue serving the mobile nodes until the switch over is
>    completed.  Until the mobile node sends a binding update to the new
>    active home agent, it still sends the packet to the previous home
>    agent.
> 
>    Therefore, the new active home agent can notify the completion of
>    switch-over to the previous active home agent by using a SW-COMP
>    message.  When the new active home agent completes the switch-over,
>    it SHOULD send a SW-COMP to the previous active home agent.  Until
>    the previous home agent receives this message, it SHOULD continue
>    serving any mobile nodes that are registered with it.  Once the
>    previous home agent receives the SW-COMP message, it can be shutdown
>    or detached from the network safely.
> 
>    In VHARP, after detecting the active home agent has failed, the
>    standby home agent whose preference value is the highest MUST take
>    over the failed home agent.  The standby home agent MUST activate the
>    virtual home agent address.  If a virtual MAC address as introduced
>    in [RFC-3768, RFC-5798] is used, the standby home agent MUST start
>    using that virtual MAC address as well.  If VHARP run with VRRP and
>    HSRP as described in Section 4.7, the virtual home agent address can
>    be treated as a virtual router address in VRRP and HSRP.  Therefore,
>    VRRP and HSRP can automatically activate the virtual home agent
>    address on the standby home agent after their election mechanism.
>    Since all the necessary state has already been transferred to this
>    standby home agent before the active home agent failed, it can
>    immediately start acting as the active home agent.
> 
>    When the failed home agent recovers from failure and would return to
>    the active home agent, it MUST re-establish IPsec SA with all the
>    mobile nodes.  All the mobile nodes lost IPsec SA with the home agent
>    when the failure is occurred.  Otherwise, it cannot be either a

                     s/is/has/

>    standby or active home agent for the mobile nodes.  Therefore, as
>    soon as the active home agent detects the recovery of the failed home
>    agent, it sends a Home Agent Rekey message to all the mobile nodes
>    served by other home agents in the same redundant home agent set, and
>    includes the recovered home agent address in the Home Agent Addresses
>    field.  The detail of the Home Agent Rekey message is described in
>    Section 6.1.3.  The mobile node will re-key the SA by using The IKEv2
>    resumption mechanism [RFC-5723].  Alternatively, the mobile node MAY
>    start a new IKE session with the recovered home agent.
> 
> 4.6.  Consideration of Routing and Neighbor Discovery Protocol (VHARP)
> 
>    This section gives a brief explanation of how a home agent interacts
>    with routing and Neighbor Discovery Protocol (NDP) when is VHARP
>    used.
> 
>    When a standby home agent becomes active in VHARP, it MUST start to
>    advertise the home agent address and the home prefix of the home
>    addresses serviced by the redundant home agent set into the routing
>    infrastructure.  This operation is normally done using a route
>    selector such as BGP or an OSPF modifier.  For example, we can use
>    the AS_Path prepend operation for BGP, and the Metric field in OSPF
>    for the route selection.  When each home agent participates in OSPF
>    routing, each home agent should be configured with the appropriate
>    metric matched to the home agent preference value.  When the active
>    home agent fails, OSPF detects the failure and can dynamically switch
>    the route to the standby home Agent based on the OSPF cost value.  If
>    this creates conflicts with the home agent preference value due to
>    configuration errors, the routers on the home link may not route
>    packets to the desired standby home agent.  In order to change the
>    OSPF cost correctly and dynamically, The operator takes other
>    existing approaches.  For example, most of router vendors have a
>    private MIB to set the cost via SNMP, though this is a vendor-
>    specific function.
> 
>    When an active home agent activates a home agent address, it SHOULD
>    use a virtual MAC address as introduced in [RFC-3768, RFC-5798].
>    When the active home agent is changed, the neighbor cache of the
>    active home agent is not necessarily updated on mobile nodes located
>    on the home link.  Otherwise, the new home agent MUST update the
>    neighbor cache entry for the home agent address on all the mobile
>    nodes located on the home link.  In addition, Mobile IPv6 uses proxy
>    NDP to intercept packets meant for mobile nodes which are away from
>    the home link.  However, it is unnecessary for the new active home
>    agent to overwrite the existing proxy neighbor entries of the mobile
>    nodes.
> 
> 4.7.  Interworking with VRRP
> 
>    VRRP and HSRP specify an election protocol that dynamically assigns
>    responsibility for a virtual router to one of the VRRP routers on a
>    LAN.  This operation is similar to the VHARP.  For example, the VRRP
>    router controlling the IP address(es) associated with a virtual
>    router is called the Master, and forwards packets sent to these IP
>    addresses.  The election process provides dynamic fail over in the
>    forwarding responsibility should the Master become unavailable.
>    Although VRRP is used to guarantee home agent address reachability,
>    it cannot be used for state synchronization and explicit switching of
>    Master and Backup.  Thus, the Home Agent Reliability protocol cannot
>    be replaced by VRRP.  This section explains how VRRP can interwork
>    with HARP/VHARP.
> 
>    When VRRP is available, VRRP can replace the Hello message described
>    in Section 6.1.1.  However, some of information is missed by using
>    VRRP.  After receiving a VRRP message, each home agent SHOULD process
>    the message and store the information as if it receives Home Agent
>    Hello messages Section 4.3.2.2.  The message format of VRRP can be
>    found in Section 5.1 of [RFC-5798].  Each field is mapped as follows:
> 
>    o  Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field.
> 
>    o  Priority: Home Agent Preference is stored in the Priority field.
>       Note that VRRP only has 8 bits for the Priority field.  Therefore,
>       values larger than 255 MUST NOT be assigned to the preference
>       value.
> 
>    o  Count IPv6 IPv6 Addr: This field MUST be always be 1.
> 
>    o  Max Advert Int: This field MUST be mapped to the Hello Interval
>       field of the Home Agent Hello message, though it only has 12
>       bytes.
> 
>    o  IPv6 address: A home agent address is stored in this field.
> 
>    Home Agent Lifetime, Sequence Number and Flags field are missed in
>    the VRRP packet format.  Therefore, operators SHOULD use the same
>    statically configured value for Home Agent Lifetime.  Each home agent
>    does not check freshness of received VRRP message because of no
>    sequence number.
> 
> 4.8.  Retransmissions and Rate Limiting
> 
>    Home agents are responsible for retransmissions and rate limiting of
>    SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response.
>    The home agent MUST determine a value for the initial transmission
>    timer:
> 
>    o  If the home agent sends a SS-REQ message, it SHOULD use an initial
>       retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.
> 
>    o  If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use
>       an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER.
> 
>    If the sending home agent fails to receive a valid matching response
>    within the selected initial retransmission interval, it SHOULD
>    retransmit the message until a response is received.  All of the
>    above constants are specified in Section 8.
> 
>    The retransmission MUST use an exponential backoff process as
>    described in [RFC-3775] until either the home agent receives a
>    response, or the timeout period reaches the value
>    MAC_HARELIABILITY_TIMEOUT.  The home agent SHOULD use a separate
>    back-off process for different message types and different
>    destinations.  The rate limiting of Mobility Header messages is the
>    same as one in [RFC-3775].  A home agent MUST NOT send Mobility
>    Header Messages to a particular home agent more than MAX_UPDATE_RATE
>    (3) times a second, which is specified in [RFC-3775].
> 
> 
> 5.  Mobile Node Operation
> 
>    This section describes the operations of a mobile node only when HARP
>    is used.  Non of operations in this section is required in VHARP.

          s/Non of operations/None of the operations/

> 6.1.3.  Home Agent Rekey Message
> 
>    This message is used to indicate that the mobile node SHOULD start an
>    IPsec re-key with the home agent specified in the Home Agent
>    Addresses field.  This message is used when a failed home agent
>    recovers and needs to re-establish IPsec SA/IKE state with a mobile
>    node.  This message MUST be unicasted to a mobile node by the active
>    home agent and MUST be authenticated and encrypted by IPsec ESP.  The
>    Home Agent Rekey message has the MH Type value TBD.  If no options
>    are present in this message, no padding is necessary and the Header
>    Len field will be set to 2.
> 
> 
>        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
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |            Reserved           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       .                      Home Agent Addresses                     .
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                        Mobility options                       .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                     Figure 8: Home Agent Rekey Message
> 
>    Reserved
> 
>       The reserved field is 16 bits
> 
>    Home Agent Address
> 
>       The receiver of this message MUST rekey the security asscoation

                                              s/asscoation/association/


Cheers,

a+