Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt

From: Christian Kaas-Petersen <[email-masked]>
Date: Wed, 18 Mar 2009 12:25:35 +0000 (GMT)

The H-bit=1 is not used to turn off neighbor discovery at HA.

The H-bit=1 is used by the mobile node to tell the home agent
it has simultaneous connectivity on home link and one or more
foreign links.  Then the home agent decides who should do neighbor
discovery on the home link (depending on whether
the home agent is the only router on the home link, ie topology a
of Figure 3, or there are other routers on the home link, ie topology b
of Figure 3), and the home agent reports its decision in the status
value of the binding acknowledgement.  In topology a the mobile node
will do neighbor discovery; in topology b the home agent will continue
doing neighbor discovery.

Christian

--- Den ons 18/3/09 skrev Benjamin Lim <[email-masked]>:

> Fra: Benjamin Lim <[email-masked]>
> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
> Til: "Christian Kaas-Petersen" <[email-masked]>
> Cc: "George Tsirtsis" <[email-masked]>, "mext" <[email-masked]>
> Dato: onsdag 18. marts 2009 08.17
> Hi Christian, all,
> 
> Pls see inline for some of my comments.
> 
> Christian Kaas-Petersen wrote:
> > The packets I proposed I get from draft 12, section
> 5.4 second paragraph
> > (which details a de-registration with lifetime=0 and
> absence of
> > care-of address) and section 5.6.3 bullets number 1
> and 2 (which detail
> > the presence of the H-bit and the absence of the
> care-of address).
> > 
> > To me, there is no need to register a binding where
> CoA=HoA (use of
> > home link), unless flow binding is used.  
> [Ben] Agree, being simultaneous connected on a home link
> and foreign
> link does not imply that flow binding must be used.
> 
> For example, MN wants to receive packets from devices on
> MN's home link
> through MN's home attached interface.  Rather than
> having those devices
> send the packet to HA who will then forward it to MN's
> foreign attached
> interface, MN uses the 'H' flag to turn off ND-proxy at HA
> and advertise
> MN's home attached interface.  This way, devices in
> the home link will
> send packets to MN's home attached interface.  On the
> other hand, any
> packets not from the home link (e.g. from the global
> Internet) will
> arrive at HA, who in turn forward it to MN's foreign
> attached interface.
> 

      Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 19 Mar 2009 10:00:00 +0800

Hello all,

I am a newcomer in IETF and I am reading the draft 
"draft-ietf-monami6-multiplecoa-12".

I have two questions/comments on the draft.

The first one:

In section 5.3 it says "A mobile node performing bulk registration 
with a correspondent node is out of scope.", while in the section 6.2
it says that CN must reject the bulk registration from MN. 
I think MN shall not perform bulk registration with a CN, if the 
section 6.2 is followed, but not say "out of scope".

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.

6.2.  Processing Binding Update
   o  When multiple Binding Identifier mobility options are present in
      the Binding Update, it is treated as bulk registration.  If the
      receiving node is a correspondent node, it MUST reject the Binding
      Update and returns the status value in the binding Acknowledgement
      set to [MCOA BULK REGISTRATION NOT SUPPORT].

The second one:

As the section 6.4, in my mind, if there is NAT between MN and CN, the 
IP packets received by CN maybe have been modified by the NAT, especially 
the source address. Is it true? 
If the modification is permitted, I think CN shall not check the source 
address and reject the packets whose address have been changed.

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

If I made wrong comprehension please tell me.

By the way, I meet another problem in the E-mail. I have sent the E-mail 
to the mail list [email-masked] twice, but I think nobody received the mail.
I have checked the E-mail Sever in my company and the result showes that 
the E-mail has beed sent out successfully in the log. 
I don't know whether this E-mail will be received by the mail-list and how 
can I solve the problem?

Any response is appreciated.

Thanks and Regards

Xiangsong

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 19 Mar 2009 13:27:30 +0800

Hi Christian,

You are right.  I forgot to consider the case where HA is not the
default router.  The HA would be the one to decide to do ND-proxy or not
based on the topology.

Regards,
Benjamin Lim

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 23 Mar 2009 03:46:01 -0700

Hi Xiangsong, and Christian,

I think Christian already answered you. Thanks!!!

The CN MUST reject the bulk registration, since it's out of scope.
The original DSMIP does not support route optimization.

regards,
ryuji

2009/3/18 Xiangsong Cui <[email-masked]>:
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 23 Mar 2009 04:35:00 -0700

Hi George, Christian, Benjamin, and all,

Let me first reply you the confusion of the binding de-registration operation.

In the MCoA doc, there are several scenarios of binding de-registrations.
I tried to summarize how MCoA document expects to be in each scenario.
Hope this clarify your concerns.

The mobile node is away, and has the three registrations in the home
agent's binding cache
   v6HoA BID1 -> v6CoA1
   v6HoA BID2 -> v6CoA2
   v6HoA BID3 -> v6CoA3

1. Removing a binding from a foreign link
MN removes a binding (BID2) from the foreign link
+ sending de-registration BU from the foreign link
   - lifetime=0
   - BID-option: BID2, No-flag (no care-of address should be given)

2. Returning home completely. (Same as RFC3775)
MN uses the interface attached to the home link only.
+ sending de-registration BU from the home link
   The de-registration BU is same as RFC3775's one.
   - lifetime = 0
   - No BID-options (no care-of address should be given)

3. Use the simultaneous home and foreign link (Normal MCoA behavior)
MN returns home with the interface (BID2) and continues using both interfaces.
+ sending de-registration BU from the home link
   - lifetime = 0
   - BID-option: BID2, H-bit=1 (no care-of address should be given)
   - the Mobility Header Link-layer Address Option

4. Use the simultaneous home and foreign link (Flow binding specific behavior)
Two approaches to create a home binding.

(1) sending BU from the home link
     - lifetime > 0
     - BID-option: BID2, H-bit=1 (no care-of address should be given)
or
(2) sending bulk-BU from the foreign link
     - lifetime > 0
     - BID-option:
       BID1, H-bit=1,  (CoA is given)
       BID2, H-bit=1,  (HoA is given as a CoA)
       BID3, H-bit=1,  (CoA is given)

5. Removing multiple bindings at once (Replacements)
MN removes multiple binding  (BID2,3) registered for the home address
with the new ones (ex. BID1).
+ sending registration BU from foreign link
   - lifetime > 0
   - BID-option:  BID1, O-bit=1,  (CoA is given)
# Note1: O-bit is originally introduced for bootstrapping operation,
# but it can be used for multiple binding de-registrations.
# Note2: Bulk-BU has similar feature, but it only does add-on.
# Bulk-BU cannot be used for replacement or multiple binding removal.

6. Giving up using MCoA
MN wants to use the RFC-3775 binding instead of MCoA binding.
+ sending registration BU from foreign link
   - lifetime > 0
   - No BID-option
#Note1:  if MN sends BU (lifetime > 0, BID-option: BID1, O-flag, CoA),
#HA creates one binding but with the BID assignment.
#Note2: if MN wants to switch from RFC-3775 binding to MCoA binding,
# it MUST de-register RFC-3775 binding first and then start
registering MCOA bindings.

regards,
ryuji