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

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 25 Jul 2010 20:45:05 +0200

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+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 26 Jul 2010 11:43:13 +0200

Hello Arnaud,

Thanks for your review and the comments. I really appreciate it. 

please find my comments inline.
I fixed all the typos and snip these parts.

> invest more time on the next version if I find the time. Some

thanks.

> may be added to the Terminology section.

OK.

> Add a reference to RFC 4285.

added.
> Completion of the switch-over depends on the MNs, so it may never end or

According to the section 5.4, the mobile node MUST re-register to the new home agent when it receive a HA switch message.
Therefore, when the HA send the HA switch messages to all the serving mobile nodes, it should 
receives BU from them. If not, the mobile node processes the HA switch unexpectedly.

>>      field set to 129 (Administratively prohibited).

hmm, this is weird situation. The standby should be able to be active, otherwise this protocol doesn't work.
The Switch Over operation is proceeded by administrator. Therefore, if there are any special reason not to 
select a standby as an active, it should use the code 129.

> What's the purpose of replying?

The SWB should be always sent by the active HA. Otherwise, the message should be dropped.
In addition, the receiver should notify the error back to the wrong active home agent. 
The state (active/standby) maintenance is very important of this protocol.

> Where does the constant (LINK_TRAVERSAL_TIME) comes from? Should be

Yes, it value should be configurable, although we gives some recommended default value. 
> What is the point in responding to that?

If a message sent from unknown-HA (No SA), the error ack should not be returned.
Since these messages are securely exchanged between HAs, there are certain security relationships between HAs.
It might be useful to notify the reason of errors back to the sender of SS-REP. 

thanks,
ryuji