Subject: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 07 May 2009 11:46:31 +0200

Hi,

I reviewed draft-ietf-monami6-multiplecoa-13. The comments are below on
an inline version of the draft. Many are simple to handle, some are just
typos. The comments in section 9 (Compatibility w/ IPsec tunnel mode)
are more substantial.

But there is a specific topic that I would like to discuss in more
details: the home return as defined in section 5.6 (Simultaneous Home
and Visited Link Operation) 

If the following has already been proposed or discussed before, just
tell me.

While reading the draft, I got puzzled by the content of section
5.6. First I thought proposed solution was extremely complicated. Then,
I reread the section multiple times to precisely understand what kind of 
difficult problem required such a complicated solution. 

In the end, if I am not mistaken, the idea is for the MN to be able to
both directly receive traffic at its HoA with one of its interface
connected to the home network and still be registered with the HA in
order to be able to have it tunnel some parts of the traffic towards
some of its CoA. I would call that route-unoptimization. Why? Well, the
MN is at home, directly connected to its HA, exactly where it should be
to get the traffic to its HoA in the most efficient way. And the draft
complicates everythings with more than 3 pages of additions in order to
avoid uisng that *direct* connection between the HA and the MN, and
replace it by tunneling to the CoA from the HA. And there is not even an 
argument in the draft to support that need!

If the MN-HA connection on the home network is so bad and it is so
important for the MN to be able to maintain bindings with the HA from
its Home Network to keep the ability to prevent traffic to be sent
directly to it and make it be tunneled to it at its CoAs, then a 
simple solution is to let the MN consider its home network as another
foreign network and configure a CoA on the associated interface to
register it with the HA. (sorry for that long sentence) That way, it
will still have the ability to have the HA redirect traffic to other
CoAs.  

What I am arguing for is to simply follow RFC 3775 and let the MN get
back ownership of its HoA when it is at home, i.e. remove the H flag in
the Binding Identifier Mobility Option, the "MCOA RETURNHOME WO/ NDP
error value, content of section 5.6 (that's 3 pages and 5 subsections,
with unhealthy L2/L3 tricks), some parts of 6.3, ... 

Note that I do not argue against the ability for the MN to have bindings
with CN using its CoAs when one of its interface is connected to the
home network. In fact, I would like to propose an extension: what about
using BID 0 as a specific BID referencing the HoA? Yes, the HoA. The
idea would be to provide the ability for a MN to tell a CN that some
specific flow should be sent directly to the HoA. At the moment, it is
not possible (I may have missed something) for a MN that has binding
with CN to specify that some flow should be sent directly to the
HoA. This would be useful when the node is at home, for instance. But
there may be other cases where the node would prefer having the traffic
be routed by the HA: for instance because the HA-MN tunnel is IPsec
protected whereas the route-optimized communications between the MN and
a CN is not protected on the MN's foreign network.

What do you think?

> 3.  Protocol Overview
> 
>    A new extension called the Binding identification number (BID) is
>    introduced to distinguish between multiple bindings pertaining to the
>    same home address.  If a mobile node configures several IPv6 global
>    addresses on one or more of its interfaces, it can register these
>    addresses with its home agent as care-of addresses.  If the mobile
>    node wants to register multiple bindings, it MUST generate a BID for
>    each care-of address and store the BID in the binding update list.  A
>    mobile node can manipulate each binding independently by using the
>    BIDs.  The mobile node then registers its care-of addresses by
>    sending a Binding Update with a Binding Identifier mobility option.
>    The BID is included in the Binding Identifier mobility option.  After
>    receiving the Binding Update with a Binding Identifier mobility
>    option, the home agent MUST copy the BID from the Binding Identifier
>    mobility option to the corresponding field in the binding cache
>    entry.  If there is an existing binding cache entry for the mobile
>    node, and if the BID in the Binding Update does not match the one
>    with the existing entry, the home agent MUST create a new binding
>    cache entry for the new care-of address and BID.  The mobile node can
>    register multiple care-of addresses either independently in
>    individual Binding Updates or multiple at once in a single Binding
>    Update.
> 
>    If the mobile host wishes to register its binding with a
>    correspondent node, it must perform return routability operations as
>    described in [RFC-3775].  This includes managing a Care-of Keygen
>    token per care-of address and exchanging Care-of Test Init and
>    Care-of Test message with the correspondent node for each care-of
>    address.  The mobile node MAY use the same BID that it used with the
>    home agent for a particular care-of address.  For protocol
>    simplicity, bulk registration to correspondent nodes is not supported
>    in this document.  This is because the Return Routability mechanism
>    introduced in [RFC-3775] cannot be easily extended to verify multiple
>    care-of addresses stored in a single Binding Update.
> 
>    Figure 1 illustrates the configuration where the mobile node obtains
>    multiple care-of addresses at foreign links.  The mobile node can
>    utilize all the care-of addresses.  In Figure 1, the home address of
>    the mobile node (MN) is 2001:db8::EUI.  The mobile node has 3
>    different interfaces and possibly acquires care-of addresses 1-3
>    (CoA1, CoA2, CoA3).  The mobile node assigns BID1, BID2 and BID3 to
>    each care-of address.
> 
>                     +----+
>                     | CN |
>                     +--+-+
>                        |
>                    +---+------+          +----+
>             +------+ Internet |----------+ HA |
>             |      +----+---+-+          +--+-+
>         CoA2|           |   |               |   Home Link
>          +--+--+        |   |         ------+------
>          |  MN +--------+   |
>          +--+--+ CoA1       |
>         CoA3|               |
>             +---------------+
> 
>      Binding Cache Database:
>         home agent's binding (Proxy neighbor advertisement is active)
>               binding [2001:db8::EUI  BID1 care-of address1]
>               binding [2001:db8::EUI  BID2 care-of address2]
>               binding [2001:db8::EUI  BID3 care-of address3]
>         correspondent node's binding
>               binding [2001:db8::EUI  BID1 care-of address1]
>               binding [2001:db8::EUI  BID2 care-of address2]
>               binding [2001:db8::EUI  BID3 care-of address3]
> 
>               Figure 1: Multiple Care-of Address Registration
> 
>    If the mobile node decides to act as a regular mobile node compliant
>    with [RFC-3775], it sends a Binding Update without any Binding
>    Identifier mobility options.  The receiver of the Binding Update
>    deletes all the bindings registering with a BID and registers only

                         s/registering/registered/

>    single binding for the mobile node.  Note that the mobile node can
>    continue using the BID even if it has only a single binding that is
>    active.
> 
>    Binding cache lookup is done based on the home address and BID
>    information if a BID is available.  This is different from RFC 3775,
>    where only the home address is used for binding cache lookup.
>    Binding cache lookup is operated for either protocol signaling and
>    data packets.  For the protocol signaling such as a Binding Update,
>    BID should be always carried by a BID sub-option in a protocol
>    signaling.  Therefore, a correspondent binding cache that matches the
>    specified BID MUST be found from the binding cache database.  On the
>    other hand, for the data packets, no BID information is carried in a
>    packet.  The binding cache lookup may involve policy or flow filters
>    to retrieve a correspondent BID per packet in cases where some policy
>    or flow filters are used to direct a certain packet or flow to a
>    particular care-of address.  However, the binding cache lookup using
>    policy or flow filters is out of scope for this document.  If no such
>    mechanism is available and no BID is found for a packet, a node
>    SHOULD use the binding which was last verified by receiving data
>    packets or signaling from the mobile node.  In case the binding cache
>    lookup for data packets, using the combination of home address and
>    BID, does not return a valid binding cache entry, the home agent
>    SHOULD perform the lookup based on only the home address as described
>    in [RFC-3775].
>
>    In any case, to avoid problems with upper layer protocols and TCP in
>    particular, a single packet flow as identified by the 5-tuple SHOULD
>    only be sent to a single care-of address at a time.

> 
>    The mobile node may return to the home link through one of its
>    interfaces.  There are two options possible for the mobile node when
>    its returns home.  Section 5.6 and Section 5.5.1 describe the
>    returning home procedures in more detail.
> 
>    1.  The mobile node uses only the interface with which it attaches to
>        the home link. 

I think that first sentence is a bit misleading w.r.t. the content of
the paragraph. The whole idea of option 1) is just that the MN
de-registers all bindings with the HA and takes back full ownership of 
its HoA. Binding with CN may remain in place. What about (just a
proposal) saying just that, i.e. use the following to describe that
setup: 

     1. The mobile node de-registers all bindings with the HA related to
        all care-of addresses it has and takes back full ownership of
        its HoA on the home link. The net effect of this de-registration
        is that it no more receives any encapsulated traffic from the
        Home Agent on any of its interfaces. In parallel, the mobile
        node can still use the interfaces attached to foreign networks
        for route-optimized communications with correspondent nodes
        (from/to CoA1 and CoA2). This setup is illustrated in Figure 2.

This is while rewriting this paragraph that I thought it would be a good
idea for the MN to be able to express to CN the fact that some flows
should be directly sent to the HoA. Hence, the idea of asosciating BID 0
to that feature.

> 
>                     +----+
>                     | CN |
>                     +--+-+
>                        |
>                    +---+------+          +----+
>             +------+ Internet |----------+ HA |
>             |      +----+-----+          +--+-+
>         CoA2|           |                   |   Home Link
>          +--+--+        |             --+---+------
>          |  MN +--------+               |
>          +--+--+ CoA1                   |
>             |                           |
>             +---------------------------+
> 
>      Binding Cache Database:
>         home agent's binding
>               none
>         correspondent node's binding
>               binding [2001:db8::EUI  BID1 care-of address1]
>               binding [2001:db8::EUI  BID2 care-of address2]
> 
>              Figure 2: Using only Interface Attached to Home Link
> 
>    2.  The mobile node may simultaneously use both the interface
>        attached to the home link and the interfaces still attached to
>        the visited link(s) as shown in Figure 3.  There are two possible
>        topologies depending on whether the home agent is the only router
>        on the home link or not.  The operation of Neighbor Discovery
>        [RFC-4861] is different in the two topologies.  More details can
>        be found in Section 5.6.  The home agent and the correspondent
>        node have the binding entries listed in Figure 3 in their binding
>        cache database in both topologies.  The home agent also knows
>        that the mobile node is attached to the home link.  All the
>        traffic from the Internet is intercepted by the home agent first
>        and routed to either the interface attached to the home link or
>        the one of the foreign links.  How the home agent decides to
>        route a particular flow to the interface attached to the home
>        link or foreign link is out of scope in this document.

I expected to find some rationales supporting case 2 and all the
complicated thngs it adds to the draft.

>From my perspective, the home link is:

 - a specific link in MIPv6 architectures
 - the location where the MN is the closest to the HA
 - the location where packets sent to the home prefix are routed

Considering those (fair) hypothesis, what are the specific network
architectures where it is expected to be beneficial to support having
the hop just before the MN on its home link *tunnel* the traffic to a 
remote CoA on another interface?

In the end, the question is: what do we lose (in term of feature and
support) if we remove case 2 and have the MN takes back ownership of its
HoA when back home?

In fact, let me consider things in a different way: let say a MN
connected to its home network does explicitly configure an address which
is not its HoA on this specific interface. Then, the war between the HA
and the MN for the HoA on the link is over and the MN can simply
consider its Home Link as a common foreign network and keep all the
bindings it wants with its HA, i.e. have some flow routed to other CoA
on the HA. The only (IMHO, very small) drawback of this proposal is that
the traffic between the HA and the MN will be tunneled.

> 4.2.  Binding Update Message
> 
>    This specification extends the Binding Update message with a new
>    flag.  The flag is shown and described below.
> 
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |          Sequence #           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |A|H|L|K|M|R|P|F|T|O| Reserved  |           Lifetime            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        .                                                               .
>        .                        Mobility options                       .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                      Figure 4: Binding Update message
> 
>    Overwrite (O) flag
> 
>       When this flag is set, all the binding cache entries for a mobile
>       node are replaced by new entries registering with this Binding
>       Update message.  This flag is only used when BID Mobility Option
>       is carried with Binding Update.
>
>    Reserved
> 
>       6 bits Reserved field.

@ryuji: that section 4.2 seems pretty explicit to me. referencing
        already consumed flags in the Figure is IMO a good idea.

> 4.3.  Binding Identifier Mobility Option
> 
>    The Binding Identifier mobility option is included in the Binding
>    Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
>    Test Init and Care-of Test message.  The Binding Identifier Mobility
>    Option has an alignment requirement of 2n if the Care-of Address
>    field is not present.  Otherwise, it has the alignment requirement of
>    8n + 2.
> 
>                             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    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       Binding ID (BID)        |     Status    |H|   Reserved  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
>        +                                                               +
>        :                 IPv4 or IPv6 care-of address (CoA)            :
>        +                                                               +
>        +---------------------------------------------------------------+
> 
>                        Figure 5: BID Mobility Option
> 
>    Type
> 
>       Type value for Binding Identifier is TBD
> 
>    Length
> 
>       8-bit unsigned integer.  Length of the option, in octets,
>       excluding the Type and Length fields.  It MUST be set to either 4,
>       8, or 20 depending on the care-of address field.  When the care-of
>       address is not carried by this option, the length value MUST be
>       set to 4.  If the IPv4 care-of address is stored in the care-of
>       address field, the length MUST be 8.  Otherwise, the Length value
>       MUST be set to 20 for IPv6 care-of address.
> 
>    Binding ID (BID)
> 
>       The BID which is assigned to the binding indicated by the care-of
>       address in the Binding Update or the Binding Identifier mobility
>       option.  The BID is a 16-bit unsigned integer.  The value of zero
>       is reserved and MUST NOT be used.

The value MUST NOT be used. 2 questions:
  - maybe the rationale for that decision could be provided
  - what if a peer receives a BID with that value. What behavior is
    specified in that case and what will it allow if at some point that
    reserved value needs to be used?

>    Status
> 
>       The Status field is an 8-bit unsigned integer.  When the Binding
>       Identifier mobility option is included in a Binding
>       Acknowledgement, this field overwrites the status field in the
>       Binding Acknowledgement only for this BID.  If this field is set
>       to zero, the receiver ignores this field and uses the registration
>       status stored in the Binding Acknowledgement message.  The
>       receiver MUST ignore this field if the Binding Identifier mobility
>       option is not carried within either the Binding Acknowledgement or
>       the Care-of Test messages.  The possible status codes are the same
>       as the status codes of Binding Acknowledgement.  This Status field
>       is also used to carry error information related to the care-of
>       address test in the Care-of Test message.
> 
>    Simultaneous Home and Foreign Binding (H) flag
> 
>       This flag indicates that the mobile node registers multiple
>       bindings to the home agent while is attached to the home link.

                                   while it is attached

>       This flag is valid only for a Binding Update sent to the home
>       agent.
>
>    Reserved
> 
>       7 bits Reserved field.  The value MUST be initialized to zero by
>       the sender, and SHOULD be ignored by the receiver.

Why not a MUST for the receiver?

>    Care-of Address
> 
>       If a Binding Identifier mobility option is included in a Binding
>       Update for the home registration, either IPv4 or IPv6 care-of
>       address for the corresponding BID can be stored in this field.
>       For the binding registration to correspondent nodes (i.e. route
>       optimization), only IPv6 care-of address can be stored in this
>       field.  If no address is specified in this field, the length of
>       this field MUST be zero (i.e. not appeared in the option).  If the
>       option is included in any other messages than a Binding Update,
>       the length of this field MUST be also zero.
> 
> 4.4.  New Status Values for Binding Acknowledgement
> 
>    New status values for the status field in a Binding Acknowledgement
>    are defined for handling the multiple Care-of Addresses registration:
> 
>    MCOA NOTCOMPLETE (TBD less than 128)
> 
> 
> 
> 
> 
> 
> Wakikawa (Ed.), et al.  Expires October 22, 2009               [Page 15]
> 
> Internet-Draft                    MCoA                        April 2009
> 
> 
>       In bulk registration, not all the binding identifier mobility
>       options were successfully registered.  Some of them were rejected.
>       The error status value of the failed mobility option is
>       individually stored in the status field of the binding identifier
>       mobility option.
> 
>    MCOA RETURNHOME WO/NDP (TBD less than 128)
> 
>       When a mobile node returns home, it MUST NOT use Neighbor
>       Discovery Protocol (NDP) for the home address on the home link.
>       This is explained in more detail in Section 5.6
> 
>    MCOA MALFORMED (TBD more than 128)
> 
>       Registration failed because Binding Identifier mobility option was
>       not formatted correctly.  This value is used in the following
>       cases.
> 
>       *  when the wrong length value is specified (neither 4, 8 nor 20)
>          in the length field of the Binding Identifier mobility option.
> 
>       *  when a unicast routable address is not specified in the care-of
>          address field of the Binding Identifier mobility option.
> 
>       *  when a care-of address is not appeared in the care-of address

                             s/is not appeared/does not appear/

>          field of the Binding Identifier mobility option stored in an
>          IPsec ESP protected Binding Update.

> 5.3.  Bulk Registration
> 
>    Bulk registration is an optimization for binding multiple care-of
>    addresses to a home address using a single Binding Update.  This is
>    very useful if the mobile node, for instance, does not want to send a
>    lot of signaling messages through an interface where the bandwidth is
>    scarce.  This document specifies bulk registration only for the
>    mobile node's home registration.  A mobile node performing bulk
>    registration with a correspondent node is out of scope.
> 
>    To use bulk registration, the mobile node includes a Binding
>    Identifier Mobility option for each BID it wants to register in the
>    same Binding Update message.  As with single registrations (see
>    Section 5.1), the care of address field is included for BID

                       Care-of Address

> 5.4.  Binding De-Registration
> 
>    When a mobile node decides to delete all the bindings for its home
>    address, it sends a regular de-registration Binding Update with
>    lifetime set to zero as defined in [RFC-3775].  The Binding
>    Identifier mobility option is not required.
> 
>    If a mobile node wants to delete a particular binding(s) from its
>    home agent and correspondent nodes, the mobile node sends a Binding
>    Update with lifetime set to zero and includes a Binding Identifier
>    mobility option(s) with the BID(s) it wants to de-register.  The
>    receiver will remove only the care-of address(es) that match(es) the
>    specified BID(s).  Since de-registration attempts to remove a BID
>    that already exists, the care-of addresses field in each binding
>    identifier option can be omitted by the sender as defined in
>    Section 5.1.

why not change the last 'can' to a MUST then? 

> 5.5.  Returning Home: Using Single Interface

The title of this subsection is not very explicit, is it?

>    The mobile node may return to the home link, by attaching to the home
>    link through one of its interfaces.  When the mobile node wants to
>    return home, it should be configured with information on what
>    interface it needs to use.
> 
> 5.5.1.  Using only Interface attached to the Home Link
> 
>    The mobile node returns home and de-registers all the bindings as
>    shown in Figure 2 and as defined in [RFC-3775].

Should be more explicit: "The mobile node returns home and de-registers
all the bindings it has with the home agent as shown in Figure 2 and as
defined in [RFC-3775]."

>    After the de-registration step, all the packets routed by the home
>    agent are only forwarded to the interface attached to the home
>    link, even if there are other active interfaces attached to the
>    visited link(s).  While the mobile node de-registers all the
>    bindings from the home agent, it may continue registering bindings
>    for interface(s) attached to visited link(s) to the correspondent
>    node as shown in Figure 2. 
> 
> 5.5.2.  Using only Interface attached to the Visited Link
> 
>    The mobile node returns home physically but shuts down the interface
>    attached to the home link.  As a result, a mobile node does not
>    return home even though it attaches to the home link by one of
>    interfaces.  Before shutting down the interface, any binding for the
>    care-of address previously associated with the interface should be
>    deleted as defined in .

     this sentence ends badly ...

>    In this scenario, despite the fact that the mobile node is connected
>    to its home link, all of its traffic is sent and received via the
>    home agent and its foreign links.

After reading those two paragraph, this "functionality" seems weird, to
say the least. Can someone provide any rationale? or network
architecture where it is beneficial to do that? In that case, would it
not be better to consider the MN is never at home, i.e. has no home
network instead of that trick? 

> 5.6.  Returning Home: Simultaneous Home and Visited Link Operation
> 
> 5.6.1.  Problems of Simultaneous Home and Foreign Attachments
> 
>    The mobile node returns home and continues using all the interfaces
>    attached to both foreign and home links as shown in Figure 3.
> 
>    In [RFC-3775], the home agent intercepts packets meant for the mobile
>    node using Proxy Neighbor Discovery [RFC-4861] while the mobile node
>    is away from the home link.  When the mobile node returns home, the
>    home agent deletes the binding cache and stops proxying for the home
>    address so that a mobile node can configure its home address on the
>    interface attached to the home link.  In this specification, a mobile
>    node may return home, configure the home address on the interface
>    attached to the home link, but still use the interfaces attached to
>    the foreign links.  In this case, a possible conflict arises when the

                                                        s/when the/when/

>    both the home agent and the mobile node try to defend the home
>    address.  If the home agent stops proxying for the home address, the
>    packets are always routed to the interface attached to the home link
>    and are never routed to the interfaces attached to the visited links.
>    It is required to avoid the conflict between the home agent and the
>    mobile node, while still allowing the simultaneous use of home and
>    foreign links.  The following describes the mechanism for achieving
>    this.
> 
> 5.6.2.  Overview and Approach
> 
>    The home agent MUST intercept all the packets meant for the mobile
>    node whether the mobile node is attached to the home link or not and
>    decide whether to send the traffic directly to the home address on
>    the link or tunnel to the care-of address.
> 
>    Two scenarios are illustrated in Figure 3, depending on whether the
>    Home Agent is the only router at the home link or not.  The
>    difference is on who defends the home address by (Proxy) Neighbor
>    Discovery on the home link.
> 
>    1.  Mobile node defends the home address by the regular Neighbor
>        Discovery Protocol (illustrated as topology-a in Figure 3).  The
>        home agent is the only router on the home link.  Therefore the
>        home agent is capable of intercepting packets without relying on
>        the proxy Neighbor Discovery protocol and the mobile node can
>        manage the Neighbor Cache entry of the home address on the home
>        link as a regular IPv6 node.  However, there is one limitation of
>        this scenario.  If a correspondent node is located at the home
>        link, the home agent may not intercept the packets destined to
>        the mobile node.  These packets are routed only via the home
>        link, but this is the most optimal path for the mobile node to
>        communicate with nodes on the home link.
> 
>    2.  If there are other routers on the home link apart from the home
>        agent, then it cannot be guaranteed that all packets meant for
>        the mobile node are routed to the home agent.  In this case, the
>        mobile node MUST NOT operate the Neighbor Discovery protocol for
>        the home address on the home link.  This allows the home agent to
>        keep using proxy neighbor discovery and thus it keeps receiving
>        all the packets sent to the mobile node's home address.  If the
>        home agent, according to its local policy, needs to deliver
>        packets to the mobile node over the home link, an issue arises
>        with respect to how the home agent discovers the mobile node's
>        link local address.  This specification uses the Mobility Header
>        Link-layer Address Option defined in [RFC-5268] in order to carry
>        the mobile node's link-layer address in the Binding Update.
>        Likewise, the mobile node would also know the link-layer address
>        of the default router address to send packets from the home link
>        without Neighbor Discovery.  The link-layer address is used to
>        transmit packets from and to the mobile node on the home link.
>        The packets are transmitted without the Neighbor Discovery
>        protocol by constructing the link-layer header manually.  This
>        operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
>        sends a deregistration binding update to the home agent's link-
>        layer address in the operation for returning home.
> 
> 5.6.3.  Home Binding Support
> 
>    When the home binding is used, the mobile node MUST send a
>    registering binding update with a Binding Identifier mobility option
>    whith H flag set.  The lifetime MUST be set to a non-zero lifetime of
>    the home binding, and the care-of address MUST be set to the home
>    address.

as discussed 2 days ago on the list, it may be good to explicitly states
the fact that this specific format of a de-registration BU in 3775 and
that the draft changes that behavior. 

> 6.5.  Receiving Packets from Mobile Node
> 
>    When a node receives packets with a Home Address destination option
>    from a mobile node, it MUST check that the care-of address that
>    appears in the source address field of the IPv6 header MUST be equal

                                                        s/MUST/is/

>    to one of the care-of addresses in the binding cache entry.  If no
>    binding is found, the packets MUST be discarded.  The node MUST also
>    send a Binding Error message as specified in [RFC-3775].  This
>    verification MUST NOT be done for a Binding Update.
> 
> 8.  DSMIPv6 Applicability

I skipped section 8.

> 9.  IPsec and IKEv2 interaction
> 
>    Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
>    use of IPsec to protect signaling messages including Binding Updates,
>    Binding Acknowledgement and return routability messages.  IPsec may
>    also be used protect all tunneled data traffic.  The Mobile IPv6-
>    IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to
>    setup the required IPsec security associations.  The following
>    assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with
>    respect to the use of IKEv2 and IPsec.
> 
>    o  There is only one primary care-of address per mobile node.
> 
>    o  The primary care-of address is stored in the IPsec database for
>       tunnel encapsulation and decapsulation.
> 
>    o  When the home agent receives a packet from the mobile node, the
>       source address is verified against the care-of address in the
>       corresponding binding cache entry.  If the packet is a reverse
>       tunneled packet from the mobile node, the care-of address check is
>       done against the source address on the outer IPv6 header.  The
>       reverse tunnel packet could either be a tunneled Home Test Init
>       message or tunneled data traffic to the correspondent node.
> 
>    o  The mobile node runs IKEv2 (or IKEv1) with the home agent using
>       the care-of address.  The IKE SA is based on the care-of address
>       of the mobile node.
> 
>    The above assumptions may not be valid when multiple care-of
>    addresses are used by the mobile node.  In the following sections,
>    the main issues with the use of multiple care-of address with IPsec
>    are addressed.

Good overview.

> 9.1.  Use of Care-of Address in the IKEv2 exchange
> 
>    For each home address the mobile node sets up security associations
>    with the home agent, the mobile node must pick one care-of address
>    and use that as the source address for all IKEv2 messages exchanged
>    to create and maintain the IPsec security associations associated
>    with the home address.  The resultant IKEv2 security association is
>    created based on this care-of address.
> 
>    If the mobile node needs to change the care-of address, it just sends
>    a Binding Update with the care-of address it wants to use, with the
>    corresponding Binding Identifier mobility option, and with the 'K'
>    bit set.  This will force the home agent to update the IKEv2 security
>    association to use the new care-of address.  If the 'K' bit is not
>    supported on the mobile node or the home agent, the mobile node MUST
>    re-establish the IKEv2 security association with the new care-of
>    address.  This will also result in new IPsec security associations
>    being setup for the home address.

If I understand those two paragraphs correctly, the new CoA to be used
by IKE upon movement is announced to the HA by sending a BU with K bit
set and a single Binding Identifier mobility option. So, can you
confirm the following: 

 - until the HA receives such a BU with the K bit set, it considers that
   the IKE module on the MN does not support dynamic update of IKE_SA.
 - the MN cannot send multiple BID in a BU with the K bit set which
   means that multiple BU will be needed when the IKE module on the MN
   supports update.

Instead of doing that, I think it would be easier and more efficient to
consume a flag in the Binding Identifier Mobility option in order to
express which CoA should be used for IKE communication with the remote
IKE module. That way a perfectly sane MIPv6/IKE implementation
(i.e. supporting IKE_SA update) would not need to send multiple BU just
to express the IKE address to be used.

In that paragraph, it should also be stated explicitly that the pointed
CoA should be used for all the IKE exchanges between the MN and the HA,
i.e. that it should also be used for the IKE packet sent from the HA for
things related to tunnel mode SAs (even if that is probably expected).

> 9.2.  Transport Mode IPsec protected messages
> 
>    For Mobile IPv6 signaling message protected using IPsec in transport
>    mode, the use of a particular care-of address among multiple care-of
>    addresses does not matter for IPsec processing.
> 
>    The home agent processes Mobile Prefix Discovery messages with the
>    same rules of data packets described in Section 6.5.

ok.

> 9.3.  Tunnel Mode IPsec protected messages
> 
>    The use of IPsec in tunnel mode with multiple care-of address
>    introduces a few issues that require changes to how the mobile node
>    and the home agent send and receive tunneled traffic.  The route
>    optimization mechanism described in [RFC-3775] mandates the use of
>    IPsec protection in tunnel mode for the Home Test Init and Home Test
>    messages.  The mobile node and the home agent may also choose to
>    protect all reverse tunneled payload traffic with IPsec in tunnel
>    mode.  The following sections address multiple care-of address
>    support for these two types of messages.

ok.

> 9.3.1.  Tunneled Home Test Init and Home Test messages
> 
>    The mobile node MAY use the same care-of address for all Home Test
>    Init messages sent reverse tunneled through the home agent.  The
>    mobile node may use the same care-of address irrespective of which
>    correspondent node the Home Test Init message is being sent.  RFC
>    3775 requires the home agent to verify that the mobile node is using
>    the care-of address that is in the binding cache entry, when it
>    receives a reverse tunneled Home Test Init message.  If a different
>    address is used as the source address, the message is silently
>    dropped by the home agent.  This document requires the home agent
>    implementation to decapsulate and forward the Home Test Init message
>    as long as the source address is one of the care-of addresses in the
>    binding cache entry for the mobile node.
> 
>    When the home agent tunnels a Home Test message to the mobile node,
>    the care-of address used in the outer IPv6 header is not relevant to
>    the Home Test message.  So regular IPsec tunnel encapsulation with
>    the care-of address known to the IPsec implementation on the home
>    agent is sufficient.
> 
> 9.3.2.  Tunneled Payload Traffic
> 
>    When the mobile sends and receives multiple traffic flows protected
>    by IPsec to different care-of addresses, the use of the correct
>    care-of address for each flow becomes important.  Support for this
>    requires the following two considerations on the home agent.
> 
>    o  When the home agent receives a reverse tunneled payload message
>       protected by IPsec in tunnel mode, the source address used in the
>       outer IPv6 header is irrelevant to IPsec, since the tunnel mode
>       security association is based on the addresses in the inner IPv6
>       header.  Therefore, the same IPsec security association can be
>       used for payload traffic tunneled from any of the care-of
>       addresses.  Note that the care-of address used in the reverse
>       tunneld traffic can be different from the care-of address used

        tunneled

>       as the source address in the IKEv2 exchange.  However, this does
>       not cause an issue due to the above mentioned reason.
> 
>    o  For tunneled IPsec traffic from the home agent to the mobile node,
>       the IPsec implementation on the home agent will not be aware of
>       which care-of address to use when performing IPsec tunnel
>       encapsulation.

The IPsec tunnel encapsulation is done based on the installed security
policies. Either there is no security policy whose selectors match the
traffic or there is a tunnel mode SP (whose selectors reflects a
specific flow binding) in order for matching traffic to be sent securely
to the peer *at a given CoA*. In any case, the tunnel SP will reference
the given CoA as tunnel endpoints. The point being that this SP will
require a specific SA with the CoA as destination and will never (at
least w/o modifications to the IPsec stack) use another SA that
reference another CoA. Simply put, you will be able to reuse a SA for
various flow towards a given CoA but you will have to negotiate as many
SA as CoA (in fact twice that value to cope with both directions).

>       The Mobile IP stack on the home agent, based on the binding
>       cache entries created by the mobile node, knows which care-of
>       address the packet belonging to a particular flow needs to 
>       be tunneled to.

Agree that it knows that but this is of no help ...

>       The destination address for the outer IP header
>       must either by conveyed dynamically per packet to the IPsec stack
>       when it performs the encapsulation

seems quite a change to current IPsec processing if done in the IPsec
stack. The problem will also remain at the receiver (the MN), because
it will not have a matching SA.

>       or the Mobile IPv6 stack must get access to the packet after
>       IPsec processing is done and modify the destination address.

Like the remapping rules I have in my IRO draft. Those changes to an
IPsec stack are not easy to do.

>       The first option requires changes to the IPsec implementation.
>       In the second option, there is a need for special processing in
>       the forwarding function to replace the destination address on
>       the outer header with the correct care-of address.

The same kind of thing is needed on the receiver too in order for the
(destination) address to be remapped to that of the SA.

>       The exact technique to achieve the above is implementation
>       specific.

Well, the clean way to do that is to setup one IPsec tunnel per CoA and
do the same thing as usual when a CoA changes (update all associated SPs
and the associated SA). As per RFC 3775 requirements, the IPsec stack is
expected to support that kind of update (for instance, using
MIGRATE/KMADDRESS mechanism).

As for the negotiation of those tunnel SA, the usual way is to use the
local endpoint address for the negotiation on the MN but I think it may
be beneficial to avoid doing that and specifically use the address used
by the already existing IKE_SA set up for the nego of the transport mode
SA (if another IKE_SA is needed). More precisely, I think it would be
good to decide and state that the IKE negotiation of the tunnel mode SA
should be done using the CoA pointed by the "I" flag.

Cheers,

a+

ps: some authors of flow-binding draft are in the recipients to get
    there feedback on the proposals.

---

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

Hi Arnaud,

> should be directly sent to the HoA. Hence, the idea of asosciating  

Thanks for texts. However, I would limit the number of changes in the  
doc at this stage.
I slightly modify the text according to your points.

    1.  The mobile node uses only the interface with which it attaches  
to
        the home link and takes back full ownership of its HoA on the
        home link.  This is illustrated in Figure 2.  It de-registers  
all
        bindings with the home agent related to all care-of addresses.
        The interfaces still attached to the visited link(s) are no
        longer going to be receiving any encapsulated traffic from the
        home agent.  On the other hand, the mobile node can continue
        communicating with the correspondent node from the other
        interfaces attached to foreign links by using route  
optimization.
        Even if the mobile node is attached to the home link, it can
        still send Binding Updates for other active care-of addresses
        (CoA1 and CoA2) to correspondent nodes.  Since the correspondent
        node has bindings, packets are routed from and to each Care-of
        Addresses directly.

>    reserved value needs to be used?

This is actually SHOULD NOT.
This is error when I updated the document.

In section 5.1, we've had the update texts.
    "A mobile node assigns a BID to each care-of address when it wants  
to
    register them simultaneously with its home address.  The BID MUST be
    unique for a given home address.  The value is an integer between 1
    and 65535.  Zero value SHOULD NOT be used as BIDs.  If a mobile node
    has only one care-of address, the assignment of a BID is not needed
    until it has multiple care-of addresses to register with, at which
    time all of the care-of addresses MUST be mapped to BIDs."

Any future document can overwrite this spec.
As for MCoA, we don't use zero value.

There is background story here. The flow binding document needs  
default binding.
We had used zero value to specify the default binding in MCoA.

After the long discussion in WG, we agreed not to have this value in  
MCoA.
The default binding should be defined in the flow binding.

> Why not a MUST for the receiver?

This is error, too. It should be MUST

> why not change the last 'can' to a MUST then?

This is just optimization. It's up to MN whether saving bits or not.

> The title of this subsection is not very explicit, is it?

any proposal?

> all the bindings it has with the home agent as shown in Figure 2 and  

ok, fixed.

>     this sentence ends badly ...

right, there was typo at xml tag.

> network instead of that trick?

again, this was also discussed.
Please check my slide at IETF 67 monami's WG meeting at 2006 Nov.
http://www.ietf.org/proceedings/06nov/slides/monami6-0.pdf

If you were there, we might beat this simultaneous things:-p
At that time, I was alone to be against this.
> that the draft changes that behavior.

The de-registration BU is obvious from the spec.
I don't know we should have all the possible packet formats.
Specially this packet is somehow clear from the texts.

We did the same for binding update. The differences are same for both  
BUs (registering/de-registering).

Thanks for the detailed comment!

regards,
ryuji

---

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

Hi,

Ryuji Wakikawa <[email-masked]> writes:

>        to the home link and takes back full ownership of its HoA on
>        the home link.  This is illustrated in Figure 2.  It
>        de-registers all bindings with the home agent related to all
>        care-of addresses. The interfaces still attached to the visited
>        link(s) are no longer going to be receiving any encapsulated
>        traffic from the home agent.  On the other hand, the mobile
>        node can continue communicating with the correspondent node

                                                        s/node/nodes/

>        from the other interfaces attached to foreign links by using
>        route optimization. Even if the mobile node is attached to the
>        home link, it can still send Binding Updates for other active
>        care-of addresses (CoA1 and CoA2) to correspondent nodes.
>        Since the correspondent node has bindings, packets are routed
>        from and to each Care-of Addresses directly.

Fine with me (would just change "node" into "nodes").

>>>   Binding ID (BID)
>>>
>>>      The BID which is assigned to the binding indicated by the
>>> care-
>>> of

Ack.

> The default binding should be defined in the flow binding.

Ok, thanks for the background. That's what I was looking for.

> This is error, too. It should be MUST

Ack.

> This is just optimization. It's up to MN whether saving bits or not.

I have not checked if this is specified but what will the peer do if the
address (if provided, obviously) is not the current one? If the address
is not used for the deletion and can just create trouble, a MUST would
just help.

>> The title of this subsection is not very explicit, is it?

   - Returning Home with complete ownerhsip of the HoA
or - Returning Home with full de-registration with the HA

something like that, which explains what really happens.

> http://www.ietf.org/proceedings/06nov/slides/monami6-0.pdf

Thanks for the pointer. Interesting slides.

> At that time, I was alone to be against this.

Too bad, indeed. I was writing a comment about the impact of 3GPP
architecture in the spec, but I just erased it. It's in fact pointless
to discuss that here :-|

> BUs (registering/de-registering).

MCoA is clear on the expected format. I just say that you reuse a packet
format which in 3775 expresses just the reverse.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 May 2009 14:33:38 +0200

Hello Ryuji, 

Cutting thru quite a bit:

On Monday 11 May 2009, Ryuji Wakikawa wrote:
> [...]
> >> care- of
> >>      address in the Binding Update or the Binding Identifier
> >> mobility option.  The BID is a 16-bit unsigned integer.  The value
> >> of zero
> >    specified in that case and what will it allow if at some point
> > that reserved value needs to be used?
>
>     "A mobile node assigns a BID to each care-of address when it
> wants to
>     register them simultaneously with its home address.  The BID MUST
> be unique for a given home address.  The value is an integer between
> 1 and 65535.  Zero value SHOULD NOT be used as BIDs.  If a mobile
> node has only one care-of address, the assignment of a BID is not
> needed until it has multiple care-of addresses to register with, at
> which time all of the care-of addresses MUST be mapped to BIDs."
>

Sorry to jump in the discussion, but IMHO what you want to achieve would 
actually be better reflected with the following than by a "value zero 
SHOULD not be used":

In 4.3.
-------

   Binding ID (BID)

      The BID which is assigned to the binding indicated by the care-of
      address in the Binding Update or the Binding Identifier mobility
      option.  The BID is a 16-bit unsigned integer.  The value of zero
      is reserved and MUST NOT be set by the sender and MUST be treated
      as an error by the receiver (MCOA MALFORMED).

In 5.1.
-------

   A mobile node assigns a BID to each care-of address when it
   wants to register them simultaneously with its home address. For a
   given home address, the assigned BID MUST be a unique integer between
   1 and 65535. The BID value zero MUST NOT be assigned, MUST NOT be
   sent in a Binding Identifier Mobility Option, and MUST be treated as
   an error (MCOA MALFORMED) by the receiver of a Binding Identifier
   Mobility Option. If a mobile node has only one care-of address, the
   assignment of a BID is not needed until it has multiple care-of
   addresses to register with, at which time all of the care-of
   addresses MUST be mapped to BIDstoo.

What do you think?

--julien