Subject: Re: [MEXT] Moving forward with MEXT documents

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 01 May 2009 11:32:18 +0200

FWIW, the deadline for this is about the expire and we only received a 
couple of volunteers so far.

marcelo bagnulo braun escribió:
> Hi,
>
> At this point in time, the WG has the following documents that are 
> ready for WGLC:
>
> draft-ietf-mext-firewall-admin-00           
> draft-ietf-mext-firewall-vendor-00          
> draft-ietf-mip6-hareliability-04        
> draft-ietf-monami6-mipv6-analysis-05         
> draft-ietf-monami6-multihoming-motivation-scenario-03
>
> And the following document that we need to ask for adoption:
>
> draft-premec-mext-extended-home-link-01
>
> According to our new ground rules, each of these documents to proceed 
> will need 5 thorough reviews. Since this is a considerable amount of 
> effort from the WG, we would like soem feedback on how to manage this 
> effort. In particular, we would like to get feedback from the WG about 
> which documents should we issue the WGLC or adoption call first and if 
> possible volunteers to do the reviews for the documents.
>
> We will receive input on this till the 3rd of may and then decide how 
> to move forward.
>
> Regards, marcelo
>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 1 May 2009 13:27:03 -0700 (PDT)

Hi Marcelo,
  Here is my review for the HA Reliability draft:

This draft describes two methods of switching HAs in case of failure: virtual switch in which HAs themselves detect failure and HA2 takes over HA1 and hard switch in which a standby HA notifies MN to register with it.

Any improvements: yes, the document can cover the local mobility anchor reliability. All the messages defined in the draft are exchanged by HAs so they would apply to LMAs as well. Virtual switch will be almost the same. Maybe some work for the hard switch due to the architectural differences.

Nits:
Informative References ID-HAHA ID-LOCALHAHA ID-PS-HARELIABILITY if there are any co-authors, they don't appear.

7.5.2. s/in-active/inactive
1. RFC-3776 why not replace with RFC-4877 which updated 3776?

Regards,

Behcet

________________________________
From: marcelo bagnulo braun <[email-masked]>
To: mext <[email-masked]>
Cc: Jari Arkko <[email-masked]>
Sent: Friday, May 1, 2009 4:32:18 AM
Subject: Re: [MEXT] Moving forward with MEXT documents

FWIW, the deadline for this is about the expire and we only received a couple of volunteers so far.

marcelo bagnulo braun escribió:
> Hi,
> 
> At this point in time, the WG has the following documents that are ready for WGLC:
> 
> draft-ietf-mext-firewall-admin-00          draft-ietf-mext-firewall-vendor-00          draft-ietf-mip6-hareliability-04        draft-ietf-monami6-mipv6-analysis-05        draft-ietf-monami6-multihoming-motivation-scenario-03
> 
> According to our new ground rules, each of these documents to proceed will need 5 thorough reviews. Since this is a considerable amount of effort from the WG, we would like soem feedback on how to manage this effort. In particular, we would like to get feedback from the WG about which documents should we issue the WGLC or adoption call first and if possible volunteers to do the reviews for the documents.
> 
> We will receive input on this till the 3rd of may and then decide how to move forward.
> 
> Regards, marcelo
> 
> 
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 04 May 2009 15:10:58 +0200

Hi,

Some comments on an inline version of draft-ietf-mip6-hareliability-04
are provided below.

>From a general standpoint, I think the document is useful and provides
a sensible solution to the problem while taking into account the various 
difficulties and possible cases. 

That been said, at some point during the reading, I started considering
that the most interesting review would be (as usual) from someone that
would have tried implementing *and testing* the protocol. Ryuji, are you
aware of some tentative implementation or is it only a pure spec at the
moment?  

Just a thought before starting: I understand the technical difficulties
to implement the HA Virtual Switch functionality compared to the HA Hard
Switch one but I think it is worth the effort both from a user (no
additional traffic, no need for additional computations, code and
logic), traffic and a management perspective.

>    Home Agent Hard Switch
>
>       In the Home Agent Hard Switch, IPsec/IKE states synchronization is
>       not required.  The home agents are addressed by different IP
>       addresses.  When an active home agent fails, a mobile node will
>       receive a notification (Home Agent Switch message [RFC-5142]) from
>       a standby home agent, and send a Binding Update to the standby
>       home agent.  In order for the mobile node to receive the Home
>       Agent Switch message securely from the standby home agent, the
>       mobile node needs to establish an IPsec SA with both the active
>       and the standby home agents beforehand.

I understand the need for the SA to be available beforehand. Some
questions though:

- I guess that the pair of SA is similar to the ones negotiated between
  the HA and the MN, i.e. that they reference the HoA, not the CoA,
  don't they?
- When the MN moves and the CoA changes, the IKE_SA on both sides
  (MN and standby HA) need to be updated. On the MN side, this is
  feasible because the MIPv6 module is aware of the handover and of the
  new CoA but because no exchange occur *directly* between the MN and
  the standby HA, this is trickier on the standby HA side. Is it
  expected that the handover information received from the state
  synchronization with the active HA be used for that purpose? If this
  is the case, it should be stated/described. If not, how is it done?
  Full rekeying initiated by the MN?

>    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, the synchronizing the
>       configurations of the Authentication protocol is out of scope in

        "the synchronizing the configurations": first 'the' should be
        removed  

>       this document.  Operators MAY correctly configure in multiple home
>       agents.

        Maybe it's just my english, but I do not understand last
        sentence.

> 4.1.  Home Agent Virtual Switch
>
>    A mobile node remains unaware about the change in the active home
>    agent since the home agents have replicated all session state
>    including IPsec/IKE/ESP states.  IPsec/IKE/ESP state transfer is out
>    of scope of this document.

     What about changing 'IPsec/IKE/ESP' to 'IPsec/IKE'

> 4.2.  Home Agent Hard Switch
>
>    The overview of the Home Agent Hard Switch is shown in Figure 2.
>    This mode is not transparent to the mobile node when the active home
>    agent failure occurs.
>
>
>      MN      HA1(active)    HA2(Standby)
>       |           |           |
>       |<--------->|           | 1. IKE exchange (with HoA assignment)
>       |---------->|           | 2. Binding Update
>       |<----------|           | 3. Binding Acknowledgment
>       |<--------------------->| 4. IKE exchange (without HoA assignment)
>       |           |           |
>       |           |<--------->. 5. State exchanges (binding cache)
>       |           |           |
>       |           X           |  HA1 FAILURE
>       |           X           |
>       |           X<----------| 6. Failure Detection
>       |<----------------------| 7. Sending Home Agent
>       |           X           |          Switch message
>       |<--------------------->| 8. Binding Registration
>       |           X           |
>       |           X           |    RECOVERY COMPLETE
>
>
>                Figure 2: Overview of Home Agent Hard Switch
>
>    The mobile node establishes IPsec/IKE state with all the home agents
>    in the redundant home agent set beforehand (1 and 4), however it
>    registers its binding only with the active home agent (2 and 3).
>    When an active home agent fails, a standby home agent uses a pre-
>    existing IPsec SA to notify the mobile node about the failure by
>    securely sending a Home Agent Switch message.  In order to discover
>    home agent addresses, two different mechanisms are defined, as
>    described in Section 9.4.1.  The active home agent synchronizes the
>    required states of the mobile nodes, such as Binding Cache and AAA
>    information, with other standby home agents periodically (5).  The
>    mobile node MUST NOT request a home address(es) assignment through
>    the IKE exchange to the standby home agent when it establishes an SA
>    with it (4).
>
>    When the standby home agent detects the failure of the active home
>    agent (6), it sends a Home Agent Switch message to all the mobile
>    nodes that were registered with the failed home agent (7).  The Home
>    Agent Switch message must be encrypted by a pre-established IPsec SA.
>    After the switch message, the mobile node MUST send a binding update
>    to the new active home agent in order to update the Mobile IPv6
>    tunnel end points (8).

     s/end points/endpoints/

>          2: Reply-Ack
>
>          The message is called State Synchronization Reply-Ack (SS-ACK)
>          and is used to acknowledge to the SS-REP.  This message is

                       s/acknowledge to/acknowledge/

>       *  IP Address Option (Sub-type: Home Address) defined in [RFC-
>          5268].  If a home agent wants the Binding Cache information for
>          a particular mobile node, it includes the mobile node's home
>          address in an IPv6 Address Option.  If a home agent want to

                                                               wants to

>          solicit all the active mobile nodes' states, it can include the
>          unspecified address (0::0) in an IPv6 address option.

                                s/0::0/::/

> 5.1.4.  Home Agent Switch Message
>
>    This message is defined in Section 9.4.3.  The Home Agent
>    Reliability protocol extends this message for the Home Agent Hard 
>    Switch. 

     Waht about changing those two sentences for the following:

     "This message is defined in [RFC5142]. The Home Agent Reliability
     protocol extends this message for the Home Agent Hadr switch, as
     described below. Its precise use in the context of HA reliability
     mechanism is defined in section 9.4.3."

>        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
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |# of Addresses |I|  Reserved   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       .                      Home Agent Addresses                     .
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                        Mobility options                       .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                     Figure 7: Home Agent Switch Message
>
>    IPsec Re-key (I)
>
>       The IPsec re-key (I) bit is set to indicate that the mobile node
>       SHOULD start an IPsec re-key with the home agent specified in the
>       Home Agent Addresses field.  This flag is used when a failed home
>       agent recovers and needs to re-establish IPsec SA/IKE state with a
>       mobile node.  When this flag is set, the mobile node does not
>       switch the home agent, but only re-key the SA.

If I understand things correctly, when a Home Agent Switch message is
sent to a MN by a standby HA, it means that the MN should send a binding
update to the standby HA (referenced in the Home Agent Addresses field
of the message), *except* when the I flag is set in the message which in
that case means that the MN should perform an IKE negotiation with the
HA in the Home Agent Addresses field *but* not send a binding update to
that HA.

If that is correct, this breaks the semantic of the message. In that
case, having a simple flag changing the whole purpose of the message
looks like a bad idea.

I reread RFC5142 (more precisely the end of section 5.1 and the content
of section 6.1 describing how the MN should process the message). 2
cases are described (from a MN perspective):

- Home Agent Switch message is sent by a HA which is our current HA,
  containing one or more addresses which should be considered in
  order. In all cases, the MN is expected to send a de-registration
  binding and send a BU to the first HA of the list.
- Home Agent Switch message is sent by a HA which is not our current HA:
  the message SHOULD contain one address, which is the address of the
  sender of the message, which implies the MN should switch to the
  sender of the message, i.e. send a BU.

Current proposal in section 5.1.4 of the draft would basically add the
additional third case:

- Home Agent Switch message is sent by a HA (standby or not based on
  what is in 9.4.3, but chances are high is is the active HA) *with* I
  flag set *and* an address different from the one of the sender. In
  that case, the MN does not switch, it just setup an IPsec SA with the
  addresses in the message.

In the context of Hard Switch mechanism, I understand the need to have
the MN set up SA with the reborn HA (in order for that standby HA to be
able to send switch messages later in the process). But IMO that "Please 
rekey" feature needs a different (MH) container.

>    Reserved
>
>       The reserve field is reduced from 8 to 7 bits

       s/reserve/reserved/

> 5.2.2.  Binding Cache Information Option
>
>    The binding cache information option has an alignment requirement of
>    8n+2.  The Binding Cache Information option is only valid in a State
>    Synchronization message.  Its format is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = TBD  | Length = 40   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Flags                |       Sequence Number         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Lifetime             |          Reserved             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                        Home Address                           |
>        +                                                               +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                        Care-of Address                        +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                               .
>        .                                                               .
>        .                Mobile Network Prefix Option                   .
>        .                                                               .
>        .                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                 Figure 8: Binding Cache Information Option
>
>    The fields of Home Address, Care-of Address, Flags, Sequence Number,
>    and Lifetime are copied from the registered binding of a particular
>    mobile node or mobile router.  The 8-bit Reserved field MUST be set

                                       16-bit

> 5.2.3.  AAA Information Option
>
>    This option is used to carry the AAA state of the mobile node's
>    Mobile IPv6 sessions.  The AAA state information can be carried in
>    RADIUS or Diameter AVP formats including the user and session info.
>    This information option is only valid in a State Synchronization
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = TBD  |   Length      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                               .
>        .                                                               .
>        .                        AAA AVPs                               .
>        .                                                               .
>        .                                                               .
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                Figure 9: Vendor Specific Inforamtion Option

                                           Information

> 7.  Home Agent Common Operation
>
> 7.1.  Home Agent List Management
>
>    In Mobile IPv6 [RFC-3775], each home agent periodically sends router
>    advertisements with the Home Address Information option [RFC-3775]
>    when there are multiple home agents present on a link.  This
>    information is managed in a home agent list.  For the Home Agent
>    Reliability Protocol, HA-HELLO messages are used to manage the home
>    agent list.  There are several reasons to use HA-HELLO message
>    instead of Router Advertisement such as:
>
>    1.  In the Home Agent Virtual Switch mode, if the standby home agents
>        send unsolicited Router Advertisements to the home link, the
>        mobile nodes attached to the home link are aware of the presence
>        of standby home agents.  However, the standby home agents must be
>        hidden until the active home agent fails.  HA-Hello messages are
>        exchanged only between home agents.
>
>    2.  As shown in Section 6.1, standby home agents are not always
>        configured at the same link.  In this case, Router Advertisements
>        cannot be sent to the recovery link unless the home link and the
>        recovery link are connected (ex.  L2TP).  HA-HELLO can be sent
>        beyond the link.
>
>    3.  The Home Agent Reliability protocol defines to manage

                                         s/defines/is defined to/

>        additional information such as Group ID and Active/Standby
>        Status of the home agents in the home agent list.

>    In Mobile IPv6, Router Advertisement are to carry the home agent
>    information to both mobile nodes on the home link and the home
>    agents.  On the other hand, in the Home Agent Reliability protocol,
>    HA-Hello is to exchange the information among the home agents and the
>    Router Advertisement is used to notify the information to the mobile
>    nodes.

     nodes on the home link.

> 7.3.2.  Sending Hello Message
>
>    Each home agent periodically sends HA-HELLO for the home agent's
>    failure detection.  The interval time is configured at each home
>    agent.  Each home agent MUST also send a HA-HELLO in following case:
>
>    1.  when a home agent receives a HA-HELLO with the R-flag set
>
>    2.  When a home agent detects its local information such as home
>        agent preference, home agent lifetime, and registration status
>        change.
>
>    3.  When a new home agent boots up, it SHOULD solicit Hello messages
>        by multicasting a Hello message with the R-flag set in parallel
>        with sending its own Hello message.
>
>    When a home agent sends HA-HELLO, the following rule MUST be applied.

>    o  Whenever a home agent generates HA-HELLO, it MUST increment in

                                              s/increment in/increment/

>    o  If the source IPv6 address of HA-HELLO is not belong to one of

                                    s/is not belong/does not belong/

>    o  If the Group ID field of the received HA-HELLO and the receiver's
>       Group ID is different, HA-HELLO MUST be discarded.  HA-HELLO MUST
>       NOT be sent to home agents whose Group ID is different from the

            s/sent/unicasted/

>    o  If the Sequence Number value in the HA-HELLO is equal to or less
>       than the last received Sequence Number value stored in the home
>       agent list entry, the HA-HELLO MUST be discarded.

        Except when the number wraps, I imagine.

> 7.4.1.  Requesting State of a Particular Mobile Node(s)
>
>    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  It MUST set the Type field to 0 (Request).
>
>    o  It MUST set a random value in the Identifier field that does not
>       coincide with any other currently pending Requests.
>
>    o  It MUST include an IP address mobility option(s) which subtype is
>       set to the home address if the target is mobile node(s).
>
>    o  It MUST include a Mobile Network Prefix mobility option(s) for
>       mobile router(s).
>
>    o  It MUST set the unspecified address (0::0) in the Home Address

                                            s/0::0:/::/

> 7.4.2.  Synchronizing State
>
>    State synchronization messages SHOULD be sent when:
>
>    1.  The active home agent receives SS-REQ.
>
>    2.  The active home agent creates a binding cache entry for a
>        particular mobile node.
>
>    3.  The active home agent deletes a binding cache entry for a
>        particular mobile node.
>
>    The active home agent MAY additionally send state synchronization
>    message in following cases:
>
>    1.  The active home agent update the state information for all
>        sessions that changed since the last update in a periodic
>        interval
>
>    2.  Only for the Home Agent Virtual Switch mode, the active home
>        agent updates a binding cache entry for a particular mobile node
>        whenever the binding cache entry is updated.  In the Home Agent
>        Hard Switch mode, standby home agents only need the mapping
>        information of a home address of the mobile node/router and the
>        home agent address of the active home agent to which the mobile
>        node/router is currently registering.  This mapping is used to
>        send a Home Agent Switch message.
>
>    If an active home agent sends a State Synchronization message
>    whenever the local state information changes, such as a binding cache
>    change, the number of the State Synchronization messages sent can be
>    quite large.
>
>    All the state information of the requested mobile nodes is stored in
>    the SS-REP.  Following rules must be applied when the active home
>    constructs SS-REP.

                                                       the active home
     agent constructs SS-REP. 

>    o  If the unspecified address is found in the Home Address mobility
>       option carried with the SS-REQ, the active home agent MUST return
>       the state of all the active mobile nodes and mobile routers by the
>       SS-REP. The IP fragmentation can be occurred depending on the
>       total size of all the states.

     What about changing last sentence by:

     "The message may be fragemented depending on the total size
     needed to carry all states"

> 7.5.2.  Active Home Agent becomes in-active

                                    inactive

> 7.6.  Interworking with VRRP

     not that familiar with VRRP, I skipped the section.

> 8.1.  Consideration of Routing and Neighbor Discovery Protocol
>
>    This section gives a brief explanation of how a home agent interacts
>    with routing and Neighbor Discovery Protocol (NDP) when the Home
>    Agent Virtual Switch mode is used.
>
>    When a standby home agent becomes active in the Home Agent Virtual
>    Switch mode, 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 cost conflicts with

                                                 s/cost/creates/

> 9.1.  Home Agent Recovery
>
>    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 send a Home Agent Switch
>    message to all the mobile nodes that were registered at the failed
>    home agent as described in Section 9.2, using the pre-established
>    IPsec SA.  The standby Home Agent MUST set its own address in 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

     acknowledgement

> 9.2.  Sending Home Agent Switch Messages
>
>    The standby home agent which is going to be active MUST send a Home
>    Agent Switch message as defined in [RFC-5142] to all the mobile nodes
>    that were being served by the failed home agent.  The Home Agent
>    Switch message must be securely sent to the mobile node by using
>    IPsec ESP.  The standby home agent MUST include only its own home
>    agent address in the Home Agent Switch message.

     When it gets active. At the moment, when I flag is set, it contains
     the address of another HA.

>    When a failed home agent recovers, it MUST re-establish an IPsec SA
>    with each mobile node served by its redundant home agent set.
>    Otherwise, it cannot be either a 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 Switch
>    message with the I-flag set to all the mobile nodes serving by other

                                                      s/serving/served/

> 9.4.2.  IKE/IPsec pre-establishment to Home Agents
>
>    After a mobile node obtains multiple home agent addresses, it needs
>    to trigger multiple IKE exchanges with the multiple home agents
>    selected from the home agent list.  Since both IKEv1 and IKEv2 can be
>    used to bootstrap Mobile IPv6, this solution does not introduce any
>    new operations to co-operate with IKEv1 or IKEv2.  It should initiate
>    IKE for home agents as soon as home registration is complete.
>
>    The mobile node MUST follow the standard IKEv2 exchange in the
>    bootstrapping solution of the split scenario [RFC-5026].  Home
>    Address configuration maybe also be included, if necessary, for the
>    first IKE exchange.  After its Home Address is assigned or approved
>    by the first home agent, mobile node SHOULD register itself with the
>    second home agent with IKE using the same Home Address.  Therefore,
>    no home address configuration should be used in the second IKEv2
>    procedure.  Note that the mobile node only sends a Binding Update
>    message to the first home agent.

I have the feeling that this subsection should be extended in order to
describe what happens when a handover occurs, from an IKE standpoint
(IKE_SA management/update on both sides) between the reborn HA and the
MN.

> 9.4.3.  Receiving Home Agent Switch message
>
>    A mobile node must follow the operation specified in [RFC-5142] when
>    it receives a Home Agent Switch message.
>
>    If the I-flag is set in the received Home Agent Switch message, the
>    mobile node MUST re-key the SA with the home agent addresses stored
>    in the Home Agent Addresses field.  The mobile node MUST NOT change
>    its active home agent when the I-flag is set.  If the home agent
>    address is not known from the bootstrapping described in
>    Section 9.4.1, the mobile node MUST NOT start an IKE session with the
>    unknown home agent.  Instead, it SHOULD re-start home agent discovery
>    again to update its home agent address information.
>
>    When the mobile node receives a Home Agent Switch message without
>    I-flag set, and if the message contains the IPv6 address of a standby
>    home agent, it MUST select the standby home agent in the switch
>    message as the active home agent and send a new Binding Update
>
>    message to it.  Note that the standby home agent address in the Home
>    Agent Switch MUST be equal to the sender of the Home Agent Switch
>    message.  The standby Home agent expects the Binding Update as an
>    acknowledgment of the Home Agent Switch message.  The mobile node
>    already has a pre-established SA with the standby home agents and
>    should use that SA to send the Binding Update.  If the address stored
>    in the Home agent address field is different from the sender, the
>    mobile node MUST send a binding update to the sender.

I already provided some comments about the content of that section at
the beginning of the review.

> 10.  Security Considerations
>
>    Since Mobile IPv6 operation requires ESP in transport mode between
>    the mobile node and the home agent, we will discuss the ESP field
>    synchronization issues between the mobile node and the redundant set
>    of home agents.  This synchronization is required only for Home Agent
>    Virtual Switch mode.  Most of fields should be synchronized based on
>    [RFC-4301].  The ESP header has the following fields:
>
>    SPI
>
>       This field identifies the SAD at the receiver.
>
>       The mobile node negotiates only one IPsec SA.  Hence, the SPI
>       value will remain unchanged upon home agent failover.
>
>    Sequence Number
>
>       This field is used for "anti-replay" feature of ESP.  The
>       transmitter must include this monotonically increasing number.
>       The receiver may process the sequence number based on local
>       policy.
>
>       The mobile node and the redundant home agent set will have the
>       same set of sequence numbers for transmit and receive.  Hence,
>       synchronization of the sequence number field is mandatory in this
>       mode of operation.
>
>       The SA1, SA2, SA3, SA4 could be synchronized between the home
>       agents as these messages are not sent continuously.  Moreover for
>       the Binding Update case, if the mobile node is in the middle of
>       sending a Binding Update to an active home agent for a binding
>       refresh, and the active home agent is not available at that
>       moment, the mobile node will not get any response from the active
>       home agent.  After a standby home agent becomes active, the mobile
>       node will retry and it will receive the Binding Update from the
>       mobile node with a sequence number that is +n from its last known
>       sequence number for SA1.  For the Binding Acknowledgment case
>       (SA2), the standby home agent SHOULD add a random number to the
>       last known sequence number over and above the replay window to
>       ensure that the packet passes the replay check at the mobile node.
>       The same applies to HoTi and HoT messages with SA3 and SA4.  Note
>       that this windowing of the sequence numbers for Mobile IPv6
>       signaling is only needed to cover the corner cases when Binding
>       Update or HoTi is in-flight and the active home agent fails.
>
>       The technique explained above should work for user data packets if
>       ESP is used to encrypt user data traffic as well.  The actual
>       switchover time and the routing infrastructure convergence time is
>       the only latency that the user may perceive.
>
>    Initialization Vector
>
>       Since the Initialization Vector will be delivered in each exchange
>       between a mobile node and home agent, this field is not
>       necessarily synchronized between home agents.
>
>    Others
>
>       Other fields should be synchronized based on RFC4301 [RFC-4301]
>
>    In the Home Agent Hard Switch mode, the standby home agent needs to
>    send a Home Agent Switch message using IPsec encryption.  Since the
>    mobile node has pre-established an IPsec SA with both the active and
>    standby home agents, the standby home agent can send the message to
>    the mobile node with the pre-established IPsec SA.

I wonder if previous text really belongs to the "Security
Considerations" section. IMHO, it should be in a dedicated section. 

Cheers,

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 4 May 2009 11:11:48 -0700

Hi Marcelo,

1. The following two document are ready for WGLC.
     These documents are stable for long time.
     WGLC can be done at the same time.
      draft-ietf-monami6-mipv6-analysis-05
      draft-ietf-monami6-multihoming-motivation-scenario-03

2. draft-ietf-mip6-hareliability
     This document is also stable for a long time.
     The WGLC is good phase to receive the inputs from MEXT.

3. These are -00 documents. I don't remember if they have any comments  
after -00.
     If there are any, it's better to wait for -01 documents.
     draft-ietf-mext-firewall-admin/vendor

regards,
ryuji

On 2009/04/22, at 8:29, marcelo bagnulo braun wrote:

> draft-ietf-mext-firewall-admin-00           draft-ietf-mext-firewall- 
> vendor-00          draft-ietf-mip6-hareliability-04        draft- 
> ietf-monami6-mipv6-analysis-05         draft-ietf-monami6- 
> multihoming-motivation-scenario-03
>
> According to our new ground rules, each of these documents to  
> proceed will need 5 thorough reviews. Since this is a considerable  
> amount of effort from the WG, we would like soem feedback on how to  
> manage this effort. In particular, we would like to get feedback  
> from the WG about which documents should we issue the WGLC or  
> adoption call first and if possible volunteers to do the reviews for  
> the documents.
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 10:16:36 +0200

Hi Thierry and Ryuji,

Below is a review of draft-ietf-monami6-multihoming-motivation-scenario-03.
In the end, these are mostly typos and a few questions / minor changes.

As a general comment, the document is easy to read. The numerous
high-level scenarios in section 3 provides good examples for the
needs and aspects of end-node multihoming, which are then
clarified/explained in section 4. Section 6 provides a sufficient
overview of the possible issues.

IMMO, the doc is ready for WGLC.

> 1.  Introduction
>
>    New equipments shipped on the market now often integrate several
>    access technologies (both wired and wireless).  The main purpose of
>    this integration is to federate all means of communications in order
>    to access the Internet ubiquitously (from everywhere and at any time)
>    as no single technology can be expected to be deployed everywhere.
>    Flows may thus be redirected from one interface to the other
>    following the loss of connectivity or change of the network
>    conditions in different access mediums.  Besides enabling ubiquitous
>    Interent access, integrating several access technologies also allows

     s/Interent/Internet/

>    increased bandwidth availability and selection of the the most

                                                    s/the the/the/

>    appropriate technology according to the type of flow or choices of
>    the user, since each access medium has different cost, performance,
>    bandwidth, access range, and reliability.
>
>    Once multiple accesses are offered, users may want to select the most
>    appropriate set of network interface(s) depending on the network
>    environment, particularly in wireless networks which are mutable and
>    less reliable than wired networks.  Users may also want to select the
>    most appropriate interface per communication type or to combine a set
>    of interfaces to get sufficient bandwidth.

>    The purpose of this document is to emphasize the goals and benefits
>    of multihoming for fixed and mobile hosts and routers in a generic
>    fashion, i.e. without focusing on issues pertaining to hosts, or
>    routers, or mobility.  There are other documents focusing on these.
>    issues pertaining to site multihoming in fixed networks are discussed
>    in [1].  Mobility issues pertaining to mobile nodes and mobile

        s/Mobility issues/Multihoming issues/ ?

> 3.3.  Need to Set Up Preferences
>
>    Nami works at home for a publishing company using her connection to
>    the Internet via a low-speed dial up connection, a public and
>    unrealiable 802.11b WLAN from the street and her 3G cellular phone.
>    Since the public WLAN is not secure, and the dial-up connection too
>    slow, Nami checks her company's email using her 3G phone even though
>    it is expensive.  The WLAN service is used for non-confidential
>    activities, such as web-browsing and video-conferencing, and the
>    dial-up connection is moslty used to transmit her completed work

                         s/moslty/mostly/

>    securely and synchronizing her file system.

           s/synchronizing/synchronize/ ?

> 5.  Analysis
>
>    From the definition of a multihomed node it follows that a multihomed
>    node has several IPv6 addresses to choose between.  In order to
>    expose the goals and benefits in managing multihomed nodes, we
>    propose to distinguish two main cases: either the node has only one
>    interface, or the node has several interfaces.  In the former case,
>    the node is multihomed when multilpe prefixes are advertised on the

                                s/multilpe/multiple/

>    link the node is attached to.  This distinction is important and
>    sometimes subtle but the implications are important.
>
> 5.1.  Case 1: One Interface, Multiple Prefixes
>
>    The single-interfaced node is multihomed when several prefixes are
>    advertised on its interface.  The node must therefore configure
>    several IPv6 addresses.
>
>    A typical example is a node with a 802.11b interface, connected to an
>    access point.  The access point is connected trough an Ethernet link
>    to two access routers.  Each access router is configured to advertise
>    distinct network prefixes by Router Advertisements on the link and
>    can be used as default router.  Several reasons may lead to configure
>    two access routers on the same link: for instance, the access points
>    may be shared between different ISPs, or two access routers may be
>    used for redundancy or load sharing purposes.  The node will then
>    build two global IPv6 addresses on its interface.
>
>    We now analyse which of the goals detailed in Section 4 can be met
>    with this configuration.
>
>    o  Ubiquitous Access: NO
>
>       Ubiquitous access cannot be guaranteed when the node loses
>       Internet connectivity through its sole interface (e.g. the node is
>       going outside the coverage area of its access point).
>
>    o  Flow redirection: YES
>
>       The node might need to redirect a flow from one address to another
>       for several reasons.  For example, if one of the IPv6 prefix
>       becomes unavailable, flows using the address from this prefix
>       could be redirected to the address obtained on the other prefix.
>
>    o  Reliability: MAYBE
>
>       In case of failure of one IPv6 prefix, one of the address of the
>       node will not be valid anymore.  Another available address built
>       from other prefixes may allow the node to recover this sort of
>       failure.  Bi-casting can be performed to ensure the delivery of
>       packets on the node.  To do so, more than one IPv6 address must be
>       used simultaneously for one flow.  Bi-casting would allow the node
>       to seamlessly change the address used on the node.
>
>    o  Load sharing: YES
>
>       Load Sharing can be performed in the network, according to the
>       address used by the node.  The choice of the address used by the
>       node and the router selection can be influenced by load sharing
>       rules.  This mostly benefits the network side: if different access
>       routers or routes can be used to forward the node's traffic, the
>       traffic load will be shared in the network.
>
>    o  Load balancing/Flow Distribution: NO
>
>       Load balancing cannot be performed when the node has only one
>       interface.

Well, strictly speaking (considering load balancing requires different
interfaces), the NO is valid. But considering the YES for "load sharing"
above and "Preferences" and "Aggregated Bandwidth" below, what prevents
load balancing/flow distribution between the addresses, if for some
reason it is known that they have different characteristics, let say for
instance that they are associated w/ different routers/internet lines or
different kinds of addresses (native vs 6to4) ? Note that it is just a
general comment, I won't argue to change the NO to sth else..

> 6.1.  Address Selection
>
>    The multihomed node has several addresses, which implies the
>    appropriate address must be chosen when an IPv6 communication is
>    established (e.g. when a TCP connection is opened).  An address
>    selection mechanism is therefore needed.
>
>    The choice of the address can be influenced by many parameters: user
>    preferences, ingress filtering, preference flag in Router
>    Advertisement, destination prefix, type of interface, link
>    characteristics, etc.

would add: type of address (e.g. HoA vs common address)

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 13:13:09 +0200

Hi Nicolas and Ryuji,

Below is a review of draft-ietf-monami6-mipv6-analysis-05.

IMO, the draft is ready for WGLC: noblocking questions/comments, it just
needs some polishing to remove typos and update "References" section. 

> 1.  Introduction
>
>    With the emergence of performant wireless technologies, nodes are
>    highly mobile and can change their point of attachment to the
>    Internet at any time, even during active network connections.  To
>    support such mobility in IPv6, Mobile IPv6 (RFC 3775 [1] and RFC 3776

                                                            s/3776/4877/

>    [2]) allows mobile nodes to maintain ongoing sessions while changing
>    their points of attachment to the Internet.
>
>    Additionally, as explained in [3], ubiquitous, permanent, fault-
>    tolerant and heterogeneous access to the Internet is required.  For
>    doing so, mobile nodes which are prone to failure or sudden lack of
>    connectivity may be equipped with multiple interfaces.  They may also
>    be connected to multihomed networks.  In such a situation, mobile
>    nodes would be allocated multiple addresses and are said to be
>    multihomed.  These addresses would be assigned to a single interface
>    or to multiple interfaces.  However, the current specification of
>    Mobile IPv6 lacks support for using multiple addresses
>    simultaneously.
>
>    Individual solutions have been proposed to extend Mobile IPv6 in such
>    a way but all issues have not been addressed and not even discussed
>    in some document.
>
>    This study aims at fulfilling this gap and has two goals.  The first
>    goal is to determine the capabilities required for providing
>    ubiquitous, permanent, fault-tolerant and heterogeneous access to the
>    Internet to multihomed mobile nodes operating Mobile IPv6.  The
>    second goal is to define the issues arising when we attempt to
>    fulfill these requirements.  The definition of solutions addressing
>    these issues is out of scope of this document.
>
>    To understand the foundation of this study, readers should
>    familiarize themselves with the companion document [3] which outlines
>    the motivations, the goals and the benefits of multihoming for both
>    fixed and mobile nodes (i.e. generic IPv6 nodes).  Real-life
>    scenarios as illustrated in that document are the base motivations
>    for the present study.  The reader should also has basic
>    understanding of the operation of the Mobile IPv6 protocol specified
>    in RFC3775 [1].

     s/in RFC3775 [1]/in RFC3775 and RFC4877/. I think the reader should
     have in mind that MIPv6 does use IPsec for protection of signaling
     (and optionally data) when considering multihoming
     questions. Because this possibly introduce additional difficulties
     for multihoming  when IPsec/IKE enters the game, even if the draft
     does not covers those aspects, the reader should be aware that it
     should be taken into account at some points.

> 2.  Terminology
>
>    o  Simultaneously using multiple addresses
>
>       A mobile node is using multiple addresses simultaneously when an
>       incoming packet with the destination address set to any of these
>       addresses reaches the mobile node, or when any of these addresses
>       can be used by the mobile node as the source address of outcoming

                                                   s/outcoming/outgoing/

>       packets.
>
>    o  Simultaneously using multiple interfaces
>
>       A mobile node is using multiple interfaces simultaneously when it
>       can transmit IP packets over any of these interfaces.
>
>    o  Bidirectional Tunnel (BT) Mode
>
>       Mobile IPv6 Bidirectional tunnel between the mobile node and its
>       home agent. 

        What about adding:

        "It may either be an IPv6-in-IPv6 tunnel or an IPsec tunnel based
        on security requirements and configuration."

> 5.  Analysis of Multihoming Configurations
>
>    In this section, we detail all the possible multihoming
>    configurations.  We briefly discuss the current situation with Mobile
>    IPv6 and we point to issues that will be further detailed in
>    Section 6.1, Section 6.2 and Section 6.3.
>
>    As it is demonstrated below, we notice that:
>
>    o  When the mobile nodes is equipped with multiple interfaces,

                       s/nodes/node/

>       reliability, load sharing and flow distribution can be achieved in
>       all (*,*) cases.

Well, at least it is expected they should be. Current technology does
not really allow to do that.

>    o  When a single interface is available, none of the goals can be
>       achieved in the (1,1) case (the mobile node is not multihomed).
>       In all the other cases, only reliability and load sharing can be
>       achieved.

Can you clarify why flow distribution is not possible with a single
interface when case is *not* (1,1)? Maybe the specific meaning of
reliability, load sharing and flow distribution should be given when
selected as non-overlapping goals at the beginning of section 3.

> 5.1.  (1,1): 1 HoA, 1 CoA
>
>    A mobile node in this configuration with only a single network
>    interface is not multihomed.  This configuration is the common case
>    of a mobile node is away from its home link: the node has one home
>    address and one care-of address which is configured on the foreign
>    link.  None of the multihoming goals are achievable.
>
>    A mobile node in the same configuration but with several interfaces
>    is multihomed and lead to a special situation where the mobile node

                   s/lead/may lead/

>    is connected to both its home link and a foreign link.  In order to
>    use both interfaces simultaneously, the home address would be

>          Reliability is achievable, but in a limited manner.  Although
>          the mobile node cannot register its care-of address at its home
>          agent and use its home link at the same time, it could register
>          the care-of address with selected correspondent nodes (i.e.
>          route optimization).  In this case, the mobile node can enjoy a
>          better reliability for communications sessions opened with
>          these corrrespondent nodes.  When the care-of address fails,
>          the mobile node can either bind a new care-of address with its

I don't think the use of 'either' makes sense in the sentence: in all
cases, it needs a new CoA, even in second case, to tunnel the packets
via the home agent. Or are you considering the MN is on its home link in
second case.

>          home address at the correspondent nodes, or remove the binding
>          and directly get the packets via the home link.
>
>
>       What is missing for Mobile IPv6
>
>          The mobile node cannot register the care-of address configured
>          on the foreign network with its home address and receive
>          packets from the home agent via a tunnel to the care-of address
>          at the same time it receives packet on the home address from
>          the home link.  In addition, if the mobile node looses its
>          connection on the foreign link, flows that are started by using
>          the care-of address as a source address must be re-initiated
>          with another address (either the home address, or a new care-of
>          address obtained on another foreign link).  Fault recovery is
>          thus only possible without transparency, and Mobile IPv6
>          features can only recover the failure of the home address.
>          This issue is detailed in Section 6.2.2.
>
>          Reliability could also be achieved through bi-casting since the
>          mobile node has two addresses and should be able to request any
>          correspondent node to duplicate traffic to both of them.
>          However, Mobile IPv6 does not allow the mobile node to request
>          bi-casting on the correspondent node (see Section 6.2.2).
>
>
>    o  Load Sharing, Flow Distribution
>
>       What Mobile IPv6 can achieve
>
>          The mobile node is able to use both interfaces at the same
>          time, according to some preference settings on its side to
>          decide which one to use for which application.  Therefore load
>          sharing and flow distribution can be achieved when sessions are
>          initiated by the mobile node.  When a correspondent node
>          initiates a session with the mobile node, it would choose the
>          destination address depending on the available information
>          about the mobile node (e.g., DNS request).  Presently there is
>          no mechanism allowing the mobile node to indicate on which
>          interface (i.e., address) a correspondent node may reach it.
>          If only one address is known by the distant node, load sharing
>          and flow distribution cannot be achieved.  See in Section 6.1.3
>          where such path selection issues are discussed.
>
>       What is missing for Mobile IPv6
>
>          Although the mobile node is able to use both interfaces at the
>          same time, there is no mechanism that allows the mobile node to
>          indicate to which interface (i.e., address) a correspondent
>          node send packets for a particular flow.  Section 6.1.3
>          discusses such path selection issues.

Maybe that paragraph should be updated in order to reference current
MCoA and flow binding drafts. Something like:

   Although the mobile node is able to use both interfaces at the
   same time, there is no standard mechanism currently specified which
   would allow the mobile node to indicate to which interface (i.e.,
   address) a correspondent node should send packets for a particular
   flow. Nonetheless, there are some ongoing efforts ([MCoA],
   [I-D.draft-ietf-mext-flow-binding-02]) to provide solutions. Section
   6.1.3 discusses such path selection issues.

> 5.2.  (n,1): n HoAs, 1 CoA
>
>    A mobile node in this configuration is multihomed since it has
>    several home addresses.  This case may happen when a node gets access
>    to the Internet through different home agents (possibly distinct
>    operators), each offering a Mobile IPv6 service to the node.  That
>    way, the mobile node would have a home address per home agent.
>    Alternatively, a single home network may be multihomed to the
>    Internet, leading to the advertisement of multiple prefixes on the
>    home link.  The mobile node would thus have multiple home addresses
>    on a single home link.
>
>    In either cases, the node would configure a single care-of address on
>    the visited IPv6 subnet, and bind that single care-of address to all
>    its home addresses.  If the mobile node has multiple interfaces, only
>    one interface is connected to a foreign network.  The other
>    interfaces are connected to their home links, or are inactive.
>
>    We next analyze if Mobile IPv6 can be used to achieve the following
>    multihoming benefits:
>
>    o  Reliability
>
>       What Mobile IPv6 can achieve
>
>          The care-of address may change when the mobile node has
>          multiple interfaces and is disconnected from its home link
>          (e.g. failure of the interface, or movement).  In such a
>          situation, Mobile IPv6 allows transparent redirection of flows
>          using the old care-of address (i.e. the session was initiated
>          using the home address) to another care-of address.  For
>          sessions directly opened via the care-of address, the loss of
>          the address implies a re-initiation of the session.
>
>       What is missing for Mobile IPv6
>
>          If the home agent fails, the session using the failed home
>          agent must be restarted since Mobile IPv6 does not provide any
>          mechanism to hand-over transparently from a home agent to
>          another one.  Fault tolerance cannot be achieved in this case,
>          since established communications cannot be preserved (unless
>          mechanism such as [6] is used).  See the corresponding
>          discussion in Section 6.1.4 and Section 6.2.3.
>
>          If one of the home addresses of the mobile node fails, it means
>          either that the corresponding home agent has failed (which is
>          the case discussed above), or the home address is no longer
>          routed to the home agent.  In that latter case, sessions using
>          that HoA would be terminated, since the home address cannot be
>          changed transparently.

>          Reliability through bi-casting could also be achieved by
>          registering two addresses with a single home address.  However
>          Mobile IPv6 does not provide any mechanism to associate more
>          than one care-of address with one home address.  Moreover, in
>          this particular case, one home address should be used as a

                                             should or could?

>          care-of address bound to the other home address. (see in
>          Section 6.2.1 and Section 6.3.1).

I wonder what would be the point to do that in that specific
scenario. What are the benefits? Even after reading 6.3.1, except in
very specific cases (when for some reason the first HA is not reachable
via the available CoA for instance), I don't see why it would use the
HoA as CoA.

> 5.3.  (1,n): 1 HoA, n CoAs
>
>    A mobile node in this configuration is multihomed since it has
>    several care-of addresses.  This may occur when the mobile node has
>    multiple interfaces connected to different links, or when the only
>    interface is connected to a link where multiple IPv6 prefixes are
>    advertised (i.e. the visited network is multihomed).  Note that one
>    of the interfaces of the mobile node may be connected to its home
>    link.
>
>    We next analyze if Mobile IPv6 can be used to achieve the following
>    multihoming benefits:
>
>    o  Reliability
>
>       What Mobile IPv6 can achieve
>
>          Reliability support is limited to recover from a failed care-of
>          address.  Fault recovery is achieved in Mobile IPv6 by
>          associating an alternate care-of address to replace the failed
>          one.
>
>       What is missing for Mobile IPv6
>
>          Efficient mechanisms are needed to determine that a care-of
>          address has failed (see Section 6.1.1), to check reachability
>          (Section 6.1.2), to determine which care-of address should be
>          used instead (Section 6.1.3) and to redirect flows to the new
>          care-of address (Section 6.1.4).
>
>    o  Load Sharing and Flow Distribution
>
>       What Mobile IPv6 can achieve
>
>          This configuration allows sharing of the load and setting of
>          preferences among different paths between the home agent and
>          the mobile node when bidirectional tunnel mode is used, and
>          between the correspondent node and the mobile node when route
>          optimized mode is used.
>
>       What is missing for Mobile IPv6
>
>          In order to achieve load sharing and flow distribution under
>          this scenario, the mobile node would need to register several
>          care-of addresses with its unique home addresses.  However, the
>          present specification of Mobile IPv6 only allows the mobile
>          node to register a single care-of address per home address.
>          This is discussed in Section 6.2.1.  When a single home address
>          is bounded to several care-of addresses at the same time, the

              s/bounded/bound/

> 6.1.2.  Path Exploration
>
>    When the mobile node needs to re-home a communication to an
>    alternative path, a path exploration may take place.  The path
>    exploration is a step that occurs after the failure detection,

It may happen before the failure: for instance, a node with multiple
interfaces and/or address w/ various preferences on thoses interfaces
may be able to invalidate some addresses by probing the reachability of
the home agent from that address for a given protocol (say ESP or proto
41). This would allow the node to avoid the possible latency required to
perform the path exploration if the duration of the handover is critical.

>  and
>    before the path selection.  It consists of identifying a set of paths
>    that are known to provide bidirectional connectivity between the
>    mobile node and its home agent, and optionally between the mobile
>    node and its correspondent node.  It may be noted that the step of
>    path exploration may be avoided by selecting a new path, and trying
>    to re-home the communications on this new path.  If the re- homing
>    fails, a new path is selected until there is no alternate path, or
>    the re-homing signaling succeed.
>
>    Path exploration requires some signaling between pairs of addresses
>    to check reachability.  An additional protocol may be needed to
>    perform this task.
>
>    In (1,*), the path exploration consists in checking reachability
>    between each care-of address and each home agent address.  If RO mode
>    is used, the mobile node may also insure reachability between its
>    correspondent nodes' address(es) and each care-of address.
>
>    In (n,*), the path exploration consists in checking reachability
>    between the home address that is used with the session that must be
>    re-homed and each care-of address (and optionally with the
>    correspondent nodes' address(es)).  In addition, the session may need
>    to be re-homed to a different home address.  In this case, each path
>    between a pair (HoA, CoA) must to be validated.

                               s/to be validated/be validated/

> 6.1.3.  Path Selection
>
>    When there exists multiple paths from and to the mobile node, the
>    mobile node ends up choosing a source address, and possibly the
>    interface that should be used.  A correspondent node that wants to
>    establish a communication with such a mobile node may end up by
>    choosing a destination address for this mobile node.
>
>    o  Interface selection
>
>       When the mobile node has multiple available interfaces, the
>       simultaneous or selective use of several interfaces would allow a
>       mobile node to spread flows between its different interfaces.
>
>       Each interface could be used differently according to some user
>       and applications policies and preferences that would define which
>       flow would be mapped to which interface and/or which flow should
>       not be used over a given interface.  How such preferences would be
>       set on the mobile node is out of scope of Mobile IPv6 and might be
>       implementation specific.  On the other hand, if the mobile node
>       wishes to influence how preferences are set on distant nodes
>       (correspondent node or home agent), mechanisms such as those
>       proposed in draft-soliman-flow-binding [9] could be used.

Reference should be updated to use draft-ietf-mext-flow-binding-02 ?

> 6.1.4.  Rehoming
>
>    Re-homing takes place after an outage has been detected or an
>    alternative path has been identified (see previous issues
>    Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting
>    existing sessions from one path to another.  New transport sessions
>    would have to be established over the alternate path if no mechanism
>    is provided to redirect flow transparently at layers above layer 3.
>    The need for re-homing or flow redirection is explained in Appendix A
>
>    The different mechanisms that can be used to provide re-homing can be
>    split into three categories, depending on the part of the path that
>    needs to be changed.
>
>    The first category is the care-of address changes : it influences the
>    path between the mobile node and its home agent, and the path between
>    the mobile node and its correspondent node in RO mode.  This may hold
>    in case (n, n).
>
>    The second category is when the home address changes (: it influences

                                                        s/(:/:/

> 6.1.5.  Ingress Filtering
>
>    Ingress filtering mechanisms [15][16] may drop the outgoing packets
>    when multiple bi-directional tunnels end up at different home agents.
>    This could particularly occur if different prefixes are handled by
>    different home agents.  If a packet with a source address configured
>    from a specific prefix is tunneled to a home agent that does not
>    handle that specific prefix, the packet may be discarded either by
>    the home agent or by a border router in the home network.  The
>    problem of ingress filtering however, is two-fold.  It can occur in
>    the access network as well as the home network.
>
>    Suppose the mobile node selects the interface (which would determine
>    the care-of address) and the home network (which would determine the
>    home address): the chosen care-of address may not be registered with
>    the chosen home address.  For instance, consider Figure 2 below.  In
>    the access network, the mobile node MN must use CoA=PA.MN when it
>    sends packets through AR-A and it must use CoA=PB.MN when it sends a
>    packet through AR-B.  In the home network, it must use HoA=P1.MN when
>    it tunnels the packet to home agent HA-1, and it must use HoA=P2.MN
>    when it tunnels the packet to home agent HA-2.  To avoid ingress
>    filtering, the choice is thus limited to a of valid (HoA,CoA) pairs.

                                           ^^^^^^^^

> 6.2.  MIPv6-specific Issues
>
> 6.2.1.  Binding Multiple CoAs to a given HoA
>
>    In the (1,n) cases, multiple care-of addresses would be available to
>    the mobile node.  In order to use them simultaneously, the mobile
>    node must be able to bind and register multiple care-of addresses for
>    a single home address with both the home agent and the correspondent
>    nodes.  The Mobile IPv6 specification is currently lacking such
>    ability.
>
>    Although in the (n,n) cases, Mobile IPv6 allows the mobile node to
>    have multiple (HoA,CoA) pairs, the upper layer's choice of using a
>    particular home address would mean that the mobile node is forced to
>    use the corresponding care-of address.  This constrains the mobile
>    node from choosing the best (in terms of cost, bandwidth etc) access
>    link for a particular flow, since care-of address is normally bound
>    to a particular interface.  If the mobile node can register all
>    available care-of addresses with each home address, this would
>    completely decouple the home address from the interface, and allow
>    the mobile node to fully exploit its multihoming capabilities.
>
>    To counter this issue, a solution like [18] may be used.  However,

[18] points to version 07 of the draft. Current is 13.

In general, some of the references in the draft should be updated to
point to latest versions.

Cheers,

a+

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 7 May 2009 13:12:48 +0200

Hi,

> aware of some tentative implementation or is it only a pure spec at  

I know there is an implementation of RFC5142 and draft-ietf-mip6- 
hareliability-04 for UMIP 0.4 for Linux. It was implemented as part of  
a project I joined. I think I can ask whether the code can be  
disclosed or not, if someone has interest.

Cheers,
-- 
Romain KUNTZ
[email-masked]
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 07 May 2009 13:23:53 +0200

Hi Romain,

> disclosed or not, if someone has interest.

I'd be interested to look at it and possibly (depending on the size)
maintain it (if it is not done already) with the other patches I have
for UMIP.

Do you happen to know how far the IKE/IPsec support goes in the pacth?

Cheers,

a+

---

From: Brian Haley <[email-masked]>
Date: Thu, 07 May 2009 10:01:44 -0400

> maintain it (if it is not done already) with the other patches I have

I'd be interested as well since I was implementing this for Linux since I didn't
see it in the mipv6-daemon git repo.

Thanks,

-Brian

---

From: Romain KUNTZ <[email-masked]>
Date: Sat, 9 May 2009 16:31:24 +0200

Hi,

> see it in the mipv6-daemon git repo.

I've contacted the person in charge of the code. I'll get back to you  
as soon as I get an answer.

romain

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 May 2009 14:11:26 -0700

Hi Arnaud,

Thanks for detailed comments,
please fine my comments inline.

> IMMO, the doc is ready for WGLC.

great!

>>   sometimes subtle but the implications are important.

we will correct all the typos and errors here.

> general comment, I won't argue to change the NO to sth else..

I agree on your points. However, from the MN point of view, it is hard  
to detect the quality of path or the performance of default router.
We can have some additional notes on this.
Do you have any proposed text?

> would add: type of address (e.g. HoA vs common address)

got it.

thanks!
ryuji

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 12 May 2009 09:20:57 +0200

Hi,

> Do you have any proposed text?

Well, we could add something like the following:

"Note that if the node has multiple addresses (native, 6to4, ...)
configured on its interface or various access routers available on the
subnet it would still be technically possible to distribute traffic
between those addresses or those routers." 

but your argument is valid. And because the document gathers scenarios
and motivations, and do not restrict things anyway, expanding it to
cover all weird cases does not probably makes sense. Let's just keep
things as they are.

Cheers,

a+

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 25 May 2009 18:28:39 +0200

Hi,

On 2009/05/09, at 16:31, Romain KUNTZ wrote:
> I've contacted the person in charge of the code. I'll get back to  
> you as soon as I get an answer.

The code has been released. It's an open source implementation (GPLv2)  
for UMIP 0.4 by Thales Communications. You can get more information  
and download the package on this page :

http://software.nautilus6.org/HAHA/

Regards,