Subject: [MEXT] MCoA Update [pre07]

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 15 Apr 2008 14:55:22 +0000

Hello all,

I revised the draft according to the discussions 
at the last IETF meeting. 
I haven't submitted this to the IETF, please 
fetch the document from

http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6-multiplecoa-07.txt

The diff from the previous draft is also available at 
http://www.sfc.wide.ad.jp/~ryuji/mcoadiff.html

Please take a look and provide your comments.

thanks,
ryuji

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 15 Apr 2008 13:29:43 +0100

Hi Ryuji,

This looks really good.
I have a number of detailed comments which should be easy to resolve,

1) You may want to use the IPv6 prefix (2001:DB8::/32) reserved for
documentation (see RFC3849)
2) I am suggesting that when the H flag is set in the BU, it should be
viewed as a registration, rather than de-registration.

More comments inline...

Thanks
George
--------------------------------------------------------------------------------------------

3.  Protocol Overview
…
   1.  The mobile node uses only the interface with which it attaches to
       the home link illustrated in Figure 2.  It de-registers all
       bindings related to all care-of addresses to the home agent.  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
       (CoA2 and CoA3) to correspondent nodes.  Since the correspondent
       node has bindings, packets are routed to each Care-of Addresses
       directly.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +--------+-+          +--+-+
        CoA2|               |               |   Home Link
         +--+--+            |         --+---+------
         |  MN +========+   |           |
         +--+--+        |   |           |
        CoA3|           +---|-----------+
            +---------------+

     Binding Cache Database:
        home agent's binding
              none
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address2  BID2]
              binding [a:b:c:d::EUI  care-of address3  BID3]

             Figure 2: Using only Interface Attached to Home Link

GT> Why is this figure different than the others below? Is the home
link crossing over the CoA3 link, necessary? The figure could be shown
as the once below no?

…
   3.  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 4.  There are two possible
       topologies whether the home agent is single router at the home
       link or not.  The operation of Neighbor Discovery [RFC-2461] is
       different in the two topologies.  The home agent and the
       correspondent node have the binding entries listed in Figure 4 in
       their binding cache database in both topologies.  The home agent
       also knows that the mobile node has attached to the home link.
       All the traffic from the Internet are intercepted by the home

GT> //are/is

       agent first and routed to either the interface attached to the
       home link or the one attached to the foreign links.  How to make

GT> // the one attached to the foreign links./to one of the foreign links.

       the decision is out of scope in this document.

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 10]

Internet-Draft                    MCoA                        April 2008

   Topology-a)
                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +----+-----+          +--+-+
        CoA2|           |                   |   Home Link
         +--+--+        |             --+---+------
         |  MN +========+               |
         +--+--+ CoA1                   |
       CoA3 |                           |
            +---------------------------+

   Topology-b)
                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+    Router    +----+
            +------+ Internet |-------R      | HA |
            |      +----+-----+       |      +--+-+
        CoA2|           |             |         |   Home Link
         +--+--+        |           --+-+-------+------
         |  MN +========+               |
         +--+--+ CoA1                   |
       CoA3 |                           |
            +---------------------------+

GT> I think the CoA3 shown in this figures should not be there, tight?

     Binding Cache Database:
        home agent's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]

            Figure 4: Simultaneous Home and Visited Link Operation

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 11]

Internet-Draft                    MCoA                        April 2008

4.  Mobile IPv6 Extensions

   This section summarizes the extensions to Mobile IPv6 necessary for
   manage multiple bindings.

4.1.  Binding Cache Structure and Binding Update List

   The BID is required to be stored in the binding cache and binding
   update list structure.

   The sequence number value SHOULD be shared among all the binding
   update list.  Whenever a mobile node sends either individual or bulk
   binding update, the sequence number is incremented the value of the
   previous sequence number.

GT>// is incremented the value of the previous sequence number. // is
incremented.

 On the other hand, if a mobile node
   manages an individual sequence value per binding update list, a
   mobile node SHOULD carefully select the sequence number value for the
   bulk binding update.  This is because all the bulk-registered
   bindings use the same Sequence Number specified in the Binding
   Update.  If each binding uses different sequence number, a mobile
   node MUST use the largest sequence number from the Binding Update
   list entries used for the bulk registration.  If the mobile node
   cannot select a sequence number for all the bindings due to sequence
   number out of window, it MUST NOT use the bulk registration for the
   binding whose sequence number is out of window.  A separate Binding
   Update should be sent for the binding.

4.2.  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.

                      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    |C|O|H|D|Resrvd |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       :                 IPv4 or IPv6 care-of address (CoA)            :
       +                                                               +
       +---------------------------------------------------------------+

                       Figure 5: BID Mobility Option

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 12]

Internet-Draft                    MCoA                        April 2008

   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 4 when
      the 'C' flag is unset.  Otherwise, the Length value MUST be set to
      either 8 or 20 depending on the 'D' (DSMIPv6) flag.

   Binding ID (BID)

      The BID which is assigned to the binding indicated by the care-of
      address in the Binding Update or the BID mobility option.  The BID
      is a 16-bit unsigned integer.  The value of zero is reserved and
      MUST NOT be used.

   Status

      When the Binding Identifier mobility option is included in a
      Binding Acknowledgement, this field overwrites the status field in
      the Binding Acknowledgement.  If this field is zero, the receiver
      MUST use the registration status stored in the Binding
      Acknowledgement message.  This Status field is also used to carry
      error information related to the care-of address test in the
      Care-of Test message.  The status is 8-bit unsigned integer.  The
      possible status codes are the same as the status codes of Binding
      Acknowledgement.

   Care-of address (C) flag

      When this flag is set, it indicates that a valid care-of address
      is present in the care-of address field in the BID mobility
      option.  This flag MUST be set whenever the mobile node sends
      multiple care-of addresses in a single Binding Update, i.e., bulk
      registration.  It MAY also used as a substitute for alternate

GT> //It MAY also used/It MAY also be used

      care-of address option even for Binding Updates that are sent only
      for one care-of address.  This flag is valid only for Binding
      Update sent to the home agent.

   Overwrite (O) flag

      When this flag is set, a mobile node requests the recipient to
      replace all the bindings to binding entries stored in a Binding
      Update.

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 13]

Internet-Draft                    MCoA                        April 2008

   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.
      This flag is valid only for a Binding Update sent to the home
      agent.

   DSMIPv6 (D) flag

      This flag indicates that the care-of address is an IPv4 address.
      When this flag is set, the care-of address field MUST contain an
      IPv4 address.

GT> I can not remember if this was ever discussed but do we really
need flags C and D? It seems to me that the Length field can be 4 (CoA
not included), 12 (v4CoA), or 20 (v6CoA), which provides all the info
we need.

   Reserved

      5 bits Reserved field.  The reserved field MUST be zero.

   Care-of Address

      This field has the variable length depending on the specified
      flags.  When the 'C' flag is set and the 'D' flag is not, an IPv6
      care-of address for the corresponding BID is stored in this field.
      If both 'C' and 'D' flags are set, an IPv4 Care-of Address is
      carried in this field.  This field MUST NOT be used if a Binding
      Identifier mobility option is included in any other message other
      than a Binding Update or if the 'C' flag is not set.

…
4.4.  Link Layer Address Mobility Option

   The Link Layer Address mobility option is included only in the
   deregistration Binding Update when a mobile node returns home with
   simultaneous home and foreign attachment support described in
   Section 5.6.3.  This option contains the link-layer address of the
   sender of the Binding Update (i.e. a mobile node).  This option MUST
   be silently ignored for other mobility header messages.

GT> I think the term ?silently? is used in the context of dropping a
packet/message i.e., ?silently discard?. In this case maybe we should
just say ?ignored?.

                      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    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +                                                               +
       :                        Link Layer address                     :
       +                                                               +
       +---------------------------------------------------------------+

                       Figure 6: BID Mobility Option

GT> Figure caption seems wrong. Also, has such option never been
defined for MIPv6 before? I see that PMIPv6 draft also defined the
same option. I would hope that only one such option is needed for all
flavors of MIPv6?

…
5.6.  Returning Home

   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.  The mobile node may use only the
   interface with which it is attached to the home link, only the
   interfaces still attached to the visited link or use both interfaces

GT> // visited link/ visited link(s)

   attached to the home link and visited link simultaneously.  The

GT> // visited link/ visited link(s)

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 19]

Internet-Draft                    MCoA                        April 2008

   following describes each option in more detail.

5.6.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].  De-registering all
   the bindings is the same as binding de-registration from foreign link

GT> delete ?from foreign link?

   described in Section 5.5.  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.  While the mobile node de-registers all

GT> // visited link/ visited link(s)

   the bindings from the home agent, it may continue registering
   bindings for interface attached to visited link to the correspondent

GT> //interface attached to visited link/ interface(s) attached to
visited link(s)

   node as shown in Figure 2.

5.6.2.  Using only Interface attached to the Visited Link

   The mobile node returns home and shuts down the interface attached to
   the home link as shown in Figure 3.  Before shutting down the
   interface, any binding for the care-of address previously associated
   with the interface should be deleted. To delete the binding cache
   entry, the mobile node SHOULD send a de-registration Binding Update
   with the lifetime set to zero and include the corresponding BID
   information.  If the mobile node does not send a de-registration
   Binding Update, the binding for the care-of address previously
   assigned to the interface remains at the home agent.

GT> // at the home agent/ at the home agent until its lifetime expires

 This binding is
   deleted only when it expires.  In order to avoid this, the mobile
   node SHOULD send a de-registration binding update for the interface
   attached to the home link.

GT> I think the above can be removed (the SHOULD is repeated above and
the rest is already explained).

   This scenario is not the most efficient because all the traffic to
   and from the mobile node is going through the bi-directional tunnel,
   whereas the mobile node is now accessible at one hop on the home link
   from its home agent.

GT> To avoid judgment calls maybe we can revise this to the following:
?   In this scenario, despite the face that the mobile node is
connected to its home link, all of its traffic is send and received
via the HA and its foreign links.?

5.6.3.  Simultaneous Home and Visited Link Operation

   [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 4.  The
   mobile node indicates this by setting the 'H' flag in the BID
   mobility option as defined below.  There are additional requirements
   on the Returning Home procedures for possible Neighbor Discovery
   states conflicts at the home link.

   In [RFC-3775], the home agent intercepts packets meant for the mobile

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 20]

Internet-Draft                    MCoA                        April 2008

   node using the Proxy Neighbor Discovery [RFC-2461] 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 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.

   [Overview and Approach]

   In this specification, the home agent MUST intercept all the packets
   meant for the mobile node and decide whether to send the traffic
   directly to the home address on the link or tunnel to the care-of
   address.  The home agent intercepts all the packets even when the
   mobile node is attached to the home link through one of its
   interfaces.  The home agent would make this decision based on the
   type of packets and flows.  How to make this decision is out of scope
   in this document.

   Even when the mobile node returns home, how can home agent intercept
   the packets meant for the mobile node at the home link on behalf of
   the mobile node?

GT> The question above can be removed.

 We introduce two possible scenarios, illustrated in

GT> //We introduce two possible scenarios, illustrated / Two scenarios
are illustrated

   Figure 4, depending on whether the Home Agent is a single router at
   the home link or not.  The difference is who will defend 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 4).  The
       home agent is the single router to the Internet 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.

   2.  Home agent continue intercepting the mobile node's packets using
       proxy Neighbor Discovery even after the mobile node's returning
       home (illustrated as topology-b in Figure 4).  The home agent
       cannot intercept all the packets meant for the mobile node by IP

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 21]

Internet-Draft                    MCoA                        April 2008

       routing due to multiple routers on the home link.  Due to the
       possible competing neighbor cache state for the home address, the
       mobile node SHOULD NOT operate Neighbor Discovery protocol for
       the home address on the home link. The problem arises when the
       home agent perform the neighbor discovery to resolve the link-
       layer address of the mobile node on the home link.  Since the
       mobile node never answers to the Neighbor Discovery packets for
       the home address, the home agent would need to know the Link-
       Layer address of the interface with which the mobile node is
       attached to the home link in other way.

GT> I re-wrote the above to make it clearer:
"The home agent cannot naturally intercept all the packets meant for
the mobile node by IP routing due to multiple routers on the home
link. In this case, the mobile node MUST NOT operate 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
       introduces a new Link-Layer Address mobility option carrying 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 returning home operation.

   [Sending Deregistration Binding Update]

   o  As soon as a mobile node returns home, it sends a de-registration
      Binding Update to the home agent from the interface attached to
      the home link.

GT> I think throughout the description of this mode of operation the
MN sends a *registration* not a *de-registration*. In fact you should
add somewhere that "A BU with H flag set MUST have a non-zero
Lifetime"

   o  The mobile node MUST include the BID mobility option specifying
      the BID the mobile node had previously associated with the
      interface attached to the home link.  The 'H' flag MUST be set in
      the BID mobility option.  The 'C' flag MUST NOT be set and the
      care-of address field MUST NOT be included.  When the 'H' flag is
      set, the home agent recognizes that the mobile node wants to
      continue using interfaces attached to both home and visited links.
      Note that H flag MUST be set for all the binding updates sent from
      the mobile node (ex.  Binding Update for the interface attached to
      the foreign link).

GT>// for the interface attached to the foreign link)./ for the
interface(s) attached to foreign link(s)).

   o  The mobile node SHOULD include the Link-Layer address mobility
      option to notify the mobile node's link-layer address to the home
      agent, too.  This link-layer address is required for the home
      agent to send the Binding Acknowledgement and to forward the
      mobile node's packet.

   o  According to [RFC-3775], the mobile node MUST start responding to
      Neighbor Solicitation for its home address right after it sends

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 22]

Internet-Draft                    MCoA                        April 2008

      the deregistration Binding Update to the home agent.  However, in
      this specification, the mobile node MUST NOT respond to Neighbor
      Solicitation before receiving a Binding Acknowledgement, since the
      home agent may continue proxying for the home address.

GT> the MN must not respond to NS messages before and *after*
receiving the BA, right?

   [Sending Binding Acknowledgement]

   o  When the home agent sends the Binding Acknowledgement after
      succeeding the binding de-registration, it MUST set the status
      value to either 0 [Binding Update Accepted] or to [MCOARETURNHOME
      WO/NDP (TBD)] in the BID mobility option depending on home agent
      configuration at the home link.  The new values are:

      *  Binding Update Accepted (0): NDP is permitted for the home
         address at the home link.  This is regular returning home
         operation of [RFC-3775]

      *  MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
         address at the home link

      If the binding update is rejected, the appropriate error value
      MUST be set to the status field.  In this case, the home agent
      operation is same as [RFC-3775].

   o  If the home agent is the only router at the home link, it stops
      proxy Neighbor Discover for the requested home address and
      responds with the [Binding Update Accepted] status value to the
      mobile node.  Since the mobile node will not reply to Neighbor
      Solicitation for the home address before receiving the Binding
      Acknowledgement, the home agent SHOULD use the link-layer address
      carried by the Link Layer Address mobility option in the received
      Binding Update.  After the completion of the binding
      deregistration, the mobile node starts regular Neighbor Discovery
      operations for the home address on the home link.  The neighbor
      cache entry for the home address is created by the regular
      exchange of Neighbor Solicitation and Neighbor Advertisement.

   o  On the other hand, if the home agent is not the only router on the
      home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status
      field of the BID mobility option.  The home agent learns the
      mobile node's link-layer address by receiving the link-layer
      address mobility option carried by the Binding Update.  It stores
      the link-layer address as a neighbor cache entry for the mobile
      node so that it can send the packets to the mobile node's link-
      layer address.

GT> It should be clarified that even if the HA is the only router on
the link, it might still make sense to continue Proxy-NDP as normal.
On shared links, this is probably the easiest way of intercepting
packets, as opposed to snooping. In any case, it is an implementation
choice.

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 23]

Internet-Draft                    MCoA                        April 2008

   o  If BID option is missed in the Binding Acknowledgement, the home
      agent might not recognize the simultaneous home and foreign
      attachment.  The home agent might process the de-registration
      Binding Update as one of [RFC-3775] and deletes all the registered
      binding cache entries for the mobile node.  Thus, the mobile node
      SHOULD stop using the interface attached to foreign link and use
      only the interface attached to the home link.

   [Sending Packets from the Home Link]

   o  When the mobile node receives the Binding Acknowledgement which
      status value is [Binding Update Accepted] and BID option, it can
      configure its home address to the interface attached to the home
      link and start operating Neighbor Discovery for the home address
      on the home link.  Packets can be transmitted from and to the
      mobile node as if the mobile node is a regular IPv6 node.

   o  If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST
      NOT operate Neighbor Discovery for the home address.  When the
      mobile node sends packets from the interface attached to the home
      link, it MUST learn the link-layer address of the next hop (i.e.
      default router of the mobile node).  A mobile node learns the
      default router's link-layer address from a Source Link-Layer
      Address option in Router Advertisements.  The mobile node sends
      packets directly to the default router's link-layer address.  This
      is done by constructing the packet including link-layer header
      with the learned link-layer address of the default router.  The
      home agent also forwards the packet to the mobile node on the home
      link by using the mobile node's link-layer address.  The link-
      layer address SHOULD be cached when the home agent received the
      deregistration Binding Update message.

   [Leaving from the Home Link]

   o  When the mobile node detaches from the home link, it SHOULD
      immediately send a binding update for one of active care-of
      address with H flag unset.  When the 'H' flag of BID option is
      unset in any Binding Update, the home agent stop forwarding the
      mobile node's packet to the home link.

   o  On the other hand, if the mobile node does not have any active
      care-of address to send a Binding Update and leaves the home link
      (i.e. the mobile node is completely disconnected), the home agent
      continues forwarding packets to the mobile node until the
      expiration of all the binding cache entries for the home address.
      Once all the bindings are expired, the mobile node is assumed to

Wakikawa (Editor), et al.  Expires October 17, 2008            [Page 24]

Internet-Draft                    MCoA                        April 2008

      be disconnected completely from networks.

   [Changing Behavior during the attachment to the home link]

   When a mobile node would change the home operation to Section 5.6.1
   or Section 5.6.2, following procedure should be taken.

GT> Remove the above sentence

   If a mobile node decides to return home completely without any active
   foreign link attachment, it simply sends a deregistration binding
   update as described in Section 5.6.1.  Once the home agent receives
   such de-registration binding update, the home agent clears all the
   binding and states for the mobile node.

   If a mobile node would stop using the interface attached to the home

GT>// If a mobile node would/ If a mobile node decides to /

 link, it simply sends a binding update from the one of active care-of
   address.  In the Binding Update, the mobile node should include the
   BID option for the care-of address and unset the H flag of BID
   option.  The home agent clears the states of the mobile node for the
   interface attached to the home link and stop forwarding the packets
   to the mobile node on the home link.

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 15 Apr 2008 23:21:48 +0800

Sorry for my late reply, I will reply Vijay's comment in the other email,

for Ryuji's reply:
>1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN, Since
RFC 4306 do require check based on the destination address. In that
case, MCOA may be able to use only 1 CoA for this direction packet
delivery. If this is true, MCOA could support multiple interfaces for
MN to HA direction, but could support only 1 HA to MN connection.
Would be better if it could be described more clearly.
Ryuji>Why?? The destination address will be home address, no?
Hui> Here we talked about packet other than BU/BA message, so CoA is involved.
Even for BU/BA, normally, IKE SA need be refreshed every regular time,
so it is also
related to which CoA is going to be used.

>2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA, >From
reading, it seems fine without source address checking. But I am not
sure whethere there is already implementation which could verify it is
workable or not.
The implementation must be updated...
Hui> OK

>3) about which interface MIP6 will use in MCOA scenario, it is mainly
about how to operate SPD, but this document may lack basic description
about it.
Do you want the detail description (example) of SPD?
Hui> Here need further clarification more than description of SPD.

>4) As the basic RFC 3775, RFC 4877 lacks interface between MIP6 and
IKEv2 this document may also need consider it.
right. this is universal issue:-)
Hui> thanks, This is PF-KEY should be gather eyeball asap, other than
leave it empty but move lots of work forward,

Regards,

-Hui

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 15 Apr 2008 23:25:16 +0800

Here is my reply to Vijay's comments,

 >1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN,
Since RFC 4306 do require check based on the destination address. In
that case, MCOA may be able to use only 1 CoA for this direction
packet delivery. If this is true, MCOA could support multiple
interfaces for MN to HA direction, but could support only 1 HA to MN
connection. Would be better if it could be described more clearly.
Ryuji> Why?? The destination address will be home address, no?

Vijay> You have think about the sequence of operations in more detail.
One possible sequence is explained below.

- The HA receives packets for the MN's home address
- The HA determines which binding to use for the particular flow.
 The binding will determine what CoA to use.
- Then the packets hit the SPD. If the filters match, IPsec tunnel
 encryption will be applied. You should be careful not to put the
 CoA in the SPD. SPD lookup will be based on the home address.
Hui> As I replied to Ryuji's email, CoA does exist in the SPD

 >2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA,
>From reading, it seems fine without source address checking. But I am
not sure whethere there is already implementation which could verify
it is workable or not.
The implementation must be updated...
 >3) about which interface MIP6 will use in MCOA scenario, it is
mainly about how to operate SPD, but this document may lack basic
description about it.
Do you want the detail description (example) of SPD?
Vijay>SPD does not have the CoA information. So I ma not sure what we
can explain better.
Hui> Same as above,

Thanks

-Hui

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 16 Apr 2008 17:40:37 +0900

Hello George,

Thanks for comments!

It looks like your comments are more editorial one.
Can I assume you mostly agree on the changes?
I will revise the document quickly and post it again to MEXT.

> documentation (see RFC3849)

I will update the doc. I wasn't aware of this reserved prefix:)

> viewed as a registration, rather than de-registration.

OK. But I have some comments on this.
Please find my comments inline below.

> George

No necessary...
These figures were located at the appendix in the previous version and  
just be reused.
I will update the figure.

> Internet-Draft                    MCoA                        April  

you are right. will fix this, too.

>                                       |   Type = TBD  |      
> Length    |

Good point. The receiver can tell which address is stored in the option.

> packet/message i.e., ?silently discard?. In this case maybe we should

yes, the intention is "ignored". I will correct the expression.

>                                       |   Type = TBD  |      
> Length    |
>       :                        Link Layer  
> address                     :

Do you mean the interface identifier option of PMIP6?
If that interface identifier is always LL address, we will reuse that  
option.
Or we can overwrite the sub-option spec. to carry the LL address  
always for MCoA in this spec.
I will discuss this with Sri.

> add somewhere that "A BU with H flag set MUST have a non-zero

I think MN can use the zero lifetime and de-register the BU.
MN continues setting the H flag for BUs to other interfaces attached  
to foreign link,
because MN attached to both foreign and home link.

MN sends BU from the interface attached to the home link just once.
After that BU, MN sends BU with H flag set from the other interfaces  
while it is at home link.

MN should not send BU from the home link multiple times..
That's why we said dregistration BU here.

What do you think?

> GT> the MN must not respond to NS messages before and *after*

This isn't such clear.
If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after  
the BA.
Otherwise, MN should answer to NS.

> packets, as opposed to snooping. In any case, it is an implementation

This is good point. We should leave the choice to implementations.

I appreciate  your detailed comments!

regards,
ryuji

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 16 Apr 2008 10:00:39 +0100

Hi Ryuji,

Yes, most of my comments are now minor so, good job!.

The only issue that bothers me a little is whether the BU with H flag
set over the home link should be viewed as registration or
de-registration. I think either way works, but I need to think this
through just in case there is some implication that we do not see at
the moment.

See some comments inline.

Regards
George

>  On 2008/04/15, at 21:29, George Tsirtsis wrote:
..
>  Or we can overwrite the sub-option spec. to carry the LL address always for
> MCoA in this spec.

GT2> Yes, I think it would be nice to coordinate with Sri, but  I am
not sure what you mean by "we can overwrite the sub-option spec...."

>  MN continues setting the H flag for BUs to other interfaces attached to
> foreign link,
>  After that BU, MN sends BU with H flag set from the other interfaces while
> it is at home link.
>

GT2> Hmmm, I guess that could work too. Let's think about this a
minute. The way you are thinking about this, can the MN send a BU over
a foreign link with the H flag set, without having send the dereg BU
with H flag set first?

>  If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after the
> BA.

GT2> OK, some clarification maybe useful to indicate that what happens
after the BA depends on how the HA responds i.e., the BA's status
field.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 16 Apr 2008 18:05:56 +0900

Hi George,

> Yes, most of my comments are now minor so, good job!.

Great! thanks.

> through just in case there is some implication that we do not see at

OK, please find my comments inline.

> not sure what you mean by "we can overwrite the sub-option spec...."

I mean the MCoA spec clearly states to carry only LL address in this  
option.

> a foreign link with the H flag set, without having send the dereg BU

MN sends only one dereg-BU with H flag set and zero lifetime to HA  
from the home link.

After that deregistration, MN sends BU with H flag set from the  
foreign link to HA.
This tells HA that MN is still at the home link.
Once MN leaves from the home link, MN unset the H flag in BU so that  
HA can detect the MN's leaving.

> after the BA depends on how the HA responds i.e., the BA's status

Right. I will update this.

regards,
ryuji

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 16 Apr 2008 17:18:59 +0800

Hi George,

Permit me to join in ;p 

=8==8<=8==
> > to foreign link,  because MN attached to both foreign and home link.
> >
> minute. The way you are thinking about this, can the MN send 
> a BU over a foreign link with the H flag set, without having 
> send the dereg BU with H flag set first?
[Ben] My view is that the 'H' flag allows MN to tell HA that its wants to
use both home and foreign attach interface. Hence, sending it on reg-BU over
foreign link or de-reg BU over home link should be ok. From the BU over
foregin link case, as the 'H' flag is in the BID option, HA can look for the
corresponding entry in BCE (that matches the BID) and mark it as a special
entry to let it know that MN is also connected to the home link. Why I say
special entry is because the BID could be reuse by the MN for flow filtering
purposes (I think this was where we last stop the discussion ;p)

Regards,
Benjamin Lim.

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 16 Apr 2008 10:19:56 +0100

Hi Ryuji,

I think what you propose wrt de-registration BU with H-flag set,
works. I have a slight preference in viewing this as a registration
but my preference is based on semantics and I do not think it
technically impacts the solution.

For this reason I say that we go with your proposal, so after fixing
the final set of minor comments I think you should publish the draft.
Time for a proper WGLC ...at least from my side :-)

Regards
George

On Wed, Apr 16, 2008 at 10:05 AM, Ryuji Wakikawa
<[email-masked]> wrote:
> while
>  MN sends only one dereg-BU with H flag set and zero lifetime to HA from the
> home link.
>
>  After that deregistration, MN sends BU with H flag set from the foreign
> link to HA.
>  Once MN leaves from the home link, MN unset the H flag in BU so that HA can
> detect the MN's leaving.
>
>
>
> >
> > >
> the

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 15 Apr 2008 23:07:22 +0000

Hi George,

At Wed, 16 Apr 2008 10:19:56 +0100,
> technically impacts the solution.

great to have agreement:-)

> Time for a proper WGLC ...at least from my side :-)

OK, I will work on your comments and will submit it to IETF unless
there are more comments from the MEXT group.

regards,
ryuji