From monami6-bounces@ietf.org Thu Apr 19 06:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeTk4-0002rj-6t; Thu, 19 Apr 2007 06:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeTk2-0002ra-N0 for monami6@ietf.org; Thu, 19 Apr 2007 06:19:54 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeTk0-0003qV-UW for monami6@ietf.org; Thu, 19 Apr 2007 06:19:54 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l3JAJoL7024830 for ; Thu, 19 Apr 2007 19:19:50 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l3JAJoJ03826 for ; Thu, 19 Apr 2007 19:19:50 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id l3JAJnd21709 for ; Thu, 19 Apr 2007 19:19:49 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml27) id l3JAJnqt007448 for monami6@ietf.org; Thu, 19 Apr 2007 19:19:49 +0900 (JST) Received: from [10.68.136.64] by soml27.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l3JAJmxD007420 for ; Thu, 19 Apr 2007 19:19:48 +0900 (JST) Date: Thu, 19 Apr 2007 19:19:58 +0900 From: Keigo Aso To: Monami6 WG Message-Id: <20070419190806.51CB.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Monami6] Fw: [Mip6] NDP operation on virtual home link X-BeenThere: monami6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Monami6 WG List-Id: Monami6 WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: monami6-bounces@ietf.org Hi all, The list has been a little quiet. One topic for reactivate;) Let me forward one email to Monami6 ML. As explained by Ryuji in his presentation at IETF68 in Prague, returning home issue is unresolved yet in MCoA draft. draft-wakikawa-mip6-no-ndp-00.txt's Section 7 (http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt) is providing very practical method for this issue. Actually the method is to introduce Home Binding for utilizing both interfaces attached to home and foreign links without modification for normal HA's operation on proxy Neighbor Discovery Protocol(proxy NDP). As you know, this issue is came from proxy NDP by HA because address duplication is occurred between MN and HA to intercept packets to MN's HoA when MN wants to utilize both interfaces attached to home and foreign. So, if there is a method for solving this issue with keeping normal HA's operation of not performing proxy NDP when MN returns home, that will be very useful for MCoA draft because it seems not to need consideration of influence on definition of RFC3775. draft-wakikawa-mip6-no-ndp-00.txt will deserve it in my opinion. I would like to hear your thoughts. Regards, Keigo Forwarded by Keigo Aso ----------------------- Original Message ----------------------- From: RYUJI WAKIKAWA To: mip6@ietf.org, nemo@ietf.org Date: Sat, 10 Mar 2007 23:07:09 +0900 Subject: [Mip6] NDP operation on virtual home link ---- Hello all, We recently publish draft-wakikawa-mip6-no-ndp-00.txt. http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt Abstract This document summarizes operations of home agent without using the proxy NDP. The Proxy NDP is mainly used to intercept packets by a Home Agent on Mobile IPv6 and NEMO. We intend to submit this document as an informational doc. regards, ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------------- Original Message Ends -------------------- _______________________________________________ Monami6 mailing list Monami6@ietf.org https://www1.ietf.org/mailman/listinfo/monami6 From monami6-bounces@ietf.org Mon Apr 23 02:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsIb-0008Mq-VA; Mon, 23 Apr 2007 02:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsIW-0008KU-Hb; Mon, 23 Apr 2007 02:45:16 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfsIV-0001KO-6S; Mon, 23 Apr 2007 02:45:16 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l3N6iBpT019479; Mon, 23 Apr 2007 01:44:11 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 01:45:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Apr 2007 02:45:13 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542DF3@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast Mobility mailing list Thread-Index: AceFcvIMCPI2dJgsQFK5TTi0G+B0qw== From: "Suresh Krishnan \(QB/EMC\)" To: , , , , , X-OriginalArrivalTime: 23 Apr 2007 06:45:14.0770 (UTC) FILETIME=[F2AF7720:01C78572] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Monami6] Multicast Mobility mailing list X-BeenThere: monami6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Monami6 WG List-Id: Monami6 WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: monami6-bounces@ietf.org Hi Folks, =20 We wanted to inform you that we have created a new mailing list in order to discuss the interactions occuring between mobility and multicast. We invite anyone interested in contributing to the work to subscribe and collaborate. To register visit the list page at: =20 https://www1.ietf.org/mailman/listinfo/multimob =20 Several of you have expressed interest in this work and some documents already exist without a home working group. =20 The primary problem that we foresee being discussed in the mailing list is issues with Multicast listener (receiver) mobility for multicast routing. There are several other associated problems like sender mobility, which can also be discussed. =20 Thanks Suresh and Behcet _______________________________________________ Monami6 mailing list Monami6@ietf.org https://www1.ietf.org/mailman/listinfo/monami6 From monami6-bounces@ietf.org Thu Apr 26 03:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgynj-0002nI-6x; Thu, 26 Apr 2007 03:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgynh-0002mt-7i for monami6@ietf.org; Thu, 26 Apr 2007 03:54:01 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgyng-0004BH-GC for monami6@ietf.org; Thu, 26 Apr 2007 03:54:01 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l3Q7rvpW017077 for ; Thu, 26 Apr 2007 16:53:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l3Q7rvQ19649 for ; Thu, 26 Apr 2007 16:53:57 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id l3Q7rtx17106 for ; Thu, 26 Apr 2007 16:53:55 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.120]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 15:53:07 +0800 Message-ID: <46305AAA.3040309@sg.panasonic.com> Date: Thu, 26 Apr 2007 15:54:18 +0800 From: Benjamin Koh Tien-Ming User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Monami6 WG X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 07:53:07.0707 (UTC) FILETIME=[ED9594B0:01C787D7] X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Monami6] MCoA Issue: Simultaneous Usage of Home and Away interfaces X-BeenThere: monami6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Monami6 WG List-Id: Monami6 WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: monami6-bounces@ietf.org Hi All! As mentioned previously in this list, the current MCoA draft does not fully address the issue of MN being unable to utilise both interfaces attached to home and foreign links. See:- http://www1.ietf.org/mail-archive/web/monami6/current/msg00943.html http://www1.ietf.org/mail-archive/web/monami6/current/msg01049.html As a suggested resolution to this issue, I would like to propose that Section 7 of draft-wakikawa-mip6-no-ndp-00 http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt be adopted as a working solution to the problem and incorporated into the current MCoA document. Proposers of the two previous solutions (Wakikawa-san, Keigo-san and myself) are amenable to this new solution. Would like to hear if there are any strong opinions from the people on this list. I have reproduced the relevant section below. Regards, Ben 7. Multiple Care-of Address Registration In the Multiple Care-of Address Registration [2], the Mobile Node MUST disable either the interface attached to the home link or the interfaces attached to the foreign link. This is because the Home Agent defends the home address of the Mobile Node by proxy neighbor advertisements. So as to avoid the home address duplication at the home link, the Mobile Node MUST select whether it returns home or not. If a binding is active for the Mobile Node, all packets routed to the home link are intercepted by the Home Agent. On the other hand, if the Mobile Node returns home, the Home Agent no longer intercept packets and cannot tunnel the packets to the Mobile Node's interface attached to the foreign link. Figure 9 depicts the scenario where Mobile Node activates the interface attached to the home link and the foreign link, and communicates with all of the interfaces. Since the Home Agent does not use Proxy Neighbor Advertisement to intercept packets, the Mobile Node can utilize both of interfaces attached to the home link and the foreign link simultaneously. The Home Agent can intercept packets by IP routing, but not by proxy Neighbor Discovery. +----+ | CN | +--+-+ | +----+-----+ +----+ | Internet |--------------+ HA | +----+---+-+ +--+-+ |Foreign Link |Home Link --------+------------ ------+------ | | |CoA1 | +--+--+ | | MN +--------------------+ +-----+ Binding Cache Database: Home Agent's binding (No Proxy neighbor advertisement) binding [a:b:c:d::EUI a:b:c:d::EUI BID1] (Home BC) binding [a:b:c:d::EUI Care-of Address1 BID2] Correspondent Node's binding binding [a:b:c:d::EUI a:b:c:d::EUI BID1] (Home BC) binding [a:b:c:d::EUI Care-of Address1 BID2] or None Figure 9: Utilizing of both an interface attached to the Home Link and an interface attached to the Foreign Link When the Mobile Node returns home, it de-registers a binding for the interface. While the bindings for the interfaces attached to the foreign link are still active. Intercepting packets, the Home Agent can decide whether it tunnels to the foreign interface or routes to the home interface of the Mobile Node. To do so, the Home Agent must know that the Mobile Node is back to the home link. However, if the binding is deleted according to [7], there is no way for the Home Agent to know that the Mobile Node is at the home, too. The Home Agent SHOULD invalidate the binding for the interface attached to the home link and MAY NOT delete it. It can alternatively mark that the Mobile Node is at the home link, too. In this document, as an example, the Home Agent inserts the Home Address of the Mobile Node in the Care-of Address field of the Mobile Node. The binding is named "Home Binding" in this doc. The Home Agent MAY manage this home binding as same as the other binding entry in terms of lifetime validation, etc. The Mobile Node MAY send multiple binding de- registration to keep this home binding active. Alternatively, the Home Agent can use infinity lifetime for the lifetime of the home binding. When the Mobile Node leaves the Home Link, it can update the home binding to the normal binding. Before that, the Home Agent believes the Mobile Node is at the home and may route packets for the Mobile Node to the Home Link. For this operation, the Binding Unique Identifier sub-option is modified as described in Figure Figure 10. The new Home flag is introduced. When the H flag is set, the Home Agent MUST treat the binding as the home binding. After intercepting the packets, the Home Agent may tunnel the packets according to the active binding cache(s) or route the packets to the home link according to the home binding cache. Note that the H flag MUST be used only for the binding de-registration. Note that the same mechanism is used for the correspondent node. 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 Unique ID (BID) |Priority/Status|C|R|H|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + + Care-of Address (CoA) + + + +---------------------------------------------------------------+ Wakikawa & Aramoto Expires August 5, 2007 [Page 17] Internet-Draft HA Limited Proxy NDP February 2007 Figure 10: BID Sub-Option Home Binding (H) flag When this flag is set, a home agent stores a Home Address in the Care-of Address field of the binding cache entry. This flag must be used only for binding de-registration. This flag is not used in the bulk registration mode. Reserved 5 bits Reserved field. Reserved field must be set with all 0. -- /<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\ | Benjamin Koh Tien-Ming | | R & D Engineer | | Panasonic Singapore Laboratories Pte Ltd | | Tel: (65)6550 5481 Fax: (65)6550 5459 | | E-mail: benjamin.kohtm@sg.panasonic.com | \>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<< Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HidJA-0000E7-F1; Mon, 30 Apr 2007 17:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HidJ9-0000Dx-Ga for monami6@ietf.org; Mon, 30 Apr 2007 17:21:19 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HidJ8-0004K0-CY for monami6@ietf.org; Mon, 30 Apr 2007 17:21:19 -0400 Received: from [10.0.2.25] (lns-bzn-20-82-64-23-182.adsl.proxad.net [82.64.23.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8EA3D4D94C for ; Tue, 1 May 2007 06:21:15 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v752.3) To: monami6@ietf.org Message-Id: From: Romain KUNTZ Subject: Re: [Monami6] MCoA Issue: Simultaneous Usage of Home and Away interfaces Date: Mon, 30 Apr 2007 23:21:12 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: monami6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Monami6 WG List-Id: Monami6 WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2038164655==" Errors-To: monami6-bounces@ietf.org --===============2038164655== Content-Type: multipart/alternative; boundary=Apple-Mail-6--55106461 --Apple-Mail-6--55106461 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, > As a suggested resolution to this issue, I would like to propose that > Section 7 of draft-wakikawa-mip6-no-ndp-00 > http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt > be adopted as a working solution to the problem and incorporated into > the current MCoA document. Proposers of the two previous solutions > (Wakikawa-san, Keigo-san and myself) are amenable to this new > solution. I like the solution discussed in this draft and would agree to integrate it to the MCoA draft to solve the "simultaneous location in home and foreign" issue. It has the advantage to avoid tunneling in the home network and is IMO pretty easy to implement. Regards, -- Romain KUNTZ kuntz@clarinet.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team --Apple-Mail-6--55106461 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,=A0

As a suggested resolution to this issue, I would = like to propose that
Section 7 of = draft-wakikawa-mip6-no-ndp-00
be adopted as a working solution to the problem and = incorporated into
the current MCoA document. = Proposers of the two previous solutions
I like the solution = discussed in this draft and would agree to integrate it to the MCoA = draft to solve the=A0 "simultaneous location in home and foreign" issue. = It has the advantage to avoid tunneling in the home network and is IMO = pretty easy to implement.

Regards,

= kuntz@clarinet.u-strasbg.fr
Louis Pasteur University -=A0Networks and Protocols = Team


=

= --Apple-Mail-6--55106461-- --===============2038164655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Monami6 mailing list Monami6@ietf.org https://www1.ietf.org/mailman/listinfo/monami6 --===============2038164655==--