Subject: [MEXT] Fwd: draft-wong-mext-simultaneous-ps-00

From: "Dr. Daniel Wong" <[email-masked]>
Date: Fri, 7 Mar 2008 03:41:00 +0800

dear all

thanks to Rute and Kilian for their insightful comments on our draft,
draft-wong-mext-simultaneous-ps-00. We have updated the draft after
receiving the feedback, and have posted the current updated version on
http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00.txt

In particular, we have realized that, as Kilian pointed out in the
email below, our illustrative scenario for the simultaneous mobility
problem for Mobile IPv6 that was included in the first version of the
draft was based on an incorrect assumption about the routing of
binding updates. Indeed, when the correspondent node is mobile, the
binding update would be routed to the home address (and thus, through
the home agent) of the correspondent node. This helps reduce the
occurrence of the simultaneous mobility problem.

However, there are still issues with simultaneous mobility, such as
when home test init and care-of test init messages arrive at the
destination node's home agent slightly before the home agent is
updated with the latest care-of address (more details are in the
current updated version of the draft).

The current draft is still missing another scenario that we plan to
add in section 4.1, plus an update of section 5, and these will be
done within a few days.

In the meantime, we welcome any comments that you may have.

thanks
Daniel

-- 
Dr. Daniel Wong
Assistant Professor
Malaysia University of Science and Technology
** check out my book on wireless IP at
http://www.must.edu.my/~dwong/book.html **

---------- Forwarded message ----------
From: Kilian Weniger <[email-masked]>
Date: Wed, Feb 20, 2008 at 10:57 PM
Subject: RE: [MEXT] draft-wong-mext-simultaneous-ps-00
To: "Dr. Daniel Wong" <[email-masked]>
Cc: [email-masked]

Hi Daniel,

 according to section 6.1 of RFC3775, Mobile IPv6 nodes always send
 mobility header messages (e.g., Binding Update, HoTi, and CoTi messages)
 without applying Binding Cache/Binding Update List check. Based on this
 I suppose BU/HoTi/CoTi messages are sent to the correspondent node's
 *home address* and not to the corresponent node's care-of address. This
 implies that mobility header messages are always routed over
 correspondent node's home agent and that the condition for simultaneous
 mobility problem as described in the draft ("Binding updates are sent
 directly to the most current known address (known by the sender) of the
 intended recipient Mobile Host.") should not be fulfilled. Even though
 one or two Binding Updates may get lost during a simultaneous mobility
 event, the mobile nodes should always be able to recover from this due
 to the routing of retransmitted mobility header messages over the home
 agents.

 The relevant text in section 6.1 of RFC3775 is:
  "Mobility Header messages MUST NOT be sent with a type 2 routing
   header, except as described in Section 9.5.4 for Binding
   Acknowledgement.  Mobility Header messages also MUST NOT be used with
   a Home Address destination option, except as described in Section
   11.7.1 and Section 11.7.2 for Binding Update.  Binding Update List or
   Binding Cache information (when present) for the destination MUST NOT
   be used in sending Mobility Header messages.  That is, Mobility
   Header messages bypass both the Binding Cache check described in
   Section 9.3.2 and the Binding Update List check described in Section
   11.3.1 which are normally performed for all packets.  This applies
   even to messages sent to or from a correspondent node which is itself
   a mobile node. "

 BR,

 Kilian

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]] On
 > Behalf Of Dr. Daniel Wong
 > Sent: Mittwoch, 20. Februar 2008 12:21
 > To: [email-masked]
 > Subject: [MEXT] draft-wong-mext-simultaneous-ps-00
 >
 > dear all,
 >
 > We have submitted an IETF draft on simultaneous mobility, by Wong,
 > Dutta and Schulzrinne. We believe this is a problem faced by Mobile
 > IPv6 as well as some other mobility protocols, and would appreciate
 > comments on it, both in the mailing list and also in IETF 71 in
 > Philadelphia. The URL is
 > http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneo
 > us-ps-00.txt
 >
 > thanks!
 >
 > --
 > Dr. Daniel Wong
 > Assistant Professor
 > Malaysia University of Science and Technology
 > ** check out my book on wireless IP at
 > http://www.must.edu.my/~dwong/book.html **
 > _______________________________________________
 > MEXT mailing list
 > [email-masked]
 > http://www.ietf.org/mailman/listinfo/mext
 >
 >

 Panasonic R&D Center Germany GmbH
 63225 Langen, Hessen, Germany
 Reg: AG Offenbach (Hessen) HRB 33974
 Managing Director: Thomas Micke
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Rute Sofia <[email-masked]>
Date: Fri, 07 Mar 2008 10:18:36 +0000

Daniel,

a couple of comments again,  MIP related.

Section 4.1:
- inside section 4.1 (the title is Simultaneous Mobility in Mobile IPv6) 
you speak about MIPv4. This should be separated.

- concerning MIPv4: stating that simultaneous mobility is not a problem 
is   actually misleading. What I believe you are stating is that it does 
not occur - the way it is described now, it seems that MIPv4 has a 
solution for the problem.

- the mechanism that you state as a "built-in" defense in MIPv6 is 
exactly the same that is used in MIPv4. In other words: *any* node 
(independently of being CN, MN) has a HA associated. So, if a CN moves, 
it just becomes a regular MN, it's just a matter of perspective. If both 
the MN and CNs move simultaneously, then the redirection (in case the 
node is not available) is taken care of by the respective HAs. This 
applies *both* for v4 and for v6. So this should be clearly stated, 
because now it seems there is something different.

- In section 5. you added info about the RR procedure. This should be 
stated up front, in section 4., because in fact it reduces the potential 
problematic scenarios in what concerns simultaneous movement, for MIPv6.

-

-- 
Rute Sofia, PhD ([email-masked], +351 22 2094263)
http://www.inescporto.pt/utm/~ian/
Area Leader/Responsa'vel de A'rea
IAN: Internet Architectures and Networking
UTM: Telecommunications and Networking Unit
INESC Porto
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Dr. Daniel Wong" <[email-masked]>
Date: Sat, 8 Mar 2008 02:47:50 +0800

Rute

thanks for pointing out that we do mention both Mobile IPv4 and Mobile
IPv6 in section 4.1. We will separate into two sections in the next
version.

regarding MIPv4 and MIPv6, a major difference is that since route
optimization is part of MIPv6 (rather than some non-standard
extensions), the timing of messages matters. In standard MIPv4 (with
no route optimization), everything passes through the HA of the
receiving node, so timing is not critical. In MIPv6 (with route
optimization), only control messages like binding updates, HTI, COTI,
pass through the HA of the receiving node, whereas data packets go
directly to the receiving node (bypassing its HA). thus, situations
can occur where a message gets lost  because it gets to the HA just
before the HA is updated, and subsequently, data packets are sent to
an old address. one such situation is illustrated in the draft. we
will try to enhance the clarity.

section 5 is still in the process of being updated.

Daniel