From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 03:00:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03058 for ; Mon, 1 Jul 2002 03:00:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27822; Mon, 1 Jul 2002 01:00:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12057; Mon, 1 Jul 2002 00:00:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g616xEk7017633 for ; Sun, 30 Jun 2002 23:59:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g616xEU0017632 for mobile-ip-dist; Sun, 30 Jun 2002 23:59:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g616xBk7017625 for ; Sun, 30 Jun 2002 23:59:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28925 for ; Sun, 30 Jun 2002 23:59:16 -0700 (PDT) Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01061 for ; Sun, 30 Jun 2002 23:59:16 -0700 (PDT) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by multihop.net (8.12.4/8.11.1) with ESMTP id g616xAk1012288; Sun, 30 Jun 2002 23:59:10 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.4 Date: Sun, 30 Jun 2002 23:58:56 -0700 Subject: Re: [mobile-ip] closing the sol/adv security issue From: "T.J. Kniveton" To: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Message-ID: In-Reply-To: <3D1CC2AB.4080702@kolumbus.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jari Arkko > Also, we have discussed whether protecting ICMPv6 would cause > additional problems. I don't think it will -- if a packet > matches the SPD entry it will be protected to the home agent. If > not it, it will be sent in the clear. Either way, the HA will > get even ICMP errors and other messages. A separate SA should > be used for MH and ICMPv6. > > We have also discussed whether to use MH or ICMPv6 for the messages. > My proposal is that we stick to the current approach, i.e. ICMPv6 to avoid > too much document (and implementation) change. > > So here's a proposal on how to move forward: > > 1. Keep the current messages and functionality. > 2. Require that all sol/adv messages be protected. > 3. Document the fact that the mobile nodes can have > some home address to begin with, and must in any case > have SA(s). > > Ok? I agree with your conclusions. As long as you're confident that it won't be a big burden to secure ICMPv6, then it seems reasonable to me to leave things as-is and require protection (and hence an existing HoA). -TJ From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 05:06:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12565 for ; Mon, 1 Jul 2002 05:06:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01341; Mon, 1 Jul 2002 03:07:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19649; Mon, 1 Jul 2002 02:07:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6195pk7017968 for ; Mon, 1 Jul 2002 02:05:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6195pbh017967 for mobile-ip-dist; Mon, 1 Jul 2002 02:05:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6195mk7017960 for ; Mon, 1 Jul 2002 02:05:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19364 for ; Mon, 1 Jul 2002 02:05:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00716 for ; Mon, 1 Jul 2002 03:05:54 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA16918 for ; Mon, 1 Jul 2002 02:05:53 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6195rX17665 for ; Mon, 1 Jul 2002 02:05:53 -0700 X-mProtect: <200207010905> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNBfa5r; Mon, 01 Jul 2002 02:05:51 PDT Message-ID: <3D201B6F.4E3408CF@iprg.nokia.com> Date: Mon, 01 Jul 2002 02:05:51 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] New draft for Mobile IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, A new revision for Mobile IPv6 has been submitted to the Internet Drafts directorate, and is also available at the URL: http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt Regards. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 05:53:10 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17435 for ; Mon, 1 Jul 2002 05:53:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14662; Mon, 1 Jul 2002 02:53:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27621; Mon, 1 Jul 2002 02:53:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g619pek7018132 for ; Mon, 1 Jul 2002 02:51:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g619peO2018131 for mobile-ip-dist; Mon, 1 Jul 2002 02:51:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g619pak7018124 for ; Mon, 1 Jul 2002 02:51:36 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06810 for ; Mon, 1 Jul 2002 02:51:43 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09094 for ; Mon, 1 Jul 2002 03:51:42 -0600 (MDT) Received: from PTHUBERTW2K2 (dhcp-nic-val-26-104.cisco.com [64.103.26.104]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA06608 for ; Mon, 1 Jul 2002 11:51:41 +0200 (MET DST) From: "Pascal Thubert" To: Subject: [mobile-ip] CoT Date: Mon, 1 Jul 2002 11:47:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I understand that the RR test is meant for the CN to ensure that the remote mobile node is actually who he says, at least as far as the Home Agent knows. So a CN sends a secret via Home, and hopefully the REAL guy gets it. Then the REAL guy could talk to the CN, using that secret to authenticate himself. Now, what about the CareOf Test? Seems that is it mostly used to check that the path to the MN works. To me, it looks like the first beat of a heartbeat more than a HELLO; we're just missing the next beats to detect when the path becomes unusable, in which case the home route should be used. Anyway, what bothers me is that the CareOf address is part of the secret that comes with that test. When the MN moves, a new test is needed before the BU, correct? In general, I do not necessarily see the value of that secret in the CoT for MIP. If the guy at the CoA has the secret from the HoT, then it's him, ain't it? This line of thinking would end up with a flow like: 1) HoT once 2) BU, based on HoT only, when CoA change 3) CoT as a heartbeat What do you think? Pascal From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 06:21:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20088 for ; Mon, 1 Jul 2002 06:21:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09061; Mon, 1 Jul 2002 04:22:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02750; Mon, 1 Jul 2002 03:22:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61AKik7018265 for ; Mon, 1 Jul 2002 03:20:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61AKhf3018264 for mobile-ip-dist; Mon, 1 Jul 2002 03:20:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61AKek7018257 for ; Mon, 1 Jul 2002 03:20:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15534 for ; Mon, 1 Jul 2002 03:20:45 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29900 for ; Mon, 1 Jul 2002 03:20:45 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 98EF76A904; Mon, 1 Jul 2002 13:20:38 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 788286A901; Mon, 1 Jul 2002 13:20:36 +0300 (EEST) Message-ID: <3D202D50.10404@kolumbus.fi> Date: Mon, 01 Jul 2002 13:22:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] CoT References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pascal Thubert wrote: > I understand that the RR test is meant for the CN to ensure that the remote > mobile node is actually who he says, at least as far as the Home Agent knows. So > a CN sends a secret via Home, and hopefully the REAL guy gets it. Then the REAL > guy could talk to the CN, using that secret to authenticate himself. Now, what > about the CareOf Test? Seems that is it mostly used to check that the path to > the MN works. To me, it looks like the first beat of a heartbeat more than a > HELLO; we're just missing the next beats to detect when the path becomes > unusable, in which case the home route should be used. Anyway, what bothers me > is that the CareOf address is part of the secret that comes with that test. When The intention of the care-of address test is to protect against certain types of bombing attacks, as described in section 2.5 of draft-aura-mipv6-bu-attacks-01.txt. > the MN moves, a new test is needed before the BU, correct? Correct. That is as intended. > In general, I do not necessarily see the value of that secret in the CoT for > MIP. If the guy at the CoA has the secret from the HoT, then it's him, ain't it? The care-of address is used as an input in creating the care-of cookie, which in turn is used as an input to the correct value of the authenticator field. If the authenticator field did not depend on the care-of address and the cookie sent to that address, the care-of test would not prove that the MN is live at the care-of address. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 06:37:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21890 for ; Mon, 1 Jul 2002 06:37:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03440; Mon, 1 Jul 2002 03:37:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20776; Mon, 1 Jul 2002 03:37:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61AZvk7018387 for ; Mon, 1 Jul 2002 03:35:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61AZvJ1018386 for mobile-ip-dist; Mon, 1 Jul 2002 03:35:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61AZrk7018379 for ; Mon, 1 Jul 2002 03:35:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05544 for ; Mon, 1 Jul 2002 03:35:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18508 for ; Mon, 1 Jul 2002 04:35:57 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21332; Mon, 1 Jul 2002 06:35:09 -0400 (EDT) Message-Id: <200207011035.GAA21332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-reg-revok-03.txt Date: Mon, 01 Jul 2002 06:35:08 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Registration Revocation in Mobile IP Author(s) : S. Glass, M. Chandra Filename : draft-ietf-mobileip-reg-revok-03.txt Pages : 37 Date : 28-Jun-02 During the original design of Mobile IP, the need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that instead of an active revocation mechanism explicitly for the purpose of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registrations from a mobile node, would likely be sufficient for this purpose. Investigations into requirements for a AAA protocol within the AAA working group have forced reconsideration of a more pro-active Mobile IP registration revocation feature whereby both domains providing Mobile IP services can be made aware that the service is being suspended. In the ideal model, revocations must be possible from either home or foreign domains, so any registration revocation mechanism being defined must provide a signaling mechanism between the two that identify registration(s) being released, implying that since Mobile IP services are no longer being provided on one side of the registration, they need not be provided on the other. In some cases the current registration may be terminated to simply force the mobile node to renegotiate its registration, but in other cases renegotiation may not be allowed. Either one of these reasons is sufficient to justify this mechanism. Moreover, there should also be a mechanism in place whereby the mobile node whose registration has been terminated can also be informed that such a revocation has occurred, if only so it may understand it is not longer being provided Mobile IP services, though the reasons for such a revocation need not necessarily be immediately relayed. This mechanism would ideally be independent of the signaling mechanism between the agents identified above so as to leave actual notification of the mobile node up to a separate policy of the domains in question A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-revok-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-reg-revok-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-reg-revok-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628141934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-revok-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-revok-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141934.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 07:41:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28216 for ; Mon, 1 Jul 2002 07:41:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17777; Mon, 1 Jul 2002 05:42:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10349; Mon, 1 Jul 2002 04:42:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Beuk7018625 for ; Mon, 1 Jul 2002 04:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61BetIE018624 for mobile-ip-dist; Mon, 1 Jul 2002 04:40:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Beqk7018617 for ; Mon, 1 Jul 2002 04:40:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10029 for ; Mon, 1 Jul 2002 04:40:58 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15206 for ; Mon, 1 Jul 2002 05:40:57 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g61BetRc008706; Mon, 1 Jul 2002 13:40:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 13:40:56 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F07C4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] closing the sol/adv security issue Date: Mon, 1 Jul 2002 13:40:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, This is fine with me. Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, June 28, 2002 10:10 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] closing the sol/adv security issue > > > Folks, > > We need to close this issue and move on. > > Over the course of the discussion a number of observations and > comments have been made. There seems to be some amount of > disagreement > about the level of security needed. We have also debated the > order of events, the specific protocol that should carry > the discovery messages, what information the MNs need to have > at startup anyway, and so on. > > How to agree then? Given disagreement about the security level, > perhaps it would be easiest to accept the tougher requirements. > > The question is, does this cause problems for us? > Fortunately, this does appear to be so. As has been discussed, > an SA and a potential home address is available in any case > for the MN, so perhaps these could be used. > > Also, we have discussed whether protecting ICMPv6 would cause > additional problems. I don't think it will -- if a packet > matches the SPD entry it will be protected to the home agent. If > not it, it will be sent in the clear. Either way, the HA will > get even ICMP errors and other messages. A separate SA should > be used for MH and ICMPv6. > > We have also discussed whether to use MH or ICMPv6 for the messages. > My proposal is that we stick to the current approach, i.e. > ICMPv6 to avoid > too much document (and implementation) change. > > So here's a proposal on how to move forward: > > 1. Keep the current messages and functionality. > 2. Require that all sol/adv messages be protected. > 3. Document the fact that the mobile nodes can have > some home address to begin with, and must in any case > have SA(s). > > Ok? > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 10:52:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10018 for ; Mon, 1 Jul 2002 10:52:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16199; Mon, 1 Jul 2002 08:52:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01702; Mon, 1 Jul 2002 07:52:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EpZk7019088 for ; Mon, 1 Jul 2002 07:51:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61EpZcs019087 for mobile-ip-dist; Mon, 1 Jul 2002 07:51:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EpWk7019080 for ; Mon, 1 Jul 2002 07:51:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01425 for ; Mon, 1 Jul 2002 07:51:37 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21512 for ; Mon, 1 Jul 2002 08:51:37 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 10:46:42 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG last call on Mobility Support in IPv6 Date: Mon, 1 Jul 2002 10:46:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is the Mobile IP working group last call on Mobile IP v6: draft-ietf-mobileip-ipv6-18.txt The draft has been submitted but is not yet available in the I-D directory. Until then the draft is obtainable from: http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt. All last call comments should be directed to the mailing list. Last call will conclude on July 15. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 11:11:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11244 for ; Mon, 1 Jul 2002 11:11:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00527; Mon, 1 Jul 2002 09:12:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03621; Mon, 1 Jul 2002 08:11:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61FASk7019275 for ; Mon, 1 Jul 2002 08:10:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61FARMW019274 for mobile-ip-dist; Mon, 1 Jul 2002 08:10:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61FAOk7019267 for ; Mon, 1 Jul 2002 08:10:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03678 for ; Mon, 1 Jul 2002 08:10:30 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05199 for ; Mon, 1 Jul 2002 08:10:30 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g61FASrV008945; Mon, 1 Jul 2002 17:10:29 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 17:10:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F07D0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue 49 (rfc 3041 or new prefixes and manual SAs ) Date: Mon, 1 Jul 2002 17:10:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, > And more issues to close... > > I've had a discussion about this issue with a couple of people. > The general feeling seems to be that making mobility work with > privacy in a seamless and secure way may not be achievable > right now. Or rather, it shouldn't be a requirement for the > first version of the MIPv6 RFC. > > Let me highlight some of the issues involved in this: > > * On manually keyed IPsec SAs we have the problem of binding > the SAs to the IP addresses, leading to a need for manual > intervention when addresses change. => Agreed. > > * Security schemes that are not directly bound to addresses > could also be used. But even these schemes have to deal > with a few non-trivial questions, such as who has the > authority to send a BU for a specific address to the HA? > The very first authenticated MN to come up with that address? > But then we'd have to store all addresses that have ever > been used. Or perhaps we could allow the address to be > used if no one else has a binding for it at the moment, or > DAD succeeds? But what if I hijack everyone else's addresses > after the HA reboots? => Well, I agree, with one clarification: I believe that anyone can send a BU for any home address provided: 1. No binding exists for that address and 2. That address is not stored in a server to be used as a permanent identifier for another MN. (1) is easy to check, but (2) is slightly harder. > > * On certificate-based IPsec, one can use addresses in the > Subject AltName field to force the HA to allow only the > given address for the owner of that certificate. This > would minimize configuration at the HA, but would bind > every MN to their given addresses. > > * For renumbering, it is conceivable that the HA/CA > could make new certificates for the same MN/public key > but with the new address. But isn't clear how these > are pushed to the MNs in the easiest manner. > > * For RFC 3041, the problem is harder because the MN > has the initiative. Perhaps the MN could request > a new SA/cert using its old address/SA/cert. > > Solving all of the above may not be possible in the immediate > future and definately not before Monday 9 AM. > > So, I have the following proposal: > > - We keep on allowing RFC 3041 home addresses and new prefixes. > - We point out that in order to use these, one must have e.g. > manually configured SAs suitable for the new addresses. > - We point out that future specifications will deal with this > problem in a more complete manner. > > Does this work for everyone? => Works for me. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 13:16:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19644 for ; Mon, 1 Jul 2002 13:16:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05911; Mon, 1 Jul 2002 11:16:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06878; Mon, 1 Jul 2002 10:16:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61HFbk7019643 for ; Mon, 1 Jul 2002 10:15:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61HFbO0019642 for mobile-ip-dist; Mon, 1 Jul 2002 10:15:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61HFYk7019635 for ; Mon, 1 Jul 2002 10:15:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06529 for ; Mon, 1 Jul 2002 10:15:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05185 for ; Mon, 1 Jul 2002 11:15:28 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05364 for ; Mon, 1 Jul 2002 10:15:28 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61HFRj00674 for ; Mon, 1 Jul 2002 10:15:27 -0700 X-mProtect: <200207011715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF8ixoa; Mon, 01 Jul 2002 10:15:24 PDT Message-ID: <3D208E2D.C3659ED8@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:15:25 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New Fast Handover Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I have submitted a new version of the fast handover draft to the ID registrar. However, I missed the 6 am (PST) deadline..You may access it from the following URL http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt Comments welcome! Regards, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 14:07:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23086 for ; Mon, 1 Jul 2002 14:07:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19096; Mon, 1 Jul 2002 12:07:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14531; Mon, 1 Jul 2002 11:07:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61I6Pk7019890 for ; Mon, 1 Jul 2002 11:06:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61I6Pka019889 for mobile-ip-dist; Mon, 1 Jul 2002 11:06:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61I6Mk7019882 for ; Mon, 1 Jul 2002 11:06:22 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14229 for ; Mon, 1 Jul 2002 11:06:28 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17131 for ; Mon, 1 Jul 2002 12:06:27 -0600 (MDT) From: Masataka Ohta Message-Id: <200207011755.CAA00676@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA00676; Tue, 2 Jul 2002 02:55:18 +0900 Subject: Re: [mobile-ip] New Fast Handover Draft In-Reply-To: <3D208E2D.C3659ED8@iprg.nokia.com> from Rajeev Koodli at "Jul 1, 2002 10:15:25 am" To: Rajeev Koodli Date: Tue, 2 Jul 2002 02:55:17 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev; > I have submitted a new version of the fast handover > draft to the ID registrar. However, I missed the 6 am (PST) > deadline..You may access it from the following URL > > http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt > > Comments welcome! A statement in abstract comparison to the inevitable link switching latency. is incorrect, because, with two transceivers, it is not inevitable. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 19:38:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09788 for ; Mon, 1 Jul 2002 19:38:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03718; Mon, 1 Jul 2002 17:38:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10404; Mon, 1 Jul 2002 16:38:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61NbMk7020419 for ; Mon, 1 Jul 2002 16:37:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61NbMwf020418 for mobile-ip-dist; Mon, 1 Jul 2002 16:37:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61NbIk7020408 for ; Mon, 1 Jul 2002 16:37:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01739 for ; Mon, 1 Jul 2002 16:37:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22608 for ; Mon, 1 Jul 2002 16:37:25 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA29734; Mon, 1 Jul 2002 16:37:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61NbO506267; Mon, 1 Jul 2002 16:37:24 -0700 X-mProtect: <200207012337> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxc46Yg; Mon, 01 Jul 2002 16:37:22 PDT Message-ID: <3D20E7B3.E500DC0E@iprg.nokia.com> Date: Mon, 01 Jul 2002 16:37:23 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Fast Handover Draft References: <200207011755.CAA00676@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > Rajeev; > > > I have submitted a new version of the fast handover > > draft to the ID registrar. However, I missed the 6 am (PST) > > deadline..You may access it from the following URL > > > > http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt > > > > Comments welcome! > > A statement in abstract > > comparison to the inevitable link switching latency. > > is incorrect, because, with two transceivers, it is not inevitable. > Could you elaborate more ? There could be scenarios when the link switching delay could be reduced to a "very small amount". The intention however is to provide a protocol that works well under such scenarios as well. Regards, -Rajeev > > Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 20:20:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10766 for ; Mon, 1 Jul 2002 20:20:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14456; Mon, 1 Jul 2002 18:20:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17364; Mon, 1 Jul 2002 17:20:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g620JGk7020567 for ; Mon, 1 Jul 2002 17:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g620JG98020566 for mobile-ip-dist; Mon, 1 Jul 2002 17:19:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g620JCk7020559 for ; Mon, 1 Jul 2002 17:19:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11433 for ; Mon, 1 Jul 2002 17:19:20 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18694 for ; Mon, 1 Jul 2002 18:19:19 -0600 (MDT) From: Masataka Ohta Message-Id: <200207020008.JAA01781@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA01781; Tue, 2 Jul 2002 09:08:13 +0900 Subject: Re: [mobile-ip] New Fast Handover Draft In-Reply-To: <3D20E7B3.E500DC0E@iprg.nokia.com> from Rajeev Koodli at "Jul 1, 2002 04:37:23 pm" To: Rajeev Koodli Date: Tue, 2 Jul 2002 09:08:10 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev; > > > I have submitted a new version of the fast handover > > > draft to the ID registrar. However, I missed the 6 am (PST) > > > deadline..You may access it from the following URL > > > > > > http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt > > > > > > Comments welcome! > > > > A statement in abstract > > > > comparison to the inevitable link switching latency. > > > > is incorrect, because, with two transceivers, it is not inevitable. > Could you elaborate more ? There could be scenarios > when the link switching delay could be reduced to a "very small > amount". Sure. > The intention however is to provide a protocol that > works well under such scenarios as well. Then, The intent of this document is to describe protocol enhancements to reduce handover latency due to IP protocol operations as small as possible in comparison to the inevitable link switching latency. should be: The intent of this document is to describe protocol enhancements to reduce handover latency due to IP protocol operations as small as possible when link switching latency is smaller than what is acceptable to support real-time or delay sensitive traffic or is small enough for non real-time, throughput-sensitive applications. Masataka Ohta > > Regards, > > -Rajeev > > > > > > Masataka Ohta > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 21:06:08 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12071 for ; Mon, 1 Jul 2002 21:06:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25612; Mon, 1 Jul 2002 18:06:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02583; Mon, 1 Jul 2002 18:05:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6214vk7020762 for ; Mon, 1 Jul 2002 18:04:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6214vZZ020761 for mobile-ip-dist; Mon, 1 Jul 2002 18:04:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6214rk7020754 for ; Mon, 1 Jul 2002 18:04:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01069 for ; Mon, 1 Jul 2002 18:04:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01971 for ; Mon, 1 Jul 2002 19:04:58 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA04547; Mon, 1 Jul 2002 18:04:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6214se05815; Mon, 1 Jul 2002 18:04:54 -0700 X-mProtect: <200207020104> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlj3t4r; Mon, 01 Jul 2002 18:04:52 PDT Message-ID: <3D20FC34.E3254F55@iprg.nokia.com> Date: Mon, 01 Jul 2002 18:04:52 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Fast Handover Draft References: <200207020008.JAA01781@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > Then, > > The intent of this > document is to describe protocol enhancements to reduce handover > latency due to IP protocol operations as small as possible in > comparison to the inevitable link switching latency. > > should be: > > The intent of this > document is to describe protocol enhancements to reduce handover > latency due to IP protocol operations as small as possible when > link switching latency is smaller than what is acceptable to > support real-time or delay sensitive traffic or is small enough > for non real-time, throughput-sensitive applications. > Ok, so there is link-switching latency.. Your comment above seems to belong to an applicability statement section. In an abstract, wouldn't it suffice to say that the latency due to IP protocol operations should be as small as possible in comparison with the link-switching latency, whatever the latter might be ? Regards, -Rajeev > > Masataka Ohta > > > > > Regards, > > > > -Rajeev > > > > > > > > > > Masataka Ohta > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 21:07:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12127 for ; Mon, 1 Jul 2002 21:07:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04794; Mon, 1 Jul 2002 18:07:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01747; Mon, 1 Jul 2002 18:07:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6216qk7020809 for ; Mon, 1 Jul 2002 18:06:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6216qjr020808 for mobile-ip-dist; Mon, 1 Jul 2002 18:06:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6216mk7020795 for ; Mon, 1 Jul 2002 18:06:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24714 for ; Mon, 1 Jul 2002 18:06:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25980 for ; Mon, 1 Jul 2002 18:06:54 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA04646 for ; Mon, 1 Jul 2002 18:06:53 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6216rh08314 for ; Mon, 1 Jul 2002 18:06:53 -0700 X-mProtect: <200207020106> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLDQ3MH; Mon, 01 Jul 2002 18:06:51 PDT Message-ID: <3D20FCAC.4777A5E4@iprg.nokia.com> Date: Mon, 01 Jul 2002 18:06:52 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Fast Handover Draft References: <200207020008.JAA01781@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Hello folks, I will be away for the rest of the week. I will catch up with the discussion upon returning. Regards, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 21:32:16 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12595 for ; Mon, 1 Jul 2002 21:32:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05372; Mon, 1 Jul 2002 18:32:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07646; Mon, 1 Jul 2002 18:31:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g621SLk7021075 for ; Mon, 1 Jul 2002 18:28:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g621SKxe021074 for mobile-ip-dist; Mon, 1 Jul 2002 18:28:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g621SHk7021067 for ; Mon, 1 Jul 2002 18:28:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06922 for ; Mon, 1 Jul 2002 18:28:23 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02859 for ; Mon, 1 Jul 2002 19:28:23 -0600 (MDT) From: Masataka Ohta Message-Id: <200207020117.KAA02163@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02163; Tue, 2 Jul 2002 10:17:04 +0900 Subject: Re: [mobile-ip] New Fast Handover Draft In-Reply-To: <3D20FC34.E3254F55@iprg.nokia.com> from Rajeev Koodli at "Jul 1, 2002 06:04:52 pm" To: Rajeev Koodli Date: Tue, 2 Jul 2002 10:17:03 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev; > Ok, so there is link-switching latency.. > Your comment above seems to belong to an applicability statement > section. That's fine to put it in the section. > In an abstract, wouldn't it suffice to say that the latency due to > IP protocol operations should be as small as possible in comparison > with the link-switching latency, whatever the latter might be ? The problem of the current abstract is that it is saying comparison to the inevitable link switching latency. even though link switching latency is not inevitable. comparison to the link switching latency. would be OK. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 21:39:45 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12667 for ; Mon, 1 Jul 2002 21:39:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16656; Mon, 1 Jul 2002 18:39:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09110; Mon, 1 Jul 2002 18:39:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g621cck7021193 for ; Mon, 1 Jul 2002 18:38:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g621cb8P021192 for mobile-ip-dist; Mon, 1 Jul 2002 18:38:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g621cYk7021185 for ; Mon, 1 Jul 2002 18:38:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08948 for ; Mon, 1 Jul 2002 18:38:40 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19723 for ; Mon, 1 Jul 2002 19:38:40 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g621cMpj020431; Mon, 1 Jul 2002 18:38:22 -0700 (PDT) Received: from DBLAIR-W2K.cisco.com (atlanta-dhcp-idf81-41.cisco.com [161.44.123.41]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ADG06850; Mon, 1 Jul 2002 18:38:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20020701213547.02021ce0@mira-sjcm-2.cisco.com> X-Sender: dblair@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Jul 2002 21:37:04 -0400 To: Masataka Ohta , Rajeev Koodli From: "Dana L. Blair" Subject: Re: [mobile-ip] New Fast Handover Draft Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <200207020117.KAA02163@necom830.hpcl.titech.ac.jp> References: <3D20FC34.E3254F55@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: One option might be to clarify that the draft is addressing break-before-make handover. If you have two transceivers, then make-before-break handover is possible with simple home agent registration. thanks, Dana At 10:17 AM 7/2/2002 +0859, Masataka Ohta wrote: >Rajeev; > >> Ok, so there is link-switching latency.. >> Your comment above seems to belong to an applicability statement >> section. > >That's fine to put it in the section. > >> In an abstract, wouldn't it suffice to say that the latency due to >> IP protocol operations should be as small as possible in comparison >> with the link-switching latency, whatever the latter might be ? > >The problem of the current abstract is that it is saying > > comparison to the inevitable link switching latency. > >even though link switching latency is not inevitable. > > comparison to the link switching latency. > >would be OK. > > Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 1 22:04:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13459 for ; Mon, 1 Jul 2002 22:04:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16014; Mon, 1 Jul 2002 20:05:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05659; Mon, 1 Jul 2002 19:05:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6223sk7021317 for ; Mon, 1 Jul 2002 19:03:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6223sWx021316 for mobile-ip-dist; Mon, 1 Jul 2002 19:03:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6223pk7021309 for ; Mon, 1 Jul 2002 19:03:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05529 for ; Mon, 1 Jul 2002 19:03:57 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29169 for ; Mon, 1 Jul 2002 20:03:56 -0600 (MDT) From: Masataka Ohta Message-Id: <200207020152.KAA02474@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02474; Tue, 2 Jul 2002 10:51:49 +0859 Subject: Re: [mobile-ip] New Fast Handover Draft In-Reply-To: <4.3.2.7.2.20020701213547.02021ce0@mira-sjcm-2.cisco.com> from "Dana L. Blair" at "Jul 1, 2002 09:37:04 pm" To: "Dana L. Blair" Date: Tue, 2 Jul 2002 10:51:47 +0859 () CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dana; > One option might be to clarify that the draft is addressing break-before-make > handover. If you have two transceivers, then make-before-break handover > is possible with simple home agent registration. That's not enough to clarify that the protocol is not applicable very well if link latency is large. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 00:52:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16681 for ; Tue, 2 Jul 2002 00:52:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27969; Mon, 1 Jul 2002 22:52:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10521; Mon, 1 Jul 2002 21:52:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g624pfk7021667 for ; Mon, 1 Jul 2002 21:51:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g624pfSN021666 for mobile-ip-dist; Mon, 1 Jul 2002 21:51:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g624pck7021659 for ; Mon, 1 Jul 2002 21:51:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10289; Mon, 1 Jul 2002 21:51:44 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11561; Mon, 1 Jul 2002 22:51:43 -0600 (MDT) Message-ID: <007601c22183$e711efe0$256015ac@T23KEMPF> From: "James Kempf" To: , Cc: , "Samita Chakrabarti" References: <3D11F3CB.8050700@kolumbus.fi> <3D1CDC30.5080103@piuha.net> Subject: Re: [mobile-ip] closing issue 48, identifying link changes and prev-coa Date: Mon, 1 Jul 2002 21:49:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, I've got no problem with this (and, in any case, it is too late now). jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "James Kempf" ; ; "Samita Chakrabarti" Sent: Friday, June 28, 2002 2:59 PM Subject: [mobile-ip] closing issue 48, identifying link changes and prev-coa > Yet another issue to close. > > If you remember the discussion, this was about the default router that turned to a non-default > router. This causes the mobile node to go for another default router on the same link, per > rules of the movement detection section. Since the old router is no longer in the default > router list, the MN thinks it has changed link, and may send a BU to the "previous HA". > This will however fail since the old HA will try to do DAD, which the MN itself will respond > to. Even if prefixes between the routers differ, the link local address will be the same, so > the MN will answer a DAD query if the 'L' bit was on. > > We also discussed whether it makes sense to keep the previous coa functionality in the > draft at all, and the application of SEND techniques in this space. We also noted that > we don't enough experience to say exactly how security policies can be configured for the > prev coa forwarding to work, and we are not sure it is practical to configure per MN SAs > on the routers on the places you might be moving in. > > I have a primary proposal on how to go forward. This is based on the observation that > the original situation isn't very typical, so we shouldn't try to optimize it. It is > sufficient to ensure that nothing horrible happens. So, we don't care even if the forwarding > from previous coa would fail in this situation, or if some unnessary tunneling would take > place. As long as the current coa works well and nothing breaks in the old coa, we are happy. > Forwarding from previous coa should of course work in the usual case when you actually move to > another link. > > The proposal is that we allow MNs to request forwarding from previous CoA. > We do not require them to be aware that they might possibly be on the same > link due to one of the routers no longer being a default router. What happens > then is that forwarding-from-previous-coa is requested. We require the 'D' > and 'L' bits to be set in such BUs. This leads the HA to run DAD, which should > fail as the link local address is still in use on the same physical link. > Then, no forwarding will be done. (But this is fine, as the packets will > normally come to the link anyway.) > > Does this work for everyone? (A possible backup proposal: > drop this functionality and deal with it in another spec.) > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 05:42:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29691 for ; Tue, 2 Jul 2002 05:42:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21176; Tue, 2 Jul 2002 03:42:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24066; Tue, 2 Jul 2002 02:42:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g629fPk7022361 for ; Tue, 2 Jul 2002 02:41:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g629fPo5022360 for mobile-ip-dist; Tue, 2 Jul 2002 02:41:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g629fLk7022353 for ; Tue, 2 Jul 2002 02:41:21 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g629fPb09398; Tue, 2 Jul 2002 11:41:25 +0200 (MEST) Date: Tue, 2 Jul 2002 11:40:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Issue 20 (extensibility) can be closed To: James Kempf Cc: Jari Arkko , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <01a101c21e2d$2725b760$4f6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm curious about whether ABK would fit into this scheme. > > Basically, we see ABK as not needing either HoTI or CoTI. The MN exchanges > protocol with the CN instructing the CN to load the id-crypto parameters > from the HA. After the parameters are loaded, the MN can send signed BUs to > the CN without having to use any other security signaling. A brief glance at the Okazaki ABK draft makes me think there are DoS and perhaps reflection opportunities. The ABKP1 causes a P2 to be sent to the HA, and presumably creates some state on the CN in order to do the P2/P3 transaction against the HA. If you want to avoid these threats I think you end up with at least a CoTI/CoT exchange. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 06:32:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01240 for ; Tue, 2 Jul 2002 06:32:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17004; Tue, 2 Jul 2002 04:32:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18741; Tue, 2 Jul 2002 03:32:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AVQk7022592 for ; Tue, 2 Jul 2002 03:31:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62AVQId022591 for mobile-ip-dist; Tue, 2 Jul 2002 03:31:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AVMk7022584 for ; Tue, 2 Jul 2002 03:31:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03307 for ; Tue, 2 Jul 2002 03:31:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25517 for ; Tue, 2 Jul 2002 04:31:26 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00948; Tue, 2 Jul 2002 06:30:37 -0400 (EDT) Message-Id: <200207021030.GAA00948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt Date: Tue, 02 Jul 2002 06:30:37 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Low latency Handoffs in Mobile IPv4 Author(s) : K. Malki et al. Filename : draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt Pages : 53 Date : 01-Jul-02 Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low- latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151906.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 06:34:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01769 for ; Tue, 2 Jul 2002 06:34:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28410; Tue, 2 Jul 2002 03:34:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14132; Tue, 2 Jul 2002 03:34:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AXbk7022655 for ; Tue, 2 Jul 2002 03:33:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62AXbsI022653 for mobile-ip-dist; Tue, 2 Jul 2002 03:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AXXk7022643 for ; Tue, 2 Jul 2002 03:33:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13987 for ; Tue, 2 Jul 2002 03:33:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26440 for ; Tue, 2 Jul 2002 04:33:37 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01392; Tue, 2 Jul 2002 06:32:48 -0400 (EDT) Message-Id: <200207021032.GAA01392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-yokote-mobileip-api-01.txt Date: Tue, 02 Jul 2002 06:32:48 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP API Author(s) : A. Yokote et al. Filename : draft-yokote-mobileip-api-01.txt Pages : 14 Date : 01-Jul-02 The Mobile IP API is an interface between the mobility management module and the application layer. Using Mobile IP API, applications can extract the mobility information that is already maintained by the mobility management module. API provides awareness of mobility for applications. This document describes application scenarios followed by requirements and definition of Mobile IP API. Application scenarios are example applications that can take advantage of awareness of the mobility information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yokote-mobileip-api-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yokote-mobileip-api-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701152304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yokote-mobileip-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-yokote-mobileip-api-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 06:35:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01896 for ; Tue, 2 Jul 2002 06:35:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19088; Tue, 2 Jul 2002 04:35:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03964; Tue, 2 Jul 2002 03:35:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AYak7022700 for ; Tue, 2 Jul 2002 03:34:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62AYZaO022699 for mobile-ip-dist; Tue, 2 Jul 2002 03:34:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62AYVk7022692 for ; Tue, 2 Jul 2002 03:34:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14154 for ; Tue, 2 Jul 2002 03:34:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26847 for ; Tue, 2 Jul 2002 04:34:35 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01566; Tue, 2 Jul 2002 06:33:46 -0400 (EDT) Message-Id: <200207021033.GAA01566@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-elmalki-mobileip-bicasting-v6-02.txt Date: Tue, 02 Jul 2002 06:33:46 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simultaneous Bindings for Mobile IPv6 Fast Handoffs Author(s) : K. Malki, H. Soliman Filename : draft-elmalki-mobileip-bicasting-v6-02.txt Pages : 15 Date : 01-Jul-02 Fast Handover for Mobile IPv6 [1] and Bidirectional Edge Tunnel Handover [2] describe protocols to minimise the amount of service disruption when performing layer-3 handoffs. This draft extends the Fast Handover protocol with a simultaneous bindings function and the BETH capabilities with a bicasting function to minimise packet loss at the MN. Traffic for the MN is therefore bicast or n-cast for a short period to its current location and to one or more locations where the MN is expected to move to shortly. This removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment followng a Fast Handover and allows the decoupling of layer-2 and layer-3 handoffs. It also saves the MN periods of service disruption in the case of ping-pong movement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-elmalki-mobileip-bicasting-v6-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701152515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-mobileip-bicasting-v6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 07:24:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03539 for ; Tue, 2 Jul 2002 07:24:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13373; Tue, 2 Jul 2002 05:25:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21588; Tue, 2 Jul 2002 04:25:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62BO8k7022982 for ; Tue, 2 Jul 2002 04:24:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62BO7XZ022981 for mobile-ip-dist; Tue, 2 Jul 2002 04:24:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62BO3k7022974 for ; Tue, 2 Jul 2002 04:24:04 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g62BO7b17317; Tue, 2 Jul 2002 13:24:07 +0200 (MEST) Date: Tue, 2 Jul 2002 13:22:42 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) To: Michael Thomas Cc: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <15643.37224.131596.350617@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm not sure that understand/buy this > prerequisite. I should be able to have multiple > addresses covered by a single SA/SPI, right? This > is irrespective of binding updates, and is just a > general feature of IPsec. What we clearly want to > prevent is a mobile node hijacking another node's > legitimate use of an IP address on that subnet. > But we clearly want mobile nodes to be able to use > stateless autoconf and/or rfc 3041 addresses, most > likely at the same time, and we want to allow the > MN to use mobility for those addresses if it so > desires. Thus, it seems to me that you have a way > to protect multiple addresses under a single SPI > for which it should be possible to change their > attachment point (ie, send a BU). Mike, There seems to be a fundamental conflict between the two requirements - another MN should not be able to "steal" traffic for somebody elses HoA (on the same HA) - an MN should be able to use RFC 3041 to pick random numbers as temporary home addresses Combining those two, how can the HA determine which MN "owns" which RFC 3041 address? For stateless addrconf, even with site or subnet renumbering, the situation is a little simpler because the HA can at least predict the HoAs based on the prefix and the interface ID that the MN is using. But in essence this is a variant of the threats in draft-kempf-ipng-netaccess-threats-03.txt applied to the home link and with the BU being a layer of indirection between the (mutually untrusting) MNs and the neighbor discovery messages on the home link. I think was is needed for RFC 3041 home addresses to work seemlessly is - a mechanism by which MNs can claim and release RFC 3041 addresses using an manual SA (or certificate) tied to a non-temporary home address. - a mechanism and policy on the HA which prevents one MN from stealing an already used temporary address. A reasonable policy might be first-come-first-served with the HA retaining state about the "reserved" temporary addresses. - a policy on the HA that prevents a misbehaving MNs from taking all 2^63 temporary addresses. For instance, with current RFC 3041 it would be sufficient to allow each MN to use 7 concurrent temporary addresses (per home subnet prefix) The first item could be overloaded on the BU but I think this requires extreme care. For instance, a temporary address might be allocated by an MN for 7 days per RFC 3041, and I don't think this allocation should expire because the home registration for either the temporary address or the non-temporary address expires. So at least conceptually there is a need for "temporary home address reservation" protocol to make this seamless. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 11:18:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18874 for ; Tue, 2 Jul 2002 11:18:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27552; Tue, 2 Jul 2002 09:18:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28017; Tue, 2 Jul 2002 08:18:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62FHRk7023490 for ; Tue, 2 Jul 2002 08:17:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62FHR0d023488 for mobile-ip-dist; Tue, 2 Jul 2002 08:17:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62FHNk7023480 for ; Tue, 2 Jul 2002 08:17:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27822 for ; Tue, 2 Jul 2002 08:17:28 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24212 for ; Tue, 2 Jul 2002 09:17:27 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g62FL3j08128 for ; Tue, 2 Jul 2002 10:21:04 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 2 Jul 2002 10:17:23 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 10:16:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] WG last call on Registration Revocation in Mobile IP (draft-ietf-mobileip-reg-revok-03.txt) Date: Tue, 2 Jul 2002 10:16:41 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1308F@daebe007.NOE.Nokia.com> Thread-Topic: WG last call on Registration Revocation in Mobile IP (draft-ietf-mobileip-reg-revok-03.txt) Thread-Index: AcIh23d5xMSDLXqySvOR8D5xF6FPqg== To: X-OriginalArrivalTime: 02 Jul 2002 15:16:41.0904 (UTC) FILETIME=[78438300:01C221DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g62FHOk7023481 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, This is a WG last call for: Registration Revocation in Mobile IP draft-ietf-mobileip-reg-revok-03.txt This draft is a standards track WG document. Please send in your comments by July 23rd, 2002 to the WG discussion list. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 11:24:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21846 for ; Tue, 2 Jul 2002 11:24:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28709; Tue, 2 Jul 2002 09:25:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07002; Tue, 2 Jul 2002 08:24:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62FO6k7023617 for ; Tue, 2 Jul 2002 08:24:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62FO5xe023616 for mobile-ip-dist; Tue, 2 Jul 2002 08:24:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62FO2k7023609 for ; Tue, 2 Jul 2002 08:24:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23664 for ; Tue, 2 Jul 2002 08:24:08 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28162 for ; Tue, 2 Jul 2002 09:24:07 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g62FO5Rb006009 for ; Tue, 2 Jul 2002 17:24:06 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 17:24:06 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F07E7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] HMIPv6 resubmission - different IPR statement Date: Tue, 2 Jul 2002 17:24:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, HMIPv6 ver 05 has expired and I've resubmitted it yesterday. Until it gets announced you can find it here: http://standards.ericsson.net/Hesham/draft-ietf-mobileip-hmipv6-06.txt This draft is identical to ver 05, we resubmitted it for two reasons, to keep it on the web (we've got some private emails from people interested in the draft but couldn't find it), and because we will have a new IPR statement. The IPR people in my company wanted to reference an existing draft inside the statement (and all future revisions). The new IPR statement will clearly state that licencing is royalty-free for open source implementations. I'll send a link when the statement is on the IETF page. As far as the technical content is concerned (the interesting part!) we were planning on updating the draft according to the latest MIPv6 draft. However, since rev 18 came out very recently, we couldn't be sure about meeting the deadline, but the next update of HMIPv6 will match the latest MIPv6 spec. The following needs to be done: - Update BU message format to match the latest BU format - Make sure there are no conflicts with the new MH - Security considerations (a significant section has to be added here regarding the MN - MAP SA). We should really discuss this one on the list first. I'll try to write up a brief analysis to kick start the discussion. - Changes to Extended mode to be able to work with RR. - Remove the discussion on mobile networks. - Any other comments on the ML Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 11:56:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24183 for ; Tue, 2 Jul 2002 11:56:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16488; Tue, 2 Jul 2002 09:55:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08236; Tue, 2 Jul 2002 08:55:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Fs5k7023803 for ; Tue, 2 Jul 2002 08:54:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62Fs5Qj023802 for mobile-ip-dist; Tue, 2 Jul 2002 08:54:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Fs2k7023795 for ; Tue, 2 Jul 2002 08:54:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07821 for ; Tue, 2 Jul 2002 08:54:08 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15708 for ; Tue, 2 Jul 2002 09:54:07 -0600 (MDT) Message-ID: <005701c221e0$676ca700$4f6015ac@T23KEMPF> From: "James Kempf" To: "Masataka Ohta" , "Rajeev Koodli" , "Dana L. Blair" Cc: References: <3D20FC34.E3254F55@iprg.nokia.com> <4.3.2.7.2.20020701213547.02021ce0@mira-sjcm-2.cisco.com> Subject: Re: [mobile-ip] New Fast Handover Draft Date: Tue, 2 Jul 2002 08:52:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > One option might be to clarify that the draft is addressing break-before-make > handover. If you have two transceivers, then make-before-break handover > is possible with simple home agent registration. > I think the draft may even apply in the make before break case, if some percentage of the handovers are disrupted because the channel to the old router needs to be deallocated permaturely. I think changing the wording on the abstract to remove "inevitable" should do. It might also be appropriate to have a paragraph in the introduction to discuss this. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 14:14:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05468 for ; Tue, 2 Jul 2002 14:14:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00821; Tue, 2 Jul 2002 12:14:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21494; Tue, 2 Jul 2002 11:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62IDLk7024194 for ; Tue, 2 Jul 2002 11:13:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62IDLxG024193 for mobile-ip-dist; Tue, 2 Jul 2002 11:13:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62IDHk7024186 for ; Tue, 2 Jul 2002 11:13:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21477 for ; Tue, 2 Jul 2002 11:13:23 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29649; Tue, 2 Jul 2002 12:13:22 -0600 (MDT) Message-ID: <016c01c221f3$ec140620$4f6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: "Jari Arkko" , References: Subject: Re: [mobile-ip] Issue 20 (extensibility) can be closed Date: Tue, 2 Jul 2002 11:11:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > A brief glance at the Okazaki ABK draft makes me think there are DoS > and perhaps reflection opportunities. The ABKP1 causes a P2 to be sent to > the HA, and presumably creates some state on the CN in order to do the > P2/P3 transaction against the HA. > The ABKP1-ABKp4 message exchange is intended to be stateless on the CN. That is why the CoA is included in messages ABKp2 and ABKp3. > If you want to avoid these threats I think you end up with at least a > CoTI/CoT exchange. > In the next version, we have some ideas about eliminating the dependence on the CoA entirely by running the parameter loading transaction through the home agent. If we can get it worked out properly, this should remove the threat of an attacker using a random CoA. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 2 15:53:34 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12010 for ; Tue, 2 Jul 2002 15:53:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01598; Tue, 2 Jul 2002 12:53:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21329; Tue, 2 Jul 2002 12:53:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Jpgk7024413 for ; Tue, 2 Jul 2002 12:51:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62JpgwC024412 for mobile-ip-dist; Tue, 2 Jul 2002 12:51:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Jpdk7024405 for ; Tue, 2 Jul 2002 12:51:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14601 for ; Tue, 2 Jul 2002 12:51:46 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19085 for ; Tue, 2 Jul 2002 13:51:45 -0600 (MDT) Message-ID: <024201c22201$ab13abe0$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] BAR BOF for alternate BU security algorithms? Date: Tue, 2 Jul 2002 12:40:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Is there any interest in a BAR BOF for talking about alternate BU security algorithms (CGA, ABK, IPsec) in Yoko? The intent would not be to propose anything for the MIPv6 spec but to maybe gauge interest in moving forward with standardizing algorithms that have might have some nicer properties than RR but maybe require more infastructure. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 04:58:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01945 for ; Wed, 3 Jul 2002 04:58:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01489; Wed, 3 Jul 2002 02:59:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02969; Wed, 3 Jul 2002 01:58:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g638vek7025504 for ; Wed, 3 Jul 2002 01:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g638veXx025503 for mobile-ip-dist; Wed, 3 Jul 2002 01:57:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g638vbk7025496 for ; Wed, 3 Jul 2002 01:57:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18158 for ; Wed, 3 Jul 2002 01:57:43 -0700 (PDT) Received: from ep_mailout1 ([203.254.224.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11151 for ; Wed, 3 Jul 2002 02:57:42 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GYO00E010YE2N@mailout1.samsung.com> for mobile-ip@sunroof.eng.sun.com; Wed, 03 Jul 2002 17:59:02 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GYO00E0T0YD1K@mailout1.samsung.com> for mobile-ip@sunroof.eng.sun.com; Wed, 03 Jul 2002 17:59:02 +0900 (KST) Received: from zbin ([75.2.47.220]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GYO0086C0YE5T@mmp2.samsung.com> for mobile-ip@sunroof.eng.sun.com; Wed, 03 Jul 2002 17:59:02 +0900 (KST) Date: Wed, 03 Jul 2002 17:59:54 +0900 From: zb Subject: [mobile-ip] a question on L2 trigger To: mobile-ip@sunroof.eng.sun.com Message-id: <00c301c2226f$ffc351e0$dc2f024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3D208E2D.C3659ED8@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT hi all, I have read several draft on L2 trigger in the group. I have a question on the source node and destination node of the L2 trigger. The definition does not say it explicitly. Do they locate in the same node or in different node? If in different node, how is it implemented? thanks in advanced. bin ************************************* Zhen Bin i-Networking lab, Samsung Advanced Institute of Technology, San14-1, NongSeo-ri, Kiheung-Eup, Yongin, Kyungki-do, 440600, Korea 82-31-2809569 (fax) 82-31-2809534 (o) 82-31-2122268 (h) ************************************* From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 06:32:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04096 for ; Wed, 3 Jul 2002 06:32:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28038; Wed, 3 Jul 2002 04:32:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25640; Wed, 3 Jul 2002 03:32:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AUdk7025829 for ; Wed, 3 Jul 2002 03:30:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63AUdF3025828 for mobile-ip-dist; Wed, 3 Jul 2002 03:30:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AUSk7025800 for ; Wed, 3 Jul 2002 03:30:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08091 for ; Wed, 3 Jul 2002 03:30:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17267 for ; Wed, 3 Jul 2002 04:30:32 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03621; Wed, 3 Jul 2002 06:29:42 -0400 (EDT) Message-Id: <200207031029.GAA03621@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-han-mobileip-rolmmv6-00.txt Date: Wed, 03 Jul 2002 06:29:42 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization Support for Localized Mobility Management Based on IPv6 Author(s) : Y. Han et al. Filename : draft-han-mobileip-rolmmv6-00.txt Pages : 10 Date : 02-Jul-02 Using localized mobility management based on IPv6, all packets destined to a mobile node are routed through the local mobility agent in the mobile node's local mobility domain, which then tunnels the packets to the mobile node's current location. Such packet routing mechanism is similar to the triangle routing in Mobile IPv4, which may leave the local mobility agent overloaded and take a longer route thus increasing the network traffic in the local mobility domain. This document specifies a route optimization scheme for localized mobility management based on IPv6 with the help of L2 trigger. Using this, correspondent nodes can cache LCoA of a mobile node if it is actively communicating with the mobile node, and then send their packets for the mobile node directly to the LCoA, bypassing the local mobility agent. This route optimization scheme will result in more efficient localized mobility management. It alleviates the local mobility agent's loads and takes the nearly same handoff delay time as the one in localized mobility management based on IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-han-mobileip-rolmmv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-han-mobileip-rolmmv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-han-mobileip-rolmmv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-han-mobileip-rolmmv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-han-mobileip-rolmmv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151332.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 06:32:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04112 for ; Wed, 3 Jul 2002 06:32:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18639; Wed, 3 Jul 2002 04:32:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08572; Wed, 3 Jul 2002 03:32:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AUok7025846 for ; Wed, 3 Jul 2002 03:30:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63AUotQ025845 for mobile-ip-dist; Wed, 3 Jul 2002 03:30:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AUhk7025831 for ; Wed, 3 Jul 2002 03:30:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25210 for ; Wed, 3 Jul 2002 03:30:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11238 for ; Wed, 3 Jul 2002 03:30:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03669; Wed, 3 Jul 2002 06:29:58 -0400 (EDT) Message-Id: <200207031029.GAA03669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-manyfolks-l2-mobilereq-02.txt Date: Wed, 03 Jul 2002 06:29:57 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supporting Optimized Handover for IP Mobility -Requirements for Underlying Systems Author(s) : A. Yegin et al. Filename : draft-manyfolks-l2-mobilereq-02.txt Pages : Date : 02-Jul-02 A critical factor in achieving good performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. If the new radio Access Point is associated with a new subnet, a change in routing reachability may occur and require L3 protocol action on the part of the Mobile Node or Access Routers. If no change in subnet occurs, the Access Point may still need to take some action to inform the Access Router about a change in on-link reachability. In either case, prompt and timely information from L2 to the parties involved about the sequencing of handover can help optimize handover at the IP level. This draft discusses requirements for an L2 handover protocol or API to support optimized handover. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-manyfolks-l2-mobilereq-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-manyfolks-l2-mobilereq-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-manyfolks-l2-mobilereq-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-manyfolks-l2-mobilereq-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151435.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 09:55:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13981 for ; Wed, 3 Jul 2002 09:55:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17495; Wed, 3 Jul 2002 06:55:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18016; Wed, 3 Jul 2002 06:55:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63DsCk7026825 for ; Wed, 3 Jul 2002 06:54:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63DsCNe026824 for mobile-ip-dist; Wed, 3 Jul 2002 06:54:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Ds9k7026817 for ; Wed, 3 Jul 2002 06:54:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17846 for ; Wed, 3 Jul 2002 06:54:13 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06537 for ; Wed, 3 Jul 2002 07:54:12 -0600 (MDT) From: Masataka Ohta Message-Id: <200207031334.WAA03479@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA03479; Wed, 3 Jul 2002 22:33:47 +0859 Subject: Re: [mobile-ip] New Fast Handover Draft In-Reply-To: <005701c221e0$676ca700$4f6015ac@T23KEMPF> from James Kempf at "Jul 2, 2002 08:52:01 am" To: James Kempf Date: Wed, 3 Jul 2002 22:33:47 +0859 () CC: Rajeev Koodli , "Dana L. Blair" , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James; > > One option might be to clarify that the draft is addressing break-before-make > > handover. If you have two transceivers, then make-before-break handover > > is possible with simple home agent registration. > > > > I think the draft may even apply in the make before break case, if some percentage of the handovers are disrupted because the > channel to the old router needs to be deallocated permaturely. Just for clarification, are you saying L2make-before-L2break-before-L3handover ? Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 11:37:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18569 for ; Wed, 3 Jul 2002 11:37:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04539; Wed, 3 Jul 2002 09:38:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09923; Wed, 3 Jul 2002 08:37:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Fask7027125 for ; Wed, 3 Jul 2002 08:36:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63FasKX027124 for mobile-ip-dist; Wed, 3 Jul 2002 08:36:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Fapk7027117 for ; Wed, 3 Jul 2002 08:36:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16503 for ; Wed, 3 Jul 2002 08:36:56 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03645 for ; Wed, 3 Jul 2002 09:36:55 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63FasRb004762 for ; Wed, 3 Jul 2002 17:36:54 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 17:36:54 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F080D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 Date: Wed, 3 Jul 2002 17:36:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think there is some ambiguity in chapter 8. It should be clearly stated that this chapter does not place requirements on All IPv6 nodes. The heading of chapter 8.2 says: 'Route Optimization Requirements for All IPv6 Nodes' I think that people can get confused by this. Somewhere in the beginning of chapter 8 it should be made clearer that nodes implementing RO are a subset of all IPv6 nodes on the Internet. Also I think the heading should change to: 'Requirements for IPv6 Nodes that support route optimisation' Also, I still wonder about the point behind the MUST in 8.1 for the HAO. We all agreed that it MUST be supported Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 14:07:42 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24781 for ; Wed, 3 Jul 2002 14:07:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16166; Wed, 3 Jul 2002 12:08:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19262; Wed, 3 Jul 2002 11:07:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63I6tk7027783 for ; Wed, 3 Jul 2002 11:06:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63I6t7Q027782 for mobile-ip-dist; Wed, 3 Jul 2002 11:06:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63I6pk7027775 for ; Wed, 3 Jul 2002 11:06:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18962 for ; Wed, 3 Jul 2002 11:06:57 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19045; Wed, 3 Jul 2002 11:06:56 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g63I6nvb006394; Wed, 3 Jul 2002 11:06:49 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABZ56677; Wed, 3 Jul 2002 11:04:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA20242; Wed, 3 Jul 2002 11:06:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.15673.36030.964903@thomasm-u1.cisco.com> Date: Wed, 3 Jul 2002 11:06:49 -0700 (PDT) To: Erik Nordmark Cc: Michael Thomas , Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) In-Reply-To: References: <15643.37224.131596.350617@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm somewhat behind here, but Erik's note seems to capture most of the questions raised... Erik Nordmark writes: > There seems to be a fundamental conflict between the two requirements > - another MN should not be able to "steal" traffic for somebody elses > HoA (on the same HA) > - an MN should be able to use RFC 3041 to pick random numbers as temporary > home addresses > Combining those two, how can the HA determine which MN "owns" which RFC 3041 > address? How is it that one does that without any crypto to complicate the picture? This seems to me to be the essence of DAD: you can use an address so long as nobody else is currently using it. Is this adequate? Well, you tell me. There's an obvious hijacking attack inherent with DAD, but by ignoring it you sidestep the sticky questions about "ownership". Crypto here doesn't really change that question: just because you could conceivably use strong auth to close that hole doesn't mean you are *obligated* to close that hole. Indeed, there's significant downside to conflating addresses with identity, so it may well be better to let sleeping dogs lay. > I think was is needed for RFC 3041 home addresses to work seemlessly is > - a mechanism by which MNs can claim and release RFC 3041 addresses > using an manual SA (or certificate) tied to a non-temporary home address. > - a mechanism and policy on the HA which prevents one MN from stealing an > already used temporary address. A reasonable policy might be > first-come-first-served with the HA retaining state about the "reserved" > temporary addresses. > - a policy on the HA that prevents a misbehaving MNs from taking all 2^63 > temporary addresses. For instance, with current RFC 3041 it would be > sufficient to allow each MN to use 7 concurrent temporary addresses (per > home subnet prefix) I think what needs to be asked first is whether a strict binding of identity to ip address (cf "ownership") is even a good idea. I don't think that is at all clear. In fact it may well be harmful. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 14:15:47 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25475 for ; Wed, 3 Jul 2002 14:15:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23098; Wed, 3 Jul 2002 11:14:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21321; Wed, 3 Jul 2002 11:14:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63IDjk7027896 for ; Wed, 3 Jul 2002 11:13:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63IDjT9027895 for mobile-ip-dist; Wed, 3 Jul 2002 11:13:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63IDfk7027888 for ; Wed, 3 Jul 2002 11:13:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05403 for ; Wed, 3 Jul 2002 11:13:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19287 for ; Wed, 3 Jul 2002 12:13:44 -0600 (MDT) Message-ID: <006601c222bc$4aa74f30$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "zb" , References: <3D208E2D.C3659ED8@iprg.nokia.com> <00c301c2226f$ffc351e0$dc2f024b@zbin> Subject: Re: [mobile-ip] a question on L2 trigger Date: Wed, 3 Jul 2002 11:05:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, > I have read several draft on L2 trigger in the group. I have a question on > the source node and destination node of the L2 trigger. The definition does > not say it explicitly. Do they locate in the same node or in different node? > If in different node, how is it implemented? L2 triggers are generated by the link-layer on a node. And they are consumed by the network-layer of a node. These two can be the same node, for example, in the case of a WLAN client receiving a link-up. Therefore an internal communication mechanism between the link-layer and IP would be sufficient. On the other hand, in the case of WLAN access point receiving a link-up, the consumer of this trigger is located on a separate node, like a router behind the AP. In this case there needs to be a protocol to carry the L2 trigger from the AP to the AR. Please see following draft which attempts to define such a protocol: http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt alper > > thanks in advanced. > > bin > ************************************* > Zhen Bin > > i-Networking lab, > Samsung Advanced Institute of Technology, > San14-1, NongSeo-ri, Kiheung-Eup, > Yongin, Kyungki-do, 440600, Korea > > 82-31-2809569 (fax) > 82-31-2809534 (o) > 82-31-2122268 (h) > ************************************* > > **********************Confidentiality Note********************** Privileged/Confidential Information may be contained in this e-mail and any attachment to it and may be covered by existing non-disclosure or confidentiality agreements. If you are not the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone any information contained in this e-mail. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete it from your system. Thank you very much. ************************************************************* From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 14:29:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26590 for ; Wed, 3 Jul 2002 14:29:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00492; Wed, 3 Jul 2002 11:29:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25044; Wed, 3 Jul 2002 11:29:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ISgk7028038 for ; Wed, 3 Jul 2002 11:28:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63ISgYc028037 for mobile-ip-dist; Wed, 3 Jul 2002 11:28:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ISdk7028030 for ; Wed, 3 Jul 2002 11:28:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24902 for ; Wed, 3 Jul 2002 11:28:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27188 for ; Wed, 3 Jul 2002 12:28:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12310; Wed, 3 Jul 2002 11:28:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g63IShL28581; Wed, 3 Jul 2002 11:28:43 -0700 X-mProtect: <200207031828> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.79.92, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrWDrFN; Wed, 03 Jul 2002 11:28:11 PDT Message-ID: <3D23420F.4080402@iprg.nokia.com> Date: Wed, 03 Jul 2002 11:27:27 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F080F@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (EAB) wrote: > Sorry, unfinished sentence at the end. I > just discovered that I sent it by accident. > > The last paragraph should read: > Also, I still wonder about the point behind > the MUST in 8.1 for the HAO. We all agreed that > it MUST be supported when a BCE entry, what is actually no. we agreed that HAO MUST be processed if the home address can be verified. verifiability of the home address can be achieved by mechanisms other than the a valid BCE entry. for example, lets asumme the MN and CN have an IPsec protected data session with the SA created on MN's home address. in this case the verifiability comes from the IPsec SA. another case is, when the CN and MN belong to the same 'trusted' domain. in this case the HAO can be processed. there are other mechanisms like Rajeev's and Charlie's HAO tagging proposal to verify the HoA. IMO, HoA verifiability is something I believe we can solve. it would be wrong to restrict ourselves now by saying HAO MUST NOT be processed if a vaild BCE does not exist. > the point of having it supported just in case > IPsec exists? > Is it to use triangular routing? There is nothing yes. you can have triangular routing if the home address can be verified. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 14:36:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27377 for ; Wed, 3 Jul 2002 14:36:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01407; Wed, 3 Jul 2002 12:37:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12572; Wed, 3 Jul 2002 11:36:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Ia7k7028171 for ; Wed, 3 Jul 2002 11:36:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63Ia7eE028170 for mobile-ip-dist; Wed, 3 Jul 2002 11:36:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Ia4k7028163 for ; Wed, 3 Jul 2002 11:36:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27050 for ; Wed, 3 Jul 2002 11:36:09 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03385 for ; Wed, 3 Jul 2002 11:36:09 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g63Ia1K29378; Wed, 3 Jul 2002 13:36:01 -0500 (CDT) Message-ID: <3D23442F.9090109@alcatel.com> Date: Wed, 03 Jul 2002 13:36:31 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: zb CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question on L2 trigger References: <3D208E2D.C3659ED8@iprg.nokia.com> <00c301c2226f$ffc351e0$dc2f024b@zbin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I suggested to ZB to take this discussion to pilc (pilc@ietf.org) mailing list where L2 Triggers related discussions have already been taking place. You can get to know what is going on by consulting the mailing list of pilc. Regards, zb wrote: >hi all, > >I have read several draft on L2 trigger in the group. I have a question on >the source node and destination node of the L2 trigger. The definition does >not say it explicitly. Do they locate in the same node or in different node? >If in different node, how is it implemented? > >thanks in advanced. > >bin >************************************* >Zhen Bin > >i-Networking lab, >Samsung Advanced Institute of Technology, >San14-1, NongSeo-ri, Kiheung-Eup, >Yongin, Kyungki-do, 440600, Korea > >82-31-2809569 (fax) >82-31-2809534 (o) >82-31-2122268 (h) >************************************* > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 14:44:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28366 for ; Wed, 3 Jul 2002 14:44:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16350; Wed, 3 Jul 2002 11:17:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17278; Wed, 3 Jul 2002 10:16:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63HFgk7027425 for ; Wed, 3 Jul 2002 10:15:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63HFgJk027424 for mobile-ip-dist; Wed, 3 Jul 2002 10:15:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63HFdk7027417 for ; Wed, 3 Jul 2002 10:15:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04866 for ; Wed, 3 Jul 2002 10:15:29 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17779 for ; Wed, 3 Jul 2002 11:15:28 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63HFRrU001297 for ; Wed, 3 Jul 2002 19:15:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 19:15:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F080F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 Date: Wed, 3 Jul 2002 19:15:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sorry, unfinished sentence at the end. I just discovered that I sent it by accident. The last paragraph should read: Also, I still wonder about the point behind the MUST in 8.1 for the HAO. We all agreed that it MUST be supported when a BCE entry, what is the point of having it supported just in case IPsec exists? Is it to use triangular routing? There is nothing in the draft about that. i don't see the benefit, but I see confusion for someone reading the spec and trying to understand what's going on. Hesham PS: The rest of the comments (before this paragrph) still apply. > I think there is some ambiguity in chapter > 8. It should be clearly stated that this chapter > does not place requirements on All IPv6 nodes. > The heading of chapter 8.2 says: > > 'Route Optimization Requirements for All IPv6 Nodes' > > I think that people can get confused by this. > Somewhere in the beginning of chapter 8 it should > be made clearer that nodes implementing RO are > a subset of all IPv6 nodes on the Internet. > Also I think the heading should change to: > > 'Requirements for IPv6 Nodes that support route optimisation' > > > Also, I still wonder about the point behind > the MUST in 8.1 for the HAO. We all agreed that > it MUST be supported > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 3 15:47:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03010 for ; Wed, 3 Jul 2002 15:47:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06591; Wed, 3 Jul 2002 11:41:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24649; Wed, 3 Jul 2002 10:41:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63He5k7027600 for ; Wed, 3 Jul 2002 10:40:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63He407027599 for mobile-ip-dist; Wed, 3 Jul 2002 10:40:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63He1k7027592 for ; Wed, 3 Jul 2002 10:40:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11070 for ; Wed, 3 Jul 2002 10:40:06 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06069 for ; Wed, 3 Jul 2002 11:40:05 -0600 (MDT) Message-ID: <006501c222b8$68194a90$4f6015ac@T23KEMPF> From: "James Kempf" To: "zb" , References: <3D208E2D.C3659ED8@iprg.nokia.com> <00c301c2226f$ffc351e0$dc2f024b@zbin> Subject: Re: [mobile-ip] a question on L2 trigger Date: Wed, 3 Jul 2002 10:38:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The idea behind an L2 trigger is that the trigger is delivered to the IP stack on a particular node. The trigger can be implemented as an API, protocol, or in some other way. The question of what the source node is is therefore a question of the implementation. If the trigger occurs within a single node, like a router, then there is no source in the protocol sense, though there may be in the API sense (like it comes from the wireless link driver). If the trigger is an extension of the Layer 2 protocol, then there will be a source and destination node. jak ----- Original Message ----- From: "zb" To: Sent: Wednesday, July 03, 2002 1:59 AM Subject: [mobile-ip] a question on L2 trigger > hi all, > > I have read several draft on L2 trigger in the group. I have a question on > the source node and destination node of the L2 trigger. The definition does > not say it explicitly. Do they locate in the same node or in different node? > If in different node, how is it implemented? > > thanks in advanced. > > bin > ************************************* > Zhen Bin > > i-Networking lab, > Samsung Advanced Institute of Technology, > San14-1, NongSeo-ri, Kiheung-Eup, > Yongin, Kyungki-do, 440600, Korea > > 82-31-2809569 (fax) > 82-31-2809534 (o) > 82-31-2122268 (h) > ************************************* > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 4 02:52:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09646 for ; Thu, 4 Jul 2002 02:52:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11204; Thu, 4 Jul 2002 00:53:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10651; Wed, 3 Jul 2002 23:52:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g646psk7029431 for ; Wed, 3 Jul 2002 23:51:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g646prMf029430 for mobile-ip-dist; Wed, 3 Jul 2002 23:51:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g646pok7029423 for ; Wed, 3 Jul 2002 23:51:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13081 for ; Wed, 3 Jul 2002 23:51:55 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26021 for ; Thu, 4 Jul 2002 00:51:54 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id EED416A905; Thu, 4 Jul 2002 09:51:47 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5B8D66A904; Thu, 4 Jul 2002 09:51:14 +0300 (EEST) Message-ID: <3D23F0B8.5030802@kolumbus.fi> Date: Thu, 04 Jul 2002 09:52:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F080D@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (EAB) wrote: > I think there is some ambiguity in chapter > 8. It should be clearly stated that this chapter > does not place requirements on All IPv6 nodes. > The heading of chapter 8.2 says: > > 'Route Optimization Requirements for All IPv6 Nodes' > > I think that people can get confused by this. > Somewhere in the beginning of chapter 8 it should > be made clearer that nodes implementing RO are > a subset of all IPv6 nodes on the Internet. > Also I think the heading should change to: > > 'Requirements for IPv6 Nodes that support route optimisation' Yes. Thanks for noting this. The intention was indeed to specify the MUSTs for nodes that support RO, and then leave the decision of which nodes support RO to the node requirements document that is being worked on in the IPv6 WG. => new issue #52 > Also, I still wonder about the point behind > the MUST in 8.1 for the HAO. We all agreed that > it MUST be supported There's two things here. One is whether the current spec adequately explains how all this works even if RO is not used. Does it? Secondly, how useful is the functionality? => new issue #53 (hmm... it has been discussed before...) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 4 03:06:45 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09992 for ; Thu, 4 Jul 2002 03:06:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15743; Thu, 4 Jul 2002 00:06:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23928; Thu, 4 Jul 2002 00:06:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6475Yk7029561 for ; Thu, 4 Jul 2002 00:05:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6475XXG029560 for mobile-ip-dist; Thu, 4 Jul 2002 00:05:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6475Uk7029553 for ; Thu, 4 Jul 2002 00:05:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23830 for ; Thu, 4 Jul 2002 00:05:35 -0700 (PDT) Received: from ep_mailout1 ([203.254.224.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11155 for ; Thu, 4 Jul 2002 01:05:35 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GYP00I01QFJDR@mailout1.samsung.com> for mobile-ip@sunroof.eng.sun.com; Thu, 04 Jul 2002 16:06:55 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GYP00I0YQFJCX@mailout1.samsung.com> for mobile-ip@sunroof.eng.sun.com; Thu, 04 Jul 2002 16:06:55 +0900 (KST) Received: from zbin ([75.2.47.220]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GYP002DFQFMTP@mmp2.samsung.com> for mobile-ip@sunroof.eng.sun.com; Thu, 04 Jul 2002 16:06:58 +0900 (KST) Date: Thu, 04 Jul 2002 16:07:56 +0900 From: zb Subject: Re: [mobile-ip] a question on L2 trigger To: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Message-id: <01fa01c22329$86307870$dc2f024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3D208E2D.C3659ED8@iprg.nokia.com> <00c301c2226f$ffc351e0$dc2f024b@zbin> <006601c222bc$4aa74f30$8b6015ac@AlperVAIO> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT From your answer, the source node and destination node of "L2 Trigger" can be either in a same device or in seperated device. The "L2 Trigger" only define its mechanism and ability. How to implement it is another issue. thanks, bin ----- Original Message ----- From: "Alper E. YEGIN" To: "zb" ; Sent: Thursday, July 04, 2002 3:05 AM Subject: Re: [mobile-ip] a question on L2 trigger > Hello, > > > I have read several draft on L2 trigger in the group. I have a question on > > the source node and destination node of the L2 trigger. The definition > does > > not say it explicitly. Do they locate in the same node or in different > node? > > If in different node, how is it implemented? > > L2 triggers are generated by the link-layer on a node. > And they are consumed by the network-layer of a node. > These two can be the same node, for example, in the > case of a WLAN client receiving a link-up. Therefore > an internal communication mechanism between the > link-layer and IP would be sufficient. > > On the other hand, in the case of WLAN access point > receiving a link-up, the consumer of this trigger is located > on a separate node, like a router behind the AP. In this > case there needs to be a protocol to carry the L2 trigger > from the AP to the AR. Please see following draft which > attempts to define such a protocol: > > http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt > > alper > > > > > > thanks in advanced. > > > > bin > > ************************************* > > Zhen Bin > > > > i-Networking lab, > > Samsung Advanced Institute of Technology, > > San14-1, NongSeo-ri, Kiheung-Eup, > > Yongin, Kyungki-do, 440600, Korea > > > > 82-31-2809569 (fax) > > 82-31-2809534 (o) > > 82-31-2122268 (h) > > ************************************* > > > > > **********************Confidentiality Note********************** > Privileged/Confidential Information may be contained in this e-mail and any > attachment to it and may be covered by existing non-disclosure or > confidentiality agreements. > If you are not the addressee (or authorized to receive for the addressee), > you may not use, copy or disclose to anyone any information contained in > this e-mail. If you have received this e-mail in error, please notify the > sender immediately by reply e-mail and delete it from your system. > Thank you very much. > ************************************************************* > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 4 10:27:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17988 for ; Thu, 4 Jul 2002 10:27:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19293; Thu, 4 Jul 2002 08:28:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20105; Thu, 4 Jul 2002 07:27:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64EQ2k7000538 for ; Thu, 4 Jul 2002 07:26:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g64EQ17N000537 for mobile-ip-dist; Thu, 4 Jul 2002 07:26:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64EPvk7000530 for ; Thu, 4 Jul 2002 07:25:58 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g64EPwb05346; Thu, 4 Jul 2002 16:25:58 +0200 (MEST) Date: Thu, 4 Jul 2002 16:24:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) To: Michael Thomas Cc: Erik Nordmark , Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <15651.15673.36030.964903@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > How is it that one does that without any crypto to > complicate the picture? This seems to me to be the > essence of DAD: you can use an address so long as > nobody else is currently using it. Is this > adequate? Well, you tell me. There's an obvious > hijacking attack inherent with DAD, but by > ignoring it you sidestep the sticky questions > about "ownership". Crypto here doesn't really > change that question: just because you could > conceivably use strong auth to close that hole > doesn't mean you are *obligated* to close that > hole. Indeed, there's significant downside to > conflating addresses with identity, so it may well > be better to let sleeping dogs lay. See below. > I think what needs to be asked first is whether a > strict binding of identity to ip address (cf > "ownership") is even a good idea. I don't think > that is at all clear. In fact it may well be > harmful. Perhaps the term "ownership" carries very wrong connotations in this context. The issue isn't identity, but the stability of the address. [As an aside, I didn't think "owership" in the real aka non-IETF world implied a tie to an identity. I own the 20 Euro bill in my wallet but there is no relationship between it and my identity.] Being able to use temporary addresses seems like a very useful thing in general. Folks are concerns about the threats for public multi-access links (ND and addrconf threats). To make temporary addresses useful in the SeND case, there has to be a notion of being able to "allocate" such an address and be able to use it for its intended lifetime (7 days by default). In the non-mobile case the unstated assumption is that the node needs to be present on the link to be able to "defend" an address by responding to DAD probes. Perhaps this assumption needs to be questioned in general. In any case, in the mobile case the assumption is bad if it ends up assuming that the MN is always reachable from the HA. But this "stable temporary addresses" doesn't mean that the addresses should be tied to a particular identity of the owner; merely that attackers should not be able to (easily) steal them from the owner. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 4 12:11:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20455 for ; Thu, 4 Jul 2002 12:11:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18626; Thu, 4 Jul 2002 10:12:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11898; Thu, 4 Jul 2002 09:11:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64GAfk7000764 for ; Thu, 4 Jul 2002 09:10:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g64GAeHL000763 for mobile-ip-dist; Thu, 4 Jul 2002 09:10:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64GAbk7000756 for ; Thu, 4 Jul 2002 09:10:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16059 for ; Thu, 4 Jul 2002 09:10:44 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20625 for ; Thu, 4 Jul 2002 09:10:43 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g64GAdRc028208; Thu, 4 Jul 2002 18:10:39 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 18:10:39 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Vijay Devarapalli'" , "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 Date: Thu, 4 Jul 2002 18:10:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, My comment was two fold: 1. Is it worth it? You say, yes it is because we get triangulr routing. I'm not so sure that triangular routing is much better, but anyway this is not my biggest concern. That one is below 2. The draft is very unclear about the rationale. I know it says that the HAO can be accepted if IPsec is used, but I think more text is needed there. (2) is more important to me than (1), because I was a bit confused by section 8, and I would imagine that someone reading this for the first time will be more confused. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Wednesday, July 03, 2002 8:27 PM > To: Hesham Soliman (EAB) > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 > > > > > Hesham Soliman (EAB) wrote: > > > Sorry, unfinished sentence at the end. I > > just discovered that I sent it by accident. > > > > The last paragraph should read: > > Also, I still wonder about the point behind > > the MUST in 8.1 for the HAO. We all agreed that > > it MUST be supported when a BCE entry, what is > > > actually no. we agreed that HAO MUST be processed if the home > address can be verified. verifiability of the home address can be > achieved by mechanisms other than the a valid BCE entry. > for example, > lets asumme the MN and CN have an IPsec protected data session with > the SA created on MN's home address. in this case the verifiability > comes from the IPsec SA. another case is, when the CN and MN belong > to the same 'trusted' domain. in this case the HAO can be > processed. > there are other mechanisms like Rajeev's and Charlie's HAO tagging > proposal to verify the HoA. > > IMO, HoA verifiability is something I believe we can solve. it > would be wrong to restrict ourselves now by saying HAO MUST NOT be > processed if a vaild BCE does not exist. > > > the point of having it supported just in case > > IPsec exists? > > Is it to use triangular routing? There is nothing > > > yes. you can have triangular routing if the home address can be > verified. > > regards > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 4 23:01:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01748 for ; Thu, 4 Jul 2002 23:01:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15041; Thu, 4 Jul 2002 21:01:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06326; Thu, 4 Jul 2002 20:01:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65306k7001561 for ; Thu, 4 Jul 2002 20:00:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65306Ql001560 for mobile-ip-dist; Thu, 4 Jul 2002 20:00:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65303k7001553 for ; Thu, 4 Jul 2002 20:00:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06246 for ; Thu, 4 Jul 2002 20:00:10 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01135 for ; Thu, 4 Jul 2002 21:00:09 -0600 (MDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id MAA01671; Fri, 5 Jul 2002 12:00:05 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g65304xV013447; Fri, 5 Jul 2002 12:00:05 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g65303n5000129; Fri, 5 Jul 2002 12:00:03 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA10835; Fri, 5 Jul 2002 12:00:02 +0900 (JST) Received: from OHNISHIIBM by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id MAA04874; Fri, 5 Jul 2002 12:00:02 +0900 (JST) Message-ID: <009d01c223d0$116ef7d0$900d3c81@OHNISHIIBM> From: "Hiroyuki OHNISHI" To: "Liu, Changwen" Cc: References: Subject: Re: [mobile-ip] I-D ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt Date: Fri, 5 Jul 2002 12:00:06 +0900 Organization: NTT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi changwen, Thank you for your comments. I understand what you are saying. But this architecture is aiming to be applied to a VPN model. I show you our requiements first and reply to your comments. Our requirements are followings; Requirement 1: MN outside the Intranet can set up IPsec tunnel between the MN and the Intranet(VPN GW). And the IPsec tunnel does not need to be renegotiated even if the MN changes its CoA. Requirement 2: To achieve Requirement 1, the VPN GW has to handle binding caches for the MN. And it is better that MN can create binding caches in VPN GW by using a simple way. As you mentioned, this draft proposed that MN sends Binding Update to GHA instead of HA and GHA again sends Binding Update to the HA. This is because we want to create binding caches in GHA during registering MN's CoA to HA (requirement 2). I think it can be possible that MN sends BU(for HA) over BU(for GHA) mesasge. But from the viewpoint of MN, I think it is too complex. GHA has to forward all the traffic from/to MNs. But it is common senario that the traffic has to pass through the VPN GW in the VPN senario. I think even if MN moves to outside the Intranet, the MN should be under same envinronment. It means that the packets to the MN can pass through a FW that is located in the Intranet. If the route optimization is applied in the VPN scenario, the packets that can not pass through the FW can also reach the MN. Will you give me further comments on this? Thanks in advance. Hiroyuki ----- Original Message ----- From: "Liu, Changwen" To: Sent: Saturday, June 29, 2002 2:28 AM Subject: RE: [mobile-ip] I-D ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt > I read through the draft and here is my quick observation/comment on this > draft: > Unlike MIPv4, MIPv6 (as of draft 17) has better authorization specification > for binding update. For example, in order to avoid unauthorized binding > update for a MNv6, "the security policy database entries MUST unequivocally > identify a single SA for any given home address and home agent" in MIPv6 > while MIPv4 SA doesn't has this restriction. In other words, if the GHA can > send binding update to MIPv6 HA for a MNv6, the MNv6 loses its capability > for sending binding update to its own MIPv6 HA. Hence no matter where MNv6 > roams to, all MNv6 data traffic has to go through GHA and a lot of traffic > has to go through the path HA-GHA. The routing for MNv6 can never be fully > optimized as specified in MIPv6 and triangular routing is unavoidable. If > one wants support full routing optimization for VPN traversal, it seems that > the aforementioned line in MIPv6 specification may need to be changed > slightly to allow more than one SAs for updating any given home address and > home agent pair. > > My two cents. > > changwen > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, June 28, 2002 3:37 AM > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] I-D > > ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Mobile IPv6 VPN using Gateway Home Agent > > Author(s) : H. Ohnishi, K. Suzuki, Y. Takagi > > Filename : draft-ohnishi-mobileip-v6vpngateway-00.txt > > Pages : 18 > > Date : 27-Jun-02 > > > > Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It > > can also be used for public mobility services. One of the most > > important services is the VPN service enabling users to access their > > Intranets from outside. Mobile IP does notwork well with VPN, > > however, and this issue is being discussed in the Mobile IP WG [VPN > > problem]. This document proposes a simple mechanism that combines > > VPN and Mobile IP functions. This mechanism uses a hierarchical HA > > architecture and includes an HA with GW functions, called a Gateway > > Home Agent (GHA). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-v6v > pngateway-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ohnishi-mobileip-v6vpngateway-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ohnishi-mobileip-v6vpngateway-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 5 04:42:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15232 for ; Fri, 5 Jul 2002 04:42:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25504; Fri, 5 Jul 2002 02:43:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25043; Fri, 5 Jul 2002 01:42:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g658fkk7002045 for ; Fri, 5 Jul 2002 01:41:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g658fkOp002044 for mobile-ip-dist; Fri, 5 Jul 2002 01:41:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g658fgk7002037 for ; Fri, 5 Jul 2002 01:41:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14058 for ; Fri, 5 Jul 2002 01:41:48 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29563 for ; Fri, 5 Jul 2002 02:41:47 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g658XTAd001929; Fri, 5 Jul 2002 17:33:31 +0900 (KST) Message-ID: <009b01c223fe$a3d89260$ad29024b@yhhan> From: "Youn-Hee Han" To: Cc: , References: <200207031029.GAA03621@ietf.org> Subject: Re: [mobile-ip] I-D ACTION:draft-han-mobileip-rolmmv6-00.txt Date: Fri, 5 Jul 2002 17:29:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g658fhk7002038 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello mobile-ip and micro-mobility folks! I know you all are very busy since you are being prepared with 54th IETF meeting. I submitted a new draft about the route optimization in LMMv6. Although this late draft is not included in the discussion at this yokohama meeting, I will take great efforts so that the route optimization becomes a important function in LMMv6. If you can find the time, would you please comment about this draft? see you all at yokohama! Best regards, Youn-Hee Han. ----- Original Message ----- From: To: Cc: Sent: Wednesday, July 03, 2002 7:29 PM Subject: [mobile-ip] I-D ACTION:draft-han-mobileip-rolmmv6-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Route Optimization Support for Localized Mobility > Management Based on IPv6 > Author(s) : Y. Han et al. > Filename : draft-han-mobileip-rolmmv6-00.txt > Pages : 10 > Date : 02-Jul-02 > > Using localized mobility management based on IPv6, all packets > destined to a mobile node are routed through the local mobility > agent in the mobile node's local mobility domain, which then > tunnels the packets to the mobile node's current location. Such > packet routing mechanism is similar to the triangle routing in > Mobile IPv4, which may leave the local mobility agent overloaded > and take a longer route thus increasing the network traffic in the > local mobility domain. This document specifies a route optimization > scheme for localized mobility management based on IPv6 with the > help of L2 trigger. Using this, correspondent nodes can cache LCoA > of a mobile node if it is actively communicating with the mobile > node, and then send their packets for the mobile node directly to > the LCoA, bypassing the local mobility agent. This route > optimization scheme will result in more efficient localized > mobility management. It alleviates the local mobility agent's loads > and takes the nearly same handoff delay time as the one in > localized mobility management based on IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-han-mobileip-rolmmv6-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-han-mobileip-rolmmv6-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-han-mobileip-rolmmv6-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 5 05:44:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16031 for ; Fri, 5 Jul 2002 05:44:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03056; Fri, 5 Jul 2002 03:45:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06086; Fri, 5 Jul 2002 02:44:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g659hgk7002301 for ; Fri, 5 Jul 2002 02:43:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g659hg8M002300 for mobile-ip-dist; Fri, 5 Jul 2002 02:43:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g659hdk7002293 for ; Fri, 5 Jul 2002 02:43:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24258 for ; Fri, 5 Jul 2002 02:43:44 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01965 for ; Fri, 5 Jul 2002 03:43:43 -0600 (MDT) From: Masataka Ohta Message-Id: <200207050926.SAA12794@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA12794; Fri, 5 Jul 2002 18:26:10 +0900 Subject: [mobile-ip] revised draft on WLAN and MIP To: mobile-ip@sunroof.eng.sun.com Date: Fri, 5 Jul 2002 18:26:09 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I have revised my draft: Smooth Handover over IEEE 802.11 Wireless LAN It now describes how handover period is minimized by NOT using link layer mobility or link layer beacon signals. Masataka Ohta -- INTERNET DRAFT M. Ohta draft-ohta-smooth-handover-wlan-01.txt Tokyo Institute of Technology July 2002 Smooth Handover over IEEE 802.11 Wireless LAN Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (C) The Internet Society (July/5/2002). All Rights Reserved. Abstract This memo describes, based on the experience of MIS (Mobile Internet Services, Inc.) for commercial mobile IP service over IEEE 802.11b based wireless LAN environment, how handover between access points is made small or smooth. The major obstacle for the smooth handover is time required to scan frequency channels, which is made minimal by pseudo ad-hoc mode and latency of mobile registration is not so much a problem, both of which is solved with terminals having two transceivers. 1. Introduction This memo describes technical detail on handover latency of the service of MIS (Mobile Internet Services, Inc.), the first ISP to have commercialized mobile IP with IEEE 802.11 wireless LAN as a M. Ohta Expires on January 5, 2003 [Page 1] INTERNET DRAFT Smooth Handover over WLAN July 2002 feedback from the real world to IETF. MIS uses IEEE 802.11b based wireless LAN infrastructure and puts a lot of wireless LAN access points to let its subscribers move around with IP mobility. MIS started public field trial in August 2001 and started commercial service in April 2002. During the trial, a possible problem of the wireless LAN became apparent that it takes considerable amount of time, often more than a second, to scan all the possible frequency channels, which is required upon handover to find the next access point better than the current. So, it is important to minimize handover latency, as described in Section 2. As a result, IP mobility with MIS wireless LAN base stations works, even on a car driving on highway at 100Km/h. For some applications such as web browsing, it is not a problem. However, for streaming applications such as Internet telephony, smooth handover with little or no service interruption is strongly desired. As discussed in Sections 3 and 4, the problem of smooth handover is solved by terminals having two wireless transceivers. 2. Minimizing Handover Latency of IEEE 802.11 Wireless LAN with One Transceiver IEEE 802.11 wireless LAN has two mode of operations, infrastructure mode and IBSS mode. Infrastructure mode is capable of frequency channel scanning, link layer mobility and beacon signal processing. IBSS mode is capable of beacon signal processing. However, complex link layer capabilities are seldom useful in the end-to-end Internet, because such link layer is an intelligent intermediate entity. It might be misunderstood that link layer mobility combined with IP layer mobility reduces the latency of handover, because it responds quickly enough, so that IP layer handover should be used only at borders of link layers. To rely on link layer mobility, frequency channels must be scanned once. Then, if IP layer handover is, in addition, required, frequency channels must be scanned again, which unnecessarily increases the M. Ohta Expires on January 5, 2003 [Page 2] INTERNET DRAFT Smooth Handover over WLAN July 2002 latency. To prevent it, access points must be sought regardless of the boundaries of link layer, which means link layer mobility is not used. Even if wireless LAN is used with infrastructure mode, each access point should belong to different ESS and link layer mobility should be disabled. Another problem is beacon processing with both infrastructure and IBSS modes. In both modes, information in link layer beacon is necessary before starting communication. As IEEE 802.11 does not specify anything and WiFi specifies beacon period between 20m second to 1 second, typical, or may be all the, IBSS implementations listen to a frequency channel for 1 second. Then, if a terminal scans all the 14 channels, most of which does not have beacon signals, it takes about 14 seconds, which is prohibitively long. Even if we can somehow shorten the listening period, there is still a problem with link layer beacon signals. While IEEE 802.11 frequency channels are scanned based on limited information in link layer beacon signals, real world scanning needs upper layer information. For example, whether an access point supports IPv4 and/or IPv6 is important upper layer information for scanning. Another important information is the number of remaining IP addresses pooled at an access point (with FA/MN collocation model, which MIS assumes to remove an intermediate intelligent entity of FA from the network). That is, for efficient frequency channel scanning, upper layer software of access points should generate its own beacon signals containing capabilities of the upper layer. To minimize handover latency, it should be as frequent as link layer beacon signals. As inter-frame gaps of IEEE 802.11 is considerably large, separately generating link and upper layer beacons reduces the tolerable beacon frequency by half. Another option is for terminals to actively query upper layer information to access points. However, with many candidate access points, communication with which may involve packet drop and retransmission delay, considerable amount of time is required. That is, link layer beacon signals are not useful. Fortunately, NICs from most, if not all, vendors have so called "pseudo ad-hoc" mode, with which there is no link layer intelligence M. Ohta Expires on January 5, 2003 [Page 3] INTERNET DRAFT Smooth Handover over WLAN July 2002 such as half hearted mobility or beacon signals. MIS relies on the pseudo ad-hoc mode to minimize the latency for frequency channel scanning. Access points of MIS generate beacon signals 30 time a second and it takes about a second to scan all the 14 frequency channels. It is confirmed that IP mobility take over between access points works even with terminals on cars running at 100Km/h. 3. Smooth Handover with Two Transceivers To prevent the service interruption, it is necessary that a terminal, which is expected to run service-interruption-sensitive applications, should have two wireless LAN transceivers, one for keeping connection to the the current access point and another for scanning frequency channels to search alternative ones. 4. Smoother Handover with Two Transceivers With the elimination of service interruption for frequency channel scanning, there still is a smaller amount of service interruption for mobility registration, which can also be eliminated. With two wireless LAN transceivers, just after one transceiver find a new access point better than the current, a new connection to the new access point should be established through the transceiver. Then, mobility registration for the new access point should be initiated. Still, another transceiver should keep connecting to the current access point. A while after the terminal confirms a successful mobility registration, the terminal should terminate the connection to the old access point and, as described in section 2, start scanning newer access points. During mobile registration, packets from CH comes from either of the access points. As the terminal receives packets from both access points, there is no packet loss caused by the latency of the registration. 5. Applications of the Technique The technique described in sections 3 and 4 was deployed in recent PHS (personal handy phone, 32Kbps mobile telephone system available M. Ohta Expires on January 5, 2003 [Page 4] INTERNET DRAFT Smooth Handover over WLAN July 2002 in Japan and other countries) service, only after which, PHS can support stable and smooth handover. In general, the technique requires two sets of transceivers, which increases the cost of terminals, which is welcome to wireless LAN chip vendors, it also reduce the cost of network by eliminating intelligent intermediate entities for half-hearted smooth mobility. Note that a CDMA based wireless transceiver can simultaneously use two access points with different code without additional RF modules. The technique is L1 or L2 independent and is applicable to smooth handover between different media, such as between PHS and WLAN or Ethernet and WLAN. 6. Security Considerations To prevent anonymous and/or unpaid access to the Internet, access points of MIS have packet-wise cryptographical authentication mechanism to disallow unauthorized access to the Internet. To prevent subscribers share a single subscriber ID with single payment, the mechanism disallows multiple terminals with a single subscriber ID simultaneously use access points. As a side effect, the mechanism, basically, disallows a terminal simultaneously use multiple access points. However, to allow for the smooth handover, a terminal is allowed to simultaneously use access points with overlapping service area. 7. Author's Address Masataka Ohta Graduate School of Information Science and Engineering, Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on January 5, 2003 [Page 5] INTERNET DRAFT Smooth Handover over WLAN July 2002 8. Full Copyright Statement "Copyright (C) The Internet Society (July/1/2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. M. Ohta Expires on January 5, 2003 [Page 6] From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 5 06:35:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17288 for ; Fri, 5 Jul 2002 06:35:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17845; Fri, 5 Jul 2002 03:35:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05487; Fri, 5 Jul 2002 03:35:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AXvk7002583 for ; Fri, 5 Jul 2002 03:33:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65AXvWq002582 for mobile-ip-dist; Fri, 5 Jul 2002 03:33:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AXsk7002575 for ; Fri, 5 Jul 2002 03:33:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02303 for ; Fri, 5 Jul 2002 03:33:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA02881 for ; Fri, 5 Jul 2002 04:33:58 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16895; Fri, 5 Jul 2002 06:33:08 -0400 (EDT) Message-Id: <200207051033.GAA16895@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-lmm-requirements-02.txt Date: Fri, 05 Jul 2002 06:33:08 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Localized Mobility Management Requirements Author(s) : C. Williams Filename : draft-ietf-mobileip-lmm-requirements-02.txt Pages : 12 Date : 03-Jul-02 This document describes requirements for Localized Mobility Management (LMM) for Mobile IP and Mobile Ipv6 protocols. These requirements are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces enhancements to Mobile IPv4 and Mobile IPv6 to reduce the amount of latency in binding updates sent to the Home Agent and, for route-optimization, Correspondent Nodes, upon Care of Address change. In addition, LMM seeks to reduce the amount of signaling over the global Internet when a mobile node traverses within a defined local domain. The identified requirements are essential for localized mobility management functionality. They are intended to be used as a guide for analysis on the observed benefits over the identified requirements for architecting and deploying LMM schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-lmm-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-lmm-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-lmm-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-lmm-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131648.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 5 11:45:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00339 for ; Fri, 5 Jul 2002 11:45:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05762; Fri, 5 Jul 2002 09:41:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03506; Fri, 5 Jul 2002 08:40:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Fdek7003352 for ; Fri, 5 Jul 2002 08:39:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65Fdefm003351 for mobile-ip-dist; Fri, 5 Jul 2002 08:39:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Fdbk7003344 for ; Fri, 5 Jul 2002 08:39:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12498 for ; Fri, 5 Jul 2002 08:39:43 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29196 for ; Fri, 5 Jul 2002 09:39:42 -0600 (MDT) Message-ID: <008a01c22439$eee424a0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Vijay Devarapalli'" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 Date: Fri, 5 Jul 2002 08:37:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 2. The draft is very unclear about the > rationale. I know it says that the HAO > can be accepted if IPsec is used, but I > think more text is needed there. > I was very confused by this. If IPsec is required for HAO, then doesn't that mean that the CN must have an IPsec SA with the MN in order to do RO? If so, then what was the point of developing the RR algorithm? This seems to me to be a very limiting requirement. jak From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 7 12:09:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23952 for ; Sun, 7 Jul 2002 12:09:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26480; Sun, 7 Jul 2002 10:10:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02446; Sun, 7 Jul 2002 09:09:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G7xk7006961 for ; Sun, 7 Jul 2002 09:07:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67G7x80006960 for mobile-ip-dist; Sun, 7 Jul 2002 09:07:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G7ok7006938 for ; Sun, 7 Jul 2002 09:07:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24841 for ; Sun, 7 Jul 2002 09:07:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26034 for ; Sun, 7 Jul 2002 10:07:51 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23798; Sun, 7 Jul 2002 12:06:58 -0400 (EDT) Message-Id: <200207071606.MAA23798@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-06.txt Date: Sun, 07 Jul 2002 12:06:58 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Hierarchical MIPv6 mobility management (HMIPv6) Author(s) : H. Soliman, C. Castelluccia, K. Malki, L. Bellier Filename : draft-ietf-mobileip-hmipv6-06.txt Pages : 34 Date : 05-Jul-02 This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-hmipv6-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-hmipv6-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-hmipv6-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-hmipv6-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 7 12:10:07 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24210 for ; Sun, 7 Jul 2002 12:10:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17629; Sun, 7 Jul 2002 09:10:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25150; Sun, 7 Jul 2002 09:09:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G8Ck7006976 for ; Sun, 7 Jul 2002 09:08:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67G8BZI006975 for mobile-ip-dist; Sun, 7 Jul 2002 09:08:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G85k7006968 for ; Sun, 7 Jul 2002 09:08:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05233 for ; Sun, 7 Jul 2002 09:08:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17181 for ; Sun, 7 Jul 2002 09:07:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23808; Sun, 7 Jul 2002 12:07:00 -0400 (EDT) Message-Id: <200207071607.MAA23808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-ipv6-18.txt Date: Sun, 07 Jul 2002 12:07:00 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mobileip-ipv6-18.txt Pages : 157 Date : 05-Jul-02 This document specifies how the IPv6 Internet operates with mobile computers. Without specific support for mobility in IPv6 [11], packets destined to a mobile node would not be able to reach it while the mobile node is away from its home link. In order to continue communication in spite of its movement, a mobile node could change its IP address each time it moves to a new link, but the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet during the lifetime of IPv6. The protocol defined in this document, known as Mobile IPv6, allows a mobile node to move from one link to another without changing the mobile node's IP address. A mobile node is always addressable by its 'home address', an IP address assigned to the mobile node within its home subnet prefix on its home link. Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-ipv6-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ipv6-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 7 12:11:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24536 for ; Sun, 7 Jul 2002 12:11:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27036; Sun, 7 Jul 2002 10:12:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05995; Sun, 7 Jul 2002 09:12:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67GAuk7007070 for ; Sun, 7 Jul 2002 09:10:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67GAu8g007069 for mobile-ip-dist; Sun, 7 Jul 2002 09:10:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67GAqk7007057 for ; Sun, 7 Jul 2002 09:10:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05766 for ; Sun, 7 Jul 2002 09:10:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27599 for ; Sun, 7 Jul 2002 10:10:58 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24186; Sun, 7 Jul 2002 12:10:05 -0400 (EDT) Message-Id: <200207071610.MAA24186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-soliman-mobileip-flow-move-02.txt Date: Sun, 07 Jul 2002 12:10:04 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Per-flow movement in MIPv6 Author(s) : H. Soliman, K. Malki, C. Castelluccia Filename : draft-soliman-mobileip-flow-move-02.txt Pages : 9 Date : 05-Jul-02 The aim of this draft is to introduce a new extension to MIPv6 to allow hosts to direct inbound flows individually to certain preferred interfaces. This extension to MIPv6 allows multi-homed hosts to take full advantage of the diverse access technologies that they may be connected to and direct their traffic according to internal policies specified by the users or applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-soliman-mobileip-flow-move-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-soliman-mobileip-flow-move-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-soliman-mobileip-flow-move-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-soliman-mobileip-flow-move-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141928.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 7 12:12:28 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24555 for ; Sun, 7 Jul 2002 12:12:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14978; Sun, 7 Jul 2002 09:12:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06031; Sun, 7 Jul 2002 09:12:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67GB6k7007099 for ; Sun, 7 Jul 2002 09:11:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67GB6J7007097 for mobile-ip-dist; Sun, 7 Jul 2002 09:11:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67GAwk7007073 for ; Sun, 7 Jul 2002 09:10:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02696 for ; Sun, 7 Jul 2002 09:11:04 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05461 for ; Sun, 7 Jul 2002 10:11:03 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24268; Sun, 7 Jul 2002 12:10:10 -0400 (EDT) Message-Id: <200207071610.MAA24268@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-montenegro-sucv-03.txt Date: Sun, 07 Jul 2002 12:10:10 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-03.txt Pages : 34 Date : 05-Jul-02 This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montenegro-sucv-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montenegro-sucv-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-montenegro-sucv-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705142043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142043.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 7 13:42:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27841 for ; Sun, 7 Jul 2002 13:42:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09419; Sun, 7 Jul 2002 11:43:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16517; Sun, 7 Jul 2002 10:42:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67Hfpk7007623 for ; Sun, 7 Jul 2002 10:41:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67HfpFo007622 for mobile-ip-dist; Sun, 7 Jul 2002 10:41:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67Hflk7007615 for ; Sun, 7 Jul 2002 10:41:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19518 for ; Sun, 7 Jul 2002 10:41:53 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21349 for ; Sun, 7 Jul 2002 11:41:52 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id D621C6A904; Sun, 7 Jul 2002 20:41:44 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 951EE6A901; Sun, 7 Jul 2002 20:41:41 +0300 (EEST) Message-ID: <3D287DB9.9040107@kolumbus.fi> Date: Sun, 07 Jul 2002 20:43:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: "Hesham Soliman (EAB)" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> <008a01c22439$eee424a0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: >>2. The draft is very unclear about the >>rationale. I know it says that the HAO >>can be accepted if IPsec is used, but I >>think more text is needed there. >> >> > > I was very confused by this. > > If IPsec is required for HAO, then doesn't that mean that the CN must have an IPsec SA with the MN in order to do RO? If so, then > what was the point of developing the RR algorithm? > > This seems to me to be a very limiting requirement. No, the discussion was that HAO can be accepted when *either* RR or IPsec has been used. So, IPsec SA is not a requirement for RO. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 04:46:07 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08182 for ; Mon, 8 Jul 2002 04:46:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01722; Mon, 8 Jul 2002 01:46:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27947; Mon, 8 Jul 2002 01:46:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g688j0k7008852 for ; Mon, 8 Jul 2002 01:45:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g688j0ET008851 for mobile-ip-dist; Mon, 8 Jul 2002 01:45:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g688iuk7008844 for ; Mon, 8 Jul 2002 01:44:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23284 for ; Mon, 8 Jul 2002 01:45:03 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01317 for ; Mon, 8 Jul 2002 01:45:03 -0700 (PDT) Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 04:45:02 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4601030715@ftmail.lab.flarion.com> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIP and multicast Date: Mon, 8 Jul 2002 04:45:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I have just submitted an internet-draft (abstract below) on the subject of MIPv4 and MIPv6 multicast support via the Foreign multicast system which will be available at http://www.flarion.com/technology/tech_standards.html hopefully early this week. Both MIPv4 and MIPv6 presently require the MN to use a CCoA as a foreign multicast source address. This I believe is problematic for multicast protocols that build source specific trees at cellular mobility rates. This is because each tree needs to be rebuilt on every hand-off which is going to thrash the routing system because every router on each tree is being exposed to the movement of every MN on that tree. Clearly, the more trees with MN senders the worse this problem becomes. ASM (PIM-SM) and SSM (on any protocol) all build source trees so I believe this is a major deployment barrier for foreign network multicast. In contrast, the HoA is stable across hand-offs and therefore this should be the source address and also used to populate multicast forwarding entries. To avoid the RPF check failing (expects packets from the HA and not the FA), the draft discusses various ways to initially bypass the problematic RPF checks, but in the future for multicast routing protocols to be evolved to be able to support an arbitrary RPF point (the present Multicast Designated Router of the MN). The RPF approach is optimal because each hand-off only changes the RPF interface in routers local to the hand-off and is therefore scalable. The draft does not however deal with the multicast changes in detail but is simplky intended to motivate discussion, MIP spec changes and appropriate multicast research and standards work. I will be in Yokohama from sunday to wednesday afternoon and am happy to discuss this with interested parties outside the main meeting. Regards, Alan. Mobility Management and IP Multicast Abstract Mobile IP provides a mobile node, that visits a foreign subnet, the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a redirection tunnel from a home agent on the home subnet. Mobile IP in RFC 3220 states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks. This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 11:51:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20940 for ; Mon, 8 Jul 2002 11:51:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26725; Mon, 8 Jul 2002 08:51:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21730; Mon, 8 Jul 2002 08:51:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68FoYk7009530 for ; Mon, 8 Jul 2002 08:50:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68FoYGE009529 for mobile-ip-dist; Mon, 8 Jul 2002 08:50:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68FoUk7009522 for ; Mon, 8 Jul 2002 08:50:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18877 for ; Mon, 8 Jul 2002 08:50:36 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06948 for ; Mon, 8 Jul 2002 08:50:36 -0700 (PDT) Message-ID: <00ab01c22696$eb515100$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: "Hesham Soliman \(EAB\)" , "'Vijay Devarapalli'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> <008a01c22439$eee424a0$4f6015ac@T23KEMPF> <3D287DB9.9040107@kolumbus.fi> Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 Date: Mon, 8 Jul 2002 08:48:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, Thanx for the clarification. I think the draft needs to be clearer about this. Perhaps it could be stated in the requirements section. jak ----- Original Message ----- From: "Jari Arkko" To: "James Kempf" Cc: "Hesham Soliman (EAB)" ; "'Vijay Devarapalli'" ; Sent: Sunday, July 07, 2002 10:43 AM Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 > James Kempf wrote: > > >>2. The draft is very unclear about the > >>rationale. I know it says that the HAO > >>can be accepted if IPsec is used, but I > >>think more text is needed there. > >> > >> > > > > I was very confused by this. > > > > If IPsec is required for HAO, then doesn't that mean that the CN must have an IPsec SA with the MN in order to do RO? If so, then > > what was the point of developing the RR algorithm? > > > > This seems to me to be a very limiting requirement. > > > No, the discussion was that HAO can be accepted when *either* RR or IPsec has > been used. So, IPsec SA is not a requirement for RO. > > Jari > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 13:53:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27835 for ; Mon, 8 Jul 2002 13:53:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07627; Mon, 8 Jul 2002 11:53:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04380; Mon, 8 Jul 2002 10:52:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68Hpkk7010123 for ; Mon, 8 Jul 2002 10:51:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68HpkKL010122 for mobile-ip-dist; Mon, 8 Jul 2002 10:51:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68Hphk7010115 for ; Mon, 8 Jul 2002 10:51:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10981 for ; Mon, 8 Jul 2002 10:51:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06444 for ; Mon, 8 Jul 2002 11:51:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA26196; Mon, 8 Jul 2002 10:51:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68HpkV27803; Mon, 8 Jul 2002 10:51:46 -0700 X-mProtect: <200207081751> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAxhpXk; Mon, 08 Jul 2002 10:51:45 PDT Message-ID: <3D29D131.738AC9B9@iprg.nokia.com> Date: Mon, 08 Jul 2002 10:51:45 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Hesham, "Hesham Soliman (EAB)" wrote: > > Hi Vijay, > > My comment was two fold: > > 1. Is it worth it? You say, yes it is > because we get triangulr routing. > I'm not so sure that triangular routing > is much better, but anyway this is not > my biggest concern. That one is below I will avoid getting into a debate whether triangular routing is better. (IMO it is better than reverse tunneling if we can avoid the possible reflection attacks). > 2. The draft is very unclear about the > rationale. I know it says that the HAO > can be accepted if IPsec is used, but I > think more text is needed there. > > (2) is more important to me than (1), because > I was a bit confused by section 8, and I would > imagine that someone reading this for the first > time will be more confused. not just IPsec. basically we are tying the processing of HAO to the verifiability of the home address (to avoid reflection attacks). maybe we can include more text to explain this clearly. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 14:17:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29270 for ; Mon, 8 Jul 2002 14:17:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21705; Mon, 8 Jul 2002 12:16:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14417; Mon, 8 Jul 2002 11:16:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68IEZk7010430 for ; Mon, 8 Jul 2002 11:14:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68IEZOu010429 for mobile-ip-dist; Mon, 8 Jul 2002 11:14:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68IEWk7010422 for ; Mon, 8 Jul 2002 11:14:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17440 for ; Mon, 8 Jul 2002 11:14:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18736 for ; Mon, 8 Jul 2002 11:14:37 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27845; Mon, 8 Jul 2002 11:14:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68IEaU29341; Mon, 8 Jul 2002 11:14:36 -0700 X-mProtect: <200207081814> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM4wFvW; Mon, 08 Jul 2002 11:14:33 PDT Message-ID: <3D29D689.10D89886@iprg.nokia.com> Date: Mon, 08 Jul 2002 11:14:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F080D@Esealnt861.al.sw.ericsson.se> <3D23F0B8.5030802@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > There's two things here. One is whether the current > spec adequately explains how all this works even if RO > is not used. Does it? Secondly, how useful is the > functionality? > > => new issue #53 (hmm... it has been discussed before...) I havent seen the text for this new issue. but this has been discussed as part of both Issue #31 and Issue #45. and both issues have been closed. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 16:47:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07849 for ; Mon, 8 Jul 2002 16:47:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24205; Mon, 8 Jul 2002 14:48:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07553; Mon, 8 Jul 2002 13:47:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68Kkfk7010748 for ; Mon, 8 Jul 2002 13:46:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68KkflJ010747 for mobile-ip-dist; Mon, 8 Jul 2002 13:46:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68Kkck7010740 for ; Mon, 8 Jul 2002 13:46:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11943 for ; Mon, 8 Jul 2002 13:46:44 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05249 for ; Mon, 8 Jul 2002 14:46:43 -0600 (MDT) Received: from kmilesw2k (ams-clip-vpn-dhcp136.cisco.com [10.50.0.135]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA17641 for ; Mon, 8 Jul 2002 21:46:40 +0100 (BST) From: "Kevin Miles" To: Subject: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Mon, 8 Jul 2002 21:37:25 +0100 Message-ID: <007e01c226c0$8de9eed0$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Various comments on MIPv6 I-D 18. 1. There still appears to be a minor bug in the description of how the DHAAD response is created. The addresses are ordered by decreasing Preference, and if the sender is the first in the list, its address should be omitted and the recipient will assume that the sender is most preferred. But there is also the provision for truncating the response if it exceeds max MTU. So, for example, if the sender is least preferred but its address gets truncated because of MTU size constraints, the recipient will incorrectly assume the sender to be most preferred. Since all this is specified using SHOULD and SHOULD NOT, an implementation can legitimately achieve approximately the intended behaviour by not doing what the I-D says, but the way it is currently described is an invitation to error. An obvious fix is to eliminate the 'bandwidth conservation' and explicitly transmit all addresses that will fit in the response. 2. In section 9.4.1, it says: "If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.2; otherwise, it is processed according to the procedure specified in Section 9.4.2." Unfortunately, the context of this text implies that the Return Routeability procedure can be used to secure a Home Registration, which is not the case. Same problem with the next bullet, too. 3. Sections 6.1.8 and 9.4.4 are inconsistent. The former says a BA does not use a routing header. The latter describes conditions under which it does. 4. Section 10.3 says "If the home agent does not reject the Binding Update as described above, then it MUST delete any existing entry in its Binding Cache for this mobile node, and proceed as follows." Should "any existing entry" read "all existing entries"? I.e., what are the semantics of the S bit in a deregistration? For example, is it permissible to register a set of addresses using S=0 and then individually deregister them with S=1? Editorial: 5. The document still has a few instances of "Binding Update option". Most, if not all, should read "Binding Update" or "Binding Update message. 6. Repeated text on p64: "Subsequent checks depend on the particular Mobility Header message, as specified in Sections 9.3 and 9.4. Subsequent checks depend on the particular Mobility Header message." Kevin. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 19:01:55 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15927 for ; Mon, 8 Jul 2002 19:01:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09388; Mon, 8 Jul 2002 16:01:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18013; Mon, 8 Jul 2002 16:01:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68N0Nk7011092 for ; Mon, 8 Jul 2002 16:00:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68N0MhI011091 for mobile-ip-dist; Mon, 8 Jul 2002 16:00:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68N0Jk7011084 for ; Mon, 8 Jul 2002 16:00:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28161 for ; Mon, 8 Jul 2002 16:00:25 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08546 for ; Mon, 8 Jul 2002 16:00:25 -0700 (PDT) Message-ID: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt Date: Mon, 8 Jul 2002 15:41:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I read through the MIPv6 spec last week and this note contains some suggestions. The spec is really long, and I think anything that could be done to reduce the size without compromising an accurate and detailed description of the basic protocol would be very beneficial. On the plus side, most of the technical details look good, the authors have done a good job of collecting WG opinion and forging it into a new and interesting technology. Of the following suggestions, only 2) would really need to be completed before RFC if there is an urgent need to get it out now, the rest could follow as incremental changes, with the proper attention to requirement level, IMHO. jak ----------------------------------------------- 1) Editorial The spec is in need of being worked through by a technical editor with an understanding of IETF specifications. In some cases, MUST and SHOULD language is missing where it would be useful to designate requirement level. Section 5.2 contains much detail on RR, exactly at the right level for an IETF specification, but unfortunately some of the other sections aren't up to that level. Also, there are cases where information on particular operations are spread across a number of sections making it difficult to see what is required to implement. The material in Appendix A should either be incorporated into the text or dropped. Similarly, the other two appendicies should be dropped. Appendix C would be good for the WG to use as a guide for future work, but doesn't belong here. There are lots of other such editorial changes that could be done to tighten the spec up. 2) Security with CN needed for RO On pg. 65 in Section 9.2.2, there is this statement about security for RO: Due to the threat of reflection attacks, this specification requires that packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache Entry for the given home address and the packet was not protected by IPsec. This sentence seems to imply that an IPsec SA is required between the CN and MN in order to perform RO (for which the Home Address option is used). However, in the requirements for all IPv6 nodes in Section 8.2 there is no such requirement. The practical difficulty of requiring an IPsec SA between the CN and MN was one of the motivating factors for developing the RR algorithm for securing the routing change. Requiring it in order that the actual routing itself can be done faces exactly the same practical issues. I think it would be helpful to change the "and" to an "or". 3) Security between the MN and HA There are various bits and pieces of text that deal with the security required between the MN and HA for Mobile IP signaling. For example, Section 5.1 contains a very sketchy description of the IPsec SA required for RR, where either ESP or AH is allowed. There is also some material in Section 6.1.3 along the same lines when the HoTI message is described. Section 6.8 requires an AH header for the Mobile Prefix Advertisement message (though this is not required by the SA for RR). And Section 10.7 requires ESP for RR, but not AH. In Section 11.2.2, there is a short discussion on pg. 97 about using IKE for key distribution. I think this material should be collected into a single section in which the details of the security association between the MN and HA for purposes of securing MIP signaling should be described. This section should be very specific and detailed, so there is no question of ambiguity or interoperability problems, and should deal with key management as well. Also, there should be some consideration whether the same SA can be used for securing tunneled traffic as well, in the interests of economizing the amount of processing and code. 4) Alternate Care of Address? Throughout the spec, there are occasional references to this, but I was unable to pin down exactly why this was there, and how it might be used by the HA. In Seamoby, there have been some proposals to use it for hosts that are in dormant mode, but I really couldn't tell whether it could be used from this spec. I think that a section should clearly explain why this was included in the spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped. 5) HA Service Discovery and MN Address Provisioning I was suprised to discover that MIPv6 defines its own protocol for service discovery of the HA and address provisioning of the MN. In particular, Sections 6.5 and 6.6 describe HA service discovery messages and Section 6.7, and 6.8 describe the address provisioning messages. Sections 10.9, 11.3.2, 11.3.3, and 11.3.4 describe the operation of these new protocols. I'm having a difficult time understanding why Mobile IP can't use standard IPv6 protocols in this area. In particular, it seems like DNS SRV records would be ideal for discovering the HA. Typically, an MN would have an NAI for the user's home network, and it could use the domain name as a way to look up the SRV record for the HA's address. This seems much more consistent with the typical way that IP services are discovered. As for address configuration, many of the operations described for the HA in handling MN home address assignment are exactly the same kinds of operations that a DHCP server would be expected to perform. So I'm wondering if DHCP might not be a better solution than a special Mobile IP protocol. Both DNS and DHCP would be expected on most IPv6 hosts, though, I suppose one could argue about the latter since stateless autoconfig might be expected to handle many cases. In any event, regardless of whether these suggestions are useful or not (and I don't really think this is the right thread to debate that issue) I think the spec could be profitably shortened by removing these items and taking them as separate work items for a seperate specification describing how a MN away from home configures itself. 6) Forwarding from Previous Care of Address In Section 2, the following design goal for Mobile IPv6 is stated prominently: -There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, mobile nodes can make use of IPv6 features, to operate in any location without any special support required from the local router. Yet, once we dive into the document, we find specifications for forwarding from previous care of address, which requires an access router to interpret Mobility Headers in a way different from a standard IPv6 node, that makes it an "on link" home agent. In particular, Section 11.6.6 contains most details, but others are scattered through out the specification. Since forwarding from previous care of address is meant to be a handover optimization, I think it could easily be removed from the base specification if the working group is serious about maintaining consistency to the original design goals in the base specification. There is already ongoing work on handover optimization, and forwarding from previous care of address could be folded into that work. The debate about whether an access router should support just generic IPv6 functionality or some special Mobile IP signaling could then take place within the handover optimization work, and the base spec could remain deployable with any IPv6 router, as was the original design intent. 7) BA return Section 6.1.8 says that a BA MUST be sent if the A bit is set, but it does not say what should happen if the A bit isn't set. Can a node send a BA if the A bit isn't set? 8) PadN Would it be worthwhile to specify that the PadN bits must be zeroed? 9) MaxRtAdvInterval In Section 7.5, this number is defined to be 1.5 seconds, but there may be certain wireless links where periodic multicast router advertisements are unnecessary or expensive for reasons of spectral efficiency. I think the network administrator should have the option of configuring this off in such cases. 10) Using the CoA On pg. 94 in Section 11.2.1, the second bullet item allows the MN to use the CoA for certain communications, but I have a difficult time seeing how this could be done given the standard socket API. Perhaps this is not an issue for this spec, but it does need some consideration. On the next page, the direct delivery option should mention that the described technique won't work without a Binding Cache entry or an IPsec SA. 11) NS or RS? On pg. 106, an NS message is recommended for probing the router, but wouldn't an RS be more appropriate, since the mobile node is interested in the router function? 12) Value judgement on security infrastructure In Section 14.2, pg. 130 contains a paragraph with a value judgement on whether security infrastructure might be deployable or not. It is too early to tell whether this value judgement is correct and, in any event, it does not belong in this specification. The infrastructureless approach can be motivated by the simple statement that deploying an IPsec security association between two arbitrary node in the Internet in the absence of a global PKI is a hard problem, and so a solution that does not require such was developed in the interests of maintaining the minimum requirements for deployable MIPv6. Whether or not an infrastructure based solution can be developed for some subproblem is an open question. 13) References The nonnormative references should be removed or converted into normative references. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 19:23:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16830 for ; Mon, 8 Jul 2002 19:23:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05140; Mon, 8 Jul 2002 17:24:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05872; Mon, 8 Jul 2002 16:24:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68NN8k7011283 for ; Mon, 8 Jul 2002 16:23:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68NN7pc011282 for mobile-ip-dist; Mon, 8 Jul 2002 16:23:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68NN4k7011275 for ; Mon, 8 Jul 2002 16:23:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01506 for ; Mon, 8 Jul 2002 16:23:10 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11710 for ; Mon, 8 Jul 2002 17:23:10 -0600 (MDT) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g68NN339018529; Mon, 8 Jul 2002 16:23:03 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA29574; Mon, 8 Jul 2002 16:23:03 -0700 (PDT) Message-ID: <3D2A1ED7.1F66356A@cisco.com> Date: Mon, 08 Jul 2002 16:23:03 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP WG CC: "Adrangi, Farid" Subject: [mobile-ip] Bar BoF: Mobile IPv4 VPN Traversal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, A bar BoF session is planned during the upcoming IETF meeting in Yokohama, to talk about VPN Traversal draft for MoIP v4: http://ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt The bar BoF will begin at 9:30am on Monday July 15, 2002. All interested people should please meet near the IETF registration desks. The agenda is to: 1. Summarize the status of the VPN traversal drafts 2. Discuss the MoIP v4 solution requirements 3. Discuss the VPN traversal solutions Those who would like to attend this bar BoF session, please send mail directly to Farid Adrangi (copied here) or me. Thank you, Milind From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 8 22:16:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26539 for ; Mon, 8 Jul 2002 22:16:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02526; Mon, 8 Jul 2002 20:17:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22975; Mon, 8 Jul 2002 19:17:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g692Fqk7011672 for ; Mon, 8 Jul 2002 19:15:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g692FqU2011671 for mobile-ip-dist; Mon, 8 Jul 2002 19:15:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g692Fnk7011664 for ; Mon, 8 Jul 2002 19:15:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22721 for ; Mon, 8 Jul 2002 19:15:55 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02037 for ; Mon, 8 Jul 2002 20:15:54 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA05289 for ; Tue, 9 Jul 2002 11:15:53 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA04303 for ; Tue, 9 Jul 2002 11:15:52 +0900 (JST) Date: Tue, 09 Jul 2002 11:14:36 +0900 (JST) Message-Id: <20020709.111436.38059535.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] current issue situation From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D1B71F0.4090501@kolumbus.fi> References: <3D1B71F0.4090501@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm sorry I may have missed the discussion. From: Jari Arkko > 45 Adopted HAO keyword same as for RO or MUST? Let me confirm the conclusion. As I have said in the mailing-list before, there are four types of CNs. (Sorry for the duplicated explanation.) CN0: has no special MIP6 processing code. CN1: processes HAO only if it is protected (by IPsec). CN2: processes HAO only if it is protected (by IPsec) and accepts a BU only if it is protected (by IPsec). CN3: does RR and processes HAO if it is verified and accepts a BU if it is protected (by RR). Vijay suggested CN2 capability for all CNs. There seems no one has any objection for this. This means all the IPv6 node must support the binding cache management (= RO) if the BU/HAO is protected by the IPsec. Is it WG consecsus? http://www.piuha.net/~jarkko/publications/mipv6/issues/issue45.txt --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 03:53:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15485 for ; Tue, 9 Jul 2002 03:53:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06246; Tue, 9 Jul 2002 00:53:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12802; Tue, 9 Jul 2002 00:53:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g697pZk7012267 for ; Tue, 9 Jul 2002 00:51:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g697pZlE012266 for mobile-ip-dist; Tue, 9 Jul 2002 00:51:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g697pRk7012259 for ; Tue, 9 Jul 2002 00:51:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12544 for ; Tue, 9 Jul 2002 00:51:34 -0700 (PDT) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15024 for ; Tue, 9 Jul 2002 01:51:32 -0600 (MDT) Received: from ROJOSEW2K ([10.77.139.146]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA01654; Tue, 9 Jul 2002 13:21:23 +0530 (IST) Message-ID: <0e5f01c2271d$6ddd4df0$928b4d0a@apac.cisco.com> From: "Roy Jose" To: "Alan O'Neill" , References: <8C92E23A3E87FB479988285F9E22BE4601030715@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] MIP and multicast Date: Tue, 9 Jul 2002 13:21:25 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Alan, Why am not able find your draft using ID search? -Roy > I have just submitted an internet-draft (abstract below) on the subject of > MIPv4 and MIPv6 multicast support via the Foreign multicast system which > will be available at http://www.flarion.com/technology/tech_standards.html > hopefully early this week. > > Both MIPv4 and MIPv6 presently require the MN to use a CCoA as a foreign > multicast source address. This I believe is problematic for multicast > protocols that build source specific trees at cellular mobility rates. This > is because each tree needs to be rebuilt on every hand-off which is going to > thrash the routing system because every router on each tree is being exposed > to the movement of every MN on that tree. Clearly, the more trees with MN > senders the worse this problem becomes. ASM (PIM-SM) and SSM (on any > protocol) all build source trees so I believe this is a major deployment > barrier for foreign network multicast. > > In contrast, the HoA is stable across hand-offs and therefore this should be > the source address and also used to populate multicast forwarding entries. > To avoid the RPF check failing (expects packets from the HA and not the FA), > the draft discusses various ways to initially bypass the problematic RPF > checks, but in the future for multicast routing protocols to be evolved to > be able to support an arbitrary RPF point (the present Multicast Designated > Router of the MN). The RPF approach is optimal because each hand-off only > changes the RPF interface in routers local to the hand-off and is therefore > scalable. The draft does not however deal with the multicast changes in > detail but is simplky intended to motivate discussion, MIP spec changes and > appropriate multicast research and standards work. > > I will be in Yokohama from sunday to wednesday afternoon and am happy to > discuss this with interested parties outside the main meeting. > > Regards, Alan. > > > Mobility Management and IP Multicast > > Abstract > > Mobile IP provides a mobile node, that visits a foreign subnet, the > ability > to continue to use an address from its home subnet (the home address) as > a > source address. This is achieved through the allocation of a Care of > Address > on the foreign subnet that is used as the end-point of a redirection > tunnel > from a home agent on the home subnet. Mobile IP in RFC 3220 states that > when > the mobile node originates multicast traffic intended for the foreign > multicast system, it can only do so by first obtaining an IP address from > the > foreign subnet (a Collocated Care of Address) and then using this address > as > the multicast source address. This is to ensure that the source address > will > pass multicast routing reverse path forwarding checks. > > This foreign multicast model is however extremely restrictive, and still > very > problematic to multicast routing and applications when the mobile node > regularly changes foreign subnets, as is common in wireless systems. This > is > because the source address continues to evolve which must be tracked by > source specific multicast application and routing signalling. Using the > home > multicast system, again described above, is also non-optimal because the > mobile node receiver is then serviced by packets that must be tunnelled > from > its home agent which, removes any multicast routing benefits (ie network > based tree building). This draft therefore describes modifications to the > > foreign multicast interface between mobile IP and multicast routing that > enable the mobile node to use its persistent home address as a multicast > source address. > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 05:56:48 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17981 for ; Tue, 9 Jul 2002 05:56:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07183; Tue, 9 Jul 2002 02:56:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23369; Tue, 9 Jul 2002 02:56:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699tVk7012777 for ; Tue, 9 Jul 2002 02:55:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g699tVo4012776 for mobile-ip-dist; Tue, 9 Jul 2002 02:55:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699tRk7012768 for ; Tue, 9 Jul 2002 02:55:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19861 for ; Tue, 9 Jul 2002 02:55:33 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14160 for ; Tue, 9 Jul 2002 02:55:32 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id BD6DE6A901; Tue, 9 Jul 2002 12:55:25 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8E1356A906; Tue, 9 Jul 2002 12:54:56 +0300 (EEST) Message-ID: <3D2AB324.8080303@kolumbus.fi> Date: Tue, 09 Jul 2002 12:55:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi James and thanks for your in-depth comments. I assigned issue #55 for this. Some discussion follows in-line. > I read through the MIPv6 spec last week and this note contains some suggestions. The spec is really long, and I think anything that > could be done to reduce the size without compromising an accurate and detailed description of the basic protocol would be very I agree. We did quite a bit of work on this already for draft 18, in an editorial sense. Further editorial suggestions on reducing the length and/or suggestions about the general scope of the protocol are of course highly appreciated. > beneficial. On the plus side, most of the technical details look good, the authors have done a good job of collecting WG opinion and > forging it into a new and interesting technology. Of the following suggestions, only 2) would really need to be completed before RFC > if there is an urgent need to get it out now, the rest could follow as incremental changes, with the proper attention to requirement > level, IMHO. > > jak > > ----------------------------------------------- > > 1) Editorial > > The spec is in need of being worked through by a technical editor with an understanding of IETF specifications. In some cases, MUST > and SHOULD language is missing where it would be useful to designate requirement level. Section 5.2 contains much detail on RR, > exactly at the right level for an IETF specification, but unfortunately some of the other sections aren't up to that level. Also, Yes... perhaps we should go through the spec with this particular aspect in mind. Do you have any particular complaints about sections that don't do well in this aspect? > there are cases where information on particular operations are spread across a number of sections making it difficult to see what is > required to implement. The material in Appendix A should either be incorporated into the text or dropped. Similarly, the other two > appendicies should be dropped. Appendix A is, I believe, inline with the textual descriptions earlier. The question is if people feel that a relatively short description of states helps them understand what the protocol does, or if they will be reading only the text. How does the list feel about this? I'm ready to remove appendix A or make it part of earlier sections. Change lists (appendix B) are normally removed by the time a spec reaches the RFC editor. I think we should do so here as well, but keep it until we actually are sending the I-D version to the editor. > Appendix C would be good for the WG to use as a guide for future work, but doesn't belong here. There > are lots of other such editorial changes that could be done to tighten the spec up. Yes. (We actually considered this in the last moments before the I-D deadline but didn't finally have time for removing it.) > 2) Security with CN needed for RO > > On pg. 65 in Section 9.2.2, there is this statement about security for RO: > > Due to the threat of reflection attacks, this specification requires that packets containing a Home Address option > MUST be dropped if there is no corresponding Binding Cache Entry for the given home address and the > packet was not protected by IPsec. > > This sentence seems to imply that an IPsec SA is required between the CN and MN in order to perform RO (for which the Home Address > option is used). However, in the requirements for all IPv6 nodes in Section 8.2 there is no such requirement. > > The practical difficulty of requiring an IPsec SA between the CN and MN was one of the motivating factors for developing the RR > algorithm for securing the routing change. Requiring it in order that the actual routing itself can be done faces exactly the same > practical issues. I think it would be helpful to change the "and" to an "or". Right. That was the intention. We do not require IPsec for CN communications. RR is used to establish a binding, and then HAO, RH, and direct communication can be used. (However, even folks who are not using RO at all can use HAO if they have IPsec.) > 3) Security between the MN and HA > > There are various bits and pieces of text that deal with the security required between the MN and HA for Mobile IP signaling. For > example, Section 5.1 contains a very sketchy description of the IPsec SA required for RR, where either ESP or AH is allowed. There > is also some material in Section 6.1.3 along the same lines when the HoTI message is described. Section 6.8 requires an AH header > for the Mobile Prefix Advertisement message (though this is not required by the SA for RR). And Section 10.7 requires ESP for RR, > but not AH. In Section 11.2.2, there is a short discussion on pg. 97 about using IKE for key distribution. > > I think this material should be collected into a single section in which the details of the security association between the MN and > HA for purposes of securing MIP signaling should be described. This section should be very specific and detailed, so there is no > question of ambiguity or interoperability problems, and should deal with key management as well. Also, there should be some > consideration whether the same SA can be used for securing tunneled traffic as well, in the interests of economizing the amount of > processing and code. In general I agree about this concern. We've been working with Vijay on a separate note (that I hope to post to the list soon) which describes the IPsec processing, SPD configurations, SAD contents, and so on. Same SAs can't be used for multiple purposes, due to the need to specify address-based selectors in the SAD/SPD. > 4) Alternate Care of Address? > > Throughout the spec, there are occasional references to this, but I was unable to pin down exactly why this was there, and how it > might be used by the HA. In Seamoby, there have been some proposals to use it for hosts that are in dormant mode, but I really > couldn't tell whether it could be used from this spec. I think that a section should clearly explain why this was included in the > spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped. I'll let others comment on this. > 5) HA Service Discovery and MN Address Provisioning > > I was suprised to discover that MIPv6 defines its own protocol for service discovery of the HA and address provisioning of the MN. > In particular, Sections 6.5 and 6.6 describe HA service discovery messages and Section 6.7, and 6.8 describe the address > provisioning messages. Sections 10.9, 11.3.2, 11.3.3, and 11.3.4 describe the operation of these new protocols. > > I'm having a difficult time understanding why Mobile IP can't use standard IPv6 protocols in this area. In particular, it seems like > DNS SRV records would be ideal for discovering the HA. Typically, an MN would have an NAI for the user's home network, and it could > use the domain name as a way to look up the SRV record for the HA's address. This seems much more consistent with the typical way > that IP services are discovered. As for address configuration, many of the operations described for the HA in handling MN home > address assignment are exactly the same kinds of operations that a DHCP server would be expected to perform. So I'm wondering if > DHCP might not be a better solution than a special Mobile IP protocol. Both DNS and DHCP would be expected on most IPv6 hosts, > though, I suppose one could argue about the latter since stateless autoconfig might be expected to handle many cases. > > In any event, regardless of whether these suggestions are useful or not (and I don't really think this is the right thread to debate > that issue) I think the spec could be profitably shortened by removing these items and taking them as separate work items for a > seperate specification describing how a MN away from home configures itself. DNS SRV records might work, but I'm uncertain about DHCP. Wouldn't DHCP be deployed locally, in the visited domain? This would imply some relationship between the visited and home domains which we may not always want. > 6) Forwarding from Previous Care of Address > > In Section 2, the following design goal for Mobile IPv6 is stated prominently: > > -There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In > Mobile IPv6, mobile nodes can make use of IPv6 features, to operate in any location without any > special support required from the local router. > > Yet, once we dive into the document, we find specifications for forwarding from previous care of address, which requires an access > router to interpret Mobility Headers in a way different from a standard IPv6 node, that makes it an "on link" home agent. In > particular, Section 11.6.6 contains most details, but others are scattered through out the specification. > > Since forwarding from previous care of address is meant to be a handover optimization, I think it could easily be removed from the > base specification if the working group is serious about maintaining consistency to the original design goals in the base > specification. There is already ongoing work on handover optimization, and forwarding from previous care of address could be folded > into that work. The debate about whether an access router should support just generic IPv6 functionality or some special Mobile IP > signaling could then take place within the handover optimization work, and the base spec could remain deployable with any IPv6 > router, as was the original design intent. I agree. How do others feel? > 7) BA return > > Section 6.1.8 says that a BA MUST be sent if the A bit is set, but it does not say what should happen if the A bit isn't set. Can a > node send a BA if the A bit isn't set? I removed the text in 6.1.8 about the BA, since there is more specific rules in the corresponding behaviour sections later in the draft. For instance, a home agent always returns a BA regardless of the A bit setting. > 8) PadN > > Would it be worthwhile to specify that the PadN bits must be zeroed? Yes. > 9) MaxRtAdvInterval > > In Section 7.5, this number is defined to be 1.5 seconds, but there may be certain wireless links where periodic multicast router > advertisements are unnecessary or expensive for reasons of spectral efficiency. I think the network administrator should have the > option of configuring this off in such cases. Yes.. we debated about this a while ago. I wonder if the current text is perhaps sufficient? It does say after the recommendations that the limits MUST be configurable. Or perhaps you are suggesting to turn it off completely. Yes, that capabability would be useful on some link types. > 10) Using the CoA > > On pg. 94 in Section 11.2.1, the second bullet item allows the MN to use the CoA for certain communications, but I have a difficult > time seeing how this could be done given the standard socket API. Perhaps this is not an issue for this spec, but it does need some > consideration. I believe we could (1) skip the description of the CoA usage and leave it as obvious for implementors to figure out, avoiding the API discussion altogether, (2) include the current text but add a note somewhere that this requires API support, or (3) leave this issue for the general source address selection work. There's an IPv6 draft (becoming an RFC) on address selection.. I wonder if it says anything about this subject... > On the next page, the direct delivery option should mention that the described technique won't work without a Binding Cache entry or > an IPsec SA. Yes. > 11) NS or RS? > > On pg. 106, an NS message is recommended for probing the router, but wouldn't an RS be more appropriate, since the mobile node is > interested in the router function? Perhaps the NA messages are typically shorter than RA messages. Secondly, unreachability detection in general uses NS/NA rather than RS/RA, even if we are tracking a router. Of course, here we are going a bit beyond regular NUD, but still... > 12) Value judgement on security infrastructure > > In Section 14.2, pg. 130 contains a paragraph with a value judgement on whether security infrastructure might be deployable or not. > It is too early to tell whether this value judgement is correct and, in any event, it does not belong in this specification. The > infrastructureless approach can be motivated by the simple statement that deploying an IPsec security association between two > arbitrary node in the Internet in the absence of a global PKI is a hard problem, and so a solution that does not require such was > developed in the interests of maintaining the minimum requirements for deployable MIPv6. Whether or not an infrastructure based > solution can be developed for some subproblem is an open question. Yes. > 13) References > > The nonnormative references should be removed or converted into normative references. Hmm... why? Other standards track RFCs appear to have normative and non-normative references, see for instance the SIP, RFC 3261. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 05:57:23 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18013 for ; Tue, 9 Jul 2002 05:57:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25028; Tue, 9 Jul 2002 03:57:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13495; Tue, 9 Jul 2002 02:57:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699tRk7012767 for ; Tue, 9 Jul 2002 02:55:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g699tR5X012766 for mobile-ip-dist; Tue, 9 Jul 2002 02:55:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699tOk7012759 for ; Tue, 9 Jul 2002 02:55:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19851 for ; Tue, 9 Jul 2002 02:55:30 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16918 for ; Tue, 9 Jul 2002 03:55:28 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id DD4156A907; Tue, 9 Jul 2002 12:55:11 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A28C46A904; Tue, 9 Jul 2002 12:54:55 +0300 (EEST) Message-ID: <3D2AA7AA.7020800@kolumbus.fi> Date: Tue, 09 Jul 2002 12:06:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Miles Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <007e01c226c0$8de9eed0$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Kevin for your comments. I assigned issue #56 for this. Some discussion follows inline: > 1. There still appears to be a minor bug in the description > of how the DHAAD response is created. The addresses are > ordered by decreasing Preference, and if the sender is > the first in the list, its address should be omitted and > the recipient will assume that the sender is most > preferred. But there is also the provision for > truncating the response if it exceeds max MTU. So, for > example, if the sender is least preferred but its > address gets truncated because of MTU size constraints, > the recipient will incorrectly assume the sender to be > most preferred. Since all this is specified using SHOULD > and SHOULD NOT, an implementation can legitimately > achieve approximately the intended behaviour by not > doing what the I-D says, but the way it is currently > described is an invitation to error. An obvious fix is > to eliminate the 'bandwidth conservation' and explicitly > transmit all addresses that will fit in the response. I'm OK with this fix. > 2. In section 9.4.1, it says: "If the Home Registration (H) > bit is set in the Binding Update, the Binding Update is > processed according to the procedure specified in > Section 10.2; otherwise, it is processed according to > the procedure specified in Section 9.4.2." > Unfortunately, the context of this text implies that the > Return Routeability procedure can be used to secure a > Home Registration, which is not the case. Same problem > with the next bullet, too. Right. > 3. Sections 6.1.8 and 9.4.4 are inconsistent. The former > says a BA does not use a routing header. The latter > describes conditions under which it does. I'm confused because 6.1.8 does talk about the routing header. In any case, I'm suggesting we should delete the duplicate text from sections 6.1.x and refer to the right place in the rest of the draft for setting the addresses and headers. > 4. Section 10.3 says "If the home agent does not reject the > Binding Update as described above, then it MUST delete > any existing entry in its Binding Cache for this mobile > node, and proceed as follows." Should "any existing > entry" read "all existing entries"? I.e., what are the > semantics of the S bit in a deregistration? For example, > is it permissible to register a set of addresses using > S=0 and then individually deregister them with S=1? I believe S=0 in a registration will create separate entries, so you should be able to remove them individually. But the draft is quiet on what semantics S bit has on deregistration. My proposal is that it should have the same semantics, i.e. that you could also do a S=0 deregistration to remove all of your bindings. > Editorial: > > 5. The document still has a few instances of "Binding > Update option". Most, if not all, should read "Binding > Update" or "Binding Update message. Thanks. Fixed. > 6. Repeated text on p64: "Subsequent checks depend on the > particular Mobility Header message, as specified in > Sections 9.3 and 9.4. Subsequent checks depend on the > particular Mobility Header message." Fixed. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 06:55:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18014 for ; Tue, 9 Jul 2002 05:57:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25023; Tue, 9 Jul 2002 03:57:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23515; Tue, 9 Jul 2002 02:57:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699u1k7012787 for ; Tue, 9 Jul 2002 02:56:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g699u1N4012786 for mobile-ip-dist; Tue, 9 Jul 2002 02:56:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699tuk7012779 for ; Tue, 9 Jul 2002 02:55:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13147 for ; Tue, 9 Jul 2002 02:56:01 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13641 for ; Tue, 9 Jul 2002 03:55:21 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id BDEEA6A904; Tue, 9 Jul 2002 12:55:14 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D97406A901; Tue, 9 Jul 2002 12:54:54 +0300 (EEST) Message-ID: <3D2AA098.3000008@piuha.net> Date: Tue, 09 Jul 2002 11:36:40 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: "Hesham Soliman (EAB)" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 rev 18 - Editorial in chapter 8 References: <4DA6EA82906FD511BE2F00508BCF0538044F0821@Esealnt861.al.sw.ericsson.se> <008a01c22439$eee424a0$4f6015ac@T23KEMPF> <3D287DB9.9040107@kolumbus.fi> <00ab01c22696$eb515100$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Jari, > > Thanx for the clarification. > > I think the draft needs to be clearer about this. Perhaps it could be stated in the requirements section. Yes. In 8.1, I have made the following clarification: - The node MUST be able to validate a Home Address option received in any IPv6 packet as described in Section 9.2.2. => - The node MUST be able to process a Home Address option in any IPv6 packet, and validate the option using an IPsec SA, as described in Section 9.2.2. And then addded a new item in 8.2: - The node MUST be able validate a Home Address option using an existing Binding Cache entry, as described in Section 9.2.2. Does this work for everyone? I assigned issue #54 for this. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 13:57:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05202 for ; Tue, 9 Jul 2002 13:57:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01726; Tue, 9 Jul 2002 11:58:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05234; Tue, 9 Jul 2002 10:57:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69HuXk7013700 for ; Tue, 9 Jul 2002 10:56:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69HuXDq013699 for mobile-ip-dist; Tue, 9 Jul 2002 10:56:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69HuUk7013692 for ; Tue, 9 Jul 2002 10:56:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04585 for ; Tue, 9 Jul 2002 10:56:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00715 for ; Tue, 9 Jul 2002 11:56:35 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27859; Tue, 9 Jul 2002 10:56:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69HuXt05246; Tue, 9 Jul 2002 10:56:33 -0700 X-mProtect: <200207091756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3SlK1W; Tue, 09 Jul 2002 10:56:31 PDT Message-ID: <3D2B23CF.E4904F9B@iprg.nokia.com> Date: Tue, 09 Jul 2002 10:56:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Kevin Miles , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <007e01c226c0$8de9eed0$0401010a@emea.cisco.com> <3D2AA7AA.7020800@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > I believe S=0 in a registration will create separate entries, > so you should be able to remove them individually. But the draft > is quiet on what semantics S bit has on deregistration. My proposal > is that it should have the same semantics, i.e. that you could also > do a S=0 deregistration to remove all of your bindings. this is what is done in our implementation. when the HA receives a deregistration BU with S=0, it removes all bindings for the corresponding MN. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 14:33:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06605 for ; Tue, 9 Jul 2002 14:33:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03655; Tue, 9 Jul 2002 12:33:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20741; Tue, 9 Jul 2002 11:33:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69IWGk7013885 for ; Tue, 9 Jul 2002 11:32:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69IWGx2013884 for mobile-ip-dist; Tue, 9 Jul 2002 11:32:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69IWDk7013877 for ; Tue, 9 Jul 2002 11:32:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16003 for ; Tue, 9 Jul 2002 11:32:20 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05666 for ; Tue, 9 Jul 2002 11:32:19 -0700 (PDT) Message-ID: <014d01c22776$b9efcd40$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2AB324.8080303@kolumbus.fi> Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt Date: Tue, 9 Jul 2002 11:30:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, Just a few replies. > Yes... perhaps we should go through the spec with this particular aspect in mind. Do you > have any particular complaints about sections that don't do well in this aspect? > I've marked up the spec with some particular cases, and I have some others I could cite, but I think I would rather not take up list bandwidth on it. I've cited the ones that I felt were most in need of attention in the original note, and can send others to you offline if there will be a technical editing effort. > > Appendix A is, I believe, inline with the textual descriptions earlier. The question is if people > feel that a relatively short description of states helps them understand what the protocol does, > or if they will be reading only the text. How does the list feel about this? I'm ready to > remove appendix A or make it part of earlier sections. > I feel comfortable with the state machine descriptions, but I think this is a question that implementors should answer. > DNS SRV records might work, but I'm uncertain about DHCP. Wouldn't DHCP be deployed locally, in the visited domain? > This would imply some relationship between the visited and home domains which we may not always want. > Like I said, I don't think now is the time to get into a discussion about what exactly these protocols could be. In the end, we may actually come up with justification for inventing custom service discovery and/or address configuration protocols for Mobile IP. I do think, however, these protocols are seperable from the basic routing change protocol, and therefore could easily be treated in a separate document, thus reducing the bulk of the basic spec. > Yes.. we debated about this a while ago. I wonder if the current text is perhaps sufficient? > It does say after the recommendations that the limits MUST be configurable. Or perhaps you > are suggesting to turn it off completely. Yes, that capabability would be useful on some link > types. > It could say "and periodic advertisement MAY be turned off completely if desired if the network or mobile node supports solicited or unsolicited unicast RAs upon detection of handover" or something like that. > Perhaps the NA messages are typically shorter than RA messages. Secondly, unreachability detection > in general uses NS/NA rather than RS/RA, even if we are tracking a router. Of course, here we are > going a bit beyond regular NUD, but still... > OK. > Hmm... why? Other standards track RFCs appear to have normative and non-normative references, > see for instance the SIP, RFC 3261. > OK, I wasn't aware of the precedent. This must be new, the RFC editor never allowed nonnormative references before. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 14:34:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06672 for ; Tue, 9 Jul 2002 14:34:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04841; Tue, 9 Jul 2002 12:35:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17341; Tue, 9 Jul 2002 11:35:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69IYAk7013923 for ; Tue, 9 Jul 2002 11:34:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69IYAlk013922 for mobile-ip-dist; Tue, 9 Jul 2002 11:34:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69IY7k7013912 for ; Tue, 9 Jul 2002 11:34:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20994 for ; Tue, 9 Jul 2002 11:34:13 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04020 for ; Tue, 9 Jul 2002 12:34:12 -0600 (MDT) Message-ID: <016301c22776$ffa31fe0$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] BAR BOF to discuss alternate BU security mechanisms Date: Tue, 9 Jul 2002 11:32:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've had a couple of positive responses on this, but one of the responders has a constraint of Sun. to Wed. So how does a night session on Mon. at 9 PM sound? Meet at the IETF registration desk. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 18:22:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20225 for ; Tue, 9 Jul 2002 18:22:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06924; Tue, 9 Jul 2002 16:23:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01556; Tue, 9 Jul 2002 15:23:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69MLYk7014439 for ; Tue, 9 Jul 2002 15:21:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69MLYDR014438 for mobile-ip-dist; Tue, 9 Jul 2002 15:21:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69MLVk7014431 for ; Tue, 9 Jul 2002 15:21:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06672 for ; Tue, 9 Jul 2002 15:21:37 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28622 for ; Tue, 9 Jul 2002 15:21:33 -0700 (PDT) Message-ID: <02b501c22796$c20aa390$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Re: BAR BOF to discuss alternate security algorithms Date: Tue, 9 Jul 2002 15:19:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Monday is the MIP group meeting, so we would need to move the meeting to after that. How about 22:00 (10 PM) on Monday, right after the MIP meeting? We can meet in the MIP meeting room and proceed from there. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 9 20:02:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22299 for ; Tue, 9 Jul 2002 20:02:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14398; Tue, 9 Jul 2002 17:02:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26086; Tue, 9 Jul 2002 17:02:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A017k7014664 for ; Tue, 9 Jul 2002 17:01:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6A017Sq014663 for mobile-ip-dist; Tue, 9 Jul 2002 17:01:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A014k7014656 for ; Tue, 9 Jul 2002 17:01:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17774 for ; Tue, 9 Jul 2002 17:01:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19913 for ; Tue, 9 Jul 2002 17:01:11 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA18766; Tue, 9 Jul 2002 17:01:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6A01As30744; Tue, 9 Jul 2002 17:01:10 -0700 X-mProtect: <200207100001> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMgOirI; Tue, 09 Jul 2002 17:01:08 PDT Message-ID: <3D2B7945.BBC13D09@iprg.nokia.com> Date: Tue, 09 Jul 2002 17:01:09 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > 4) Alternate Care of Address? > > Throughout the spec, there are occasional references to this, but I was unable to pin down exactly why this was there, and how it > might be used by the HA. In Seamoby, there have been some proposals to use it for hosts that are in dormant mode, but I really > couldn't tell whether it could be used from this spec. I think that a section should clearly explain why this was included in the > spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped. I dont know exactly why it was introduced (was done a long time ago). the general idea is that it is used when an MN wants to bind a HoA to CoA, but cant use the CoA as its source address (yet). I know this sounds a bit vague. there is atleast one concrete use of AltCoA option. it has to be there if the home registration BU is protected by ESP. thats the only way the CoA can be protected if ESP is used. if AH or Binding Authorization Data (Section 6.2.7) is used to protect the BU, then the CoA as the IPv6 source address is protected automatically. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 11:07:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05954 for ; Wed, 10 Jul 2002 11:07:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02565; Wed, 10 Jul 2002 08:07:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02308; Wed, 10 Jul 2002 08:06:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AF5pk7015822 for ; Wed, 10 Jul 2002 08:05:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AF5peO015821 for mobile-ip-dist; Wed, 10 Jul 2002 08:05:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AF5lk7015814 for ; Wed, 10 Jul 2002 08:05:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25134 for ; Wed, 10 Jul 2002 08:05:54 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24644 for ; Wed, 10 Jul 2002 08:05:53 -0700 (PDT) Received: from kmilesw2k (lon-sto4-lan-vlan133-dhcp22.cisco.com [144.254.108.89]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA15842; Wed, 10 Jul 2002 16:05:38 +0100 (BST) From: "Kevin Miles" To: "'Vijay Devarapalli'" , "'Jari Arkko'" Cc: Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Wed, 10 Jul 2002 16:05:37 +0100 Message-ID: <00b001c22823$40241c70$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3D2B23CF.E4904F9B@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Jari Arkko wrote: > > > > > I believe S=0 in a registration will create separate entries, > > so you should be able to remove them individually. But the draft > > is quiet on what semantics S bit has on deregistration. My proposal > > is that it should have the same semantics, i.e. that you could also > > do a S=0 deregistration to remove all of your bindings. > > this is what is done in our implementation. when the HA receives > a deregistration BU with S=0, it removes all bindings for the > corresponding MN. > I agree that maintaining consistent semantics for S is most appropriate. So, at the risk of stating the obvious, the intended behaviour is:- S=0 achieves the same effect as a set of individual BUs with S=1, one for each of the MN's home addresses. Each resulting BCE is then operated entirely independently (own tunnel, with own SAs if necessary), except for subsequent BUs in which S=0. Given that related BCEs may have been independently created with S=1, an HA receiving a BU with S=0 (for update or deregistration) decides which existing BCEs it applies to by matching IIDs alone. (I.e., it doesn't matter if some BCEs have different CoAs, etc.) Right? Kevin. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 11:31:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07124 for ; Wed, 10 Jul 2002 11:31:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18605; Wed, 10 Jul 2002 09:32:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03381; Wed, 10 Jul 2002 08:32:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFVEk7015979 for ; Wed, 10 Jul 2002 08:31:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AFVEkA015978 for mobile-ip-dist; Wed, 10 Jul 2002 08:31:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFVAk7015971 for ; Wed, 10 Jul 2002 08:31:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18173 for ; Wed, 10 Jul 2002 08:31:17 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17700 for ; Wed, 10 Jul 2002 09:31:17 -0600 (MDT) Message-ID: <001301c22826$9b244930$4f6015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" Cc: References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt Date: Wed, 10 Jul 2002 08:29:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I dont know exactly why it was introduced (was done a long time ago). > the general idea is that it is used when an MN wants to bind a HoA to > CoA, but cant use the CoA as its source address (yet). I know this > sounds a bit vague. > It does sound a bit vague. I think there needs to be some stronger motivation, and a section that clearly specifies how the AltCoA is used. Below sounds like a start on this. > there is atleast one concrete use of AltCoA option. it has to be there > if the home registration BU is protected by ESP. thats the only way > the CoA can be protected if ESP is used. if AH or Binding Authorization > Data (Section 6.2.7) is used to protect the BU, then the CoA as the > IPv6 source address is protected automatically. > So it sounds like the MN sends the BU to the HA with ESP and with the AltCoA as the source address on the packet, is that right? I'm a little confused on this. I thought the security association with the HA was based on the home address so a packet protected by ESP could be sent through a reverse tunnel. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 13:26:35 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12159 for ; Wed, 10 Jul 2002 13:26:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02710; Wed, 10 Jul 2002 11:27:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24353; Wed, 10 Jul 2002 10:27:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AHQ1k7016284 for ; Wed, 10 Jul 2002 10:26:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AHQ1VN016283 for mobile-ip-dist; Wed, 10 Jul 2002 10:26:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AHPvk7016276 for ; Wed, 10 Jul 2002 10:25:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23890 for ; Wed, 10 Jul 2002 10:26:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01431 for ; Wed, 10 Jul 2002 11:26:05 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA26359; Wed, 10 Jul 2002 10:26:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AHQ3120775; Wed, 10 Jul 2002 10:26:03 -0700 X-mProtect: <200207101726> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWerL7A; Wed, 10 Jul 2002 10:26:01 PDT Message-ID: <3D2C6E2A.B1980D2C@iprg.nokia.com> Date: Wed, 10 Jul 2002 10:26:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jim, James Kempf wrote: > So it sounds like the MN sends the BU to the HA with ESP and with the AltCoA as the source address on the packet, is that > right? Home Registration BU, if protected by ESP, is protected in transport mode. heres how the packet will look like IPv6 hdr (CoA, HA) Dst opt HoA ESP hdr Mobility Hdr Binding Update AltCoA option here the IPv6 src and AltCoA contain the same address. without the AltCoA option, the care-of address cannot be protected by the ESP hdr. > I'm a little confused on this. I thought the security association with the HA was based on the home address so a packet > protected by ESP could be sent through a reverse tunnel. the security association with the HA is beased on the home address, thats why you include a HAO. the reverse tunnel is used to send packets to CNs through the HA. not to the HA itself. if you want to send a home registration BU in ESP tunnel mode IPv6 hdr (CoA, HA) Dst opt HoA ESP hdr IPv6 hdr (HoA, HA) Mobility Hdr Binding Update AltCoA option this packet has two disadvantages. 1) more bytes 2) by the time the inner packet is processed, the CoA is lost. the outer header is no longer available. again you need an AltCoA option. hope I am not missing anything. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 14:05:49 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13538 for ; Wed, 10 Jul 2002 14:05:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18434; Wed, 10 Jul 2002 11:06:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05293; Wed, 10 Jul 2002 11:05:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI4Wk7016515 for ; Wed, 10 Jul 2002 11:04:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AI4Wdu016514 for mobile-ip-dist; Wed, 10 Jul 2002 11:04:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI4Uk7016507 for ; Wed, 10 Jul 2002 11:04:30 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00215 for ; Wed, 10 Jul 2002 14:04:36 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g6AI4hXA014549 for ; Wed, 10 Jul 2002 14:04:43 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g6AI4hb6014548 for mobile-ip@sunroof.eng.sun.com; Wed, 10 Jul 2002 14:04:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69IsKk7014158 for ; Tue, 9 Jul 2002 11:54:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27312 for ; Tue, 9 Jul 2002 11:54:27 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17402 for ; Tue, 9 Jul 2002 11:54:27 -0700 (PDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsNC20382 for ; Tue, 9 Jul 2002 14:54:24 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g69IsML38088 for ; Tue, 9 Jul 2002 14:54:22 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA45734 for mobile-ip@sunroof.eng.sun.com; Tue, 9 Jul 2002 14:54:15 -0400 Date: Tue, 9 Jul 2002 14:54:15 -0400 From: Alaa Youssef Message-Id: <200207091854.OAA45734@scarpia.watson.ibm.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IEEE Infocom 2003 Final Call For Papers Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* FINAL CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Tutorial proposals due September 30, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 14:06:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13582 for ; Wed, 10 Jul 2002 14:06:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26964; Wed, 10 Jul 2002 12:07:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29186; Wed, 10 Jul 2002 11:07:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI6Bk7016551 for ; Wed, 10 Jul 2002 11:06:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AI6AdK016550 for mobile-ip-dist; Wed, 10 Jul 2002 11:06:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI68k7016540 for ; Wed, 10 Jul 2002 11:06:09 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00707 for ; Wed, 10 Jul 2002 14:06:15 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g6AI6MXA014554 for ; Wed, 10 Jul 2002 14:06:22 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g6AI6M5W014553 for mobile-ip@sunroof.eng.sun.com; Wed, 10 Jul 2002 14:06:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A6HGk7015107; Tue, 9 Jul 2002 23:17:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07630; Tue, 9 Jul 2002 23:17:23 -0700 (PDT) Received: from nero.informatik.uni-wuerzburg.de (wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18540; Wed, 10 Jul 2002 00:17:21 -0600 (MDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g6A6CFs20010; Wed, 10 Jul 2002 08:12:15 +0200 Message-ID: <000c01c227d8$fb85e2f0$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: Subject: [mobile-ip] ITC Specialist Seminar 2002 Date: Wed, 10 Jul 2002 08:13:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C227E9.B5048230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C227E9.B5048230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES =20 =20 FINAL CALL FOR PARTICIPATION: =20 Dear colleagues, =20 we'd like to announce that the registration for the upcoming=20 15th ITC Specialist Seminar: "Internet Traffic Engineering=20 and Traffic Management (IP2002)" remains open until=20 18 July 2002. =20 http://www.itcspecialistseminar.com/=20 Venue: University of Wuerzburg, Department of Distributed Systems,=20 Wuerzburg, Germany. Date: July 22-24 2002. =20 A registration form for the IP2002 workshop is available at:=20 =20 http://www.itcspecialistseminar.com/RegistrationForm.pdf =20 =20 We are looking forward to welcome you in Wuerzburg. Best Regards, Phuoc Tran-Gia James Roberts Kurt Tutschku Klaus Heck, your IP2002 Organizing Team =20 ------=_NextPart_000_0009_01C227E9.B5048230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

PLEASE ACCEPT OUR=20 APOLOGIES FOR MULTIPLE COPIES

 

 

FINAL CALL FOR=20 PARTICIPATION:

 

Dear=20 colleagues,

 

we'd like to=20 announce that the registration for the upcoming=20

15th ITC=20 Specialist Seminar: "Internet Traffic Engineering=20

and Traffic=20 Management (IP2002)" remains open until =

18 July=20 2002.

 

http://www.itcspecialistsem= inar.com/=20

 

Venue:      University of = Wuerzburg,=20 Department of Distributed Systems,

Wuerzburg, Germany.

Date:       July 22-24=20 2002.

 

A = registration=20 form for the IP2002 workshop is available at:=20

 

http://www.itcspecialistseminar.com/RegistrationForm.pdf

 

 

We are looking=20 forward to welcome you in Wuerzburg.

Best=20 Regards,

Phuoc=20 Tran-Gia

James=20 Roberts

Kurt=20 Tutschku

Klaus Heck,=20 your IP2002 Organizing Team

 

------=_NextPart_000_0009_01C227E9.B5048230-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 14:08:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13664 for ; Wed, 10 Jul 2002 14:08:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27519; Wed, 10 Jul 2002 12:09:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12614; Wed, 10 Jul 2002 11:09:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI7Xk7016666 for ; Wed, 10 Jul 2002 11:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AI7W7W016665 for mobile-ip-dist; Wed, 10 Jul 2002 11:07:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AI7Sk7016646 for ; Wed, 10 Jul 2002 11:07:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29263 for ; Wed, 10 Jul 2002 11:07:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20997 for ; Wed, 10 Jul 2002 12:07:33 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28423; Wed, 10 Jul 2002 11:07:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AI7WQ27301; Wed, 10 Jul 2002 11:07:32 -0700 X-mProtect: <200207101807> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAMHVIg; Wed, 10 Jul 2002 11:07:29 PDT Message-ID: <3D2C77E2.392BF598@iprg.nokia.com> Date: Wed, 10 Jul 2002 11:07:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Miles CC: "'Jari Arkko'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <00b001c22823$40241c70$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > I agree that maintaining consistent semantics for S is most appropriate. > > So, at the risk of stating the obvious, the intended behaviour is:- > > S=0 achieves the same effect as a set of individual BUs with S=1, one for each > of the MN's home addresses. Each resulting BCE is then operated entirely > independently (own tunnel, with own SAs if necessary), except for subsequent BUs > in which S=0. Given that related BCEs may have been independently created with > S=1, an HA receiving a BU with S=0 (for update or deregistration) decides which > existing BCEs it applies to by matching IIDs alone. if BCEs are created independently, there will be corresponding independent entries in the MN's binding update list. > (I.e., it doesn't matter if > some BCEs have different CoAs, etc.) why would the CoA be different? the MN must have updated all bindings when it changed its CoA. anyway, in our implementation, the binding cache entries created for a BU with S=0 are linked. there are pointers from the BCE created for the HoA in the BU. I dont have to search all BCEs with matching IIDs. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 17:41:46 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20814 for ; Wed, 10 Jul 2002 17:41:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23169; Wed, 10 Jul 2002 15:42:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07492; Wed, 10 Jul 2002 14:42:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ALf9k7017534 for ; Wed, 10 Jul 2002 14:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ALf9JM017533 for mobile-ip-dist; Wed, 10 Jul 2002 14:41:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ALf6k7017526 for ; Wed, 10 Jul 2002 14:41:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05235 for ; Wed, 10 Jul 2002 14:41:13 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27867 for ; Wed, 10 Jul 2002 15:41:13 -0600 (MDT) Received: from kmilesw2k (ams-clip-vpn-dhcp158.cisco.com [10.50.0.157]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id WAA28111; Wed, 10 Jul 2002 22:40:58 +0100 (BST) From: "Kevin Miles" To: "'Vijay Devarapalli'" Cc: "'Jari Arkko'" , Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Wed, 10 Jul 2002 22:40:55 +0100 Message-ID: <00b501c2285a$7962f010$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3D2C77E2.392BF598@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > anyway, in our implementation, the binding cache entries created > for a BU with S=0 are linked. there are pointers from the BCE > created for the HoA in the BU. I dont have to search all BCEs > with matching IIDs. > So if the BCEs were created independently with S=1, presumably they would not be linked. In which case, a single deregistration BU with S=0 could not be used to deregister them. Correct? This is what I'm trying to get clarified. Is it permissible, under any circumstances, for the MN to change the value of the S bit in successive BUs that relate to the same binding(s)? I cannot see anything in the draft that prohibits it. Currently, it would appear that an MN could use multiple BUs with S=1 to selectively register certain addresses and then deregister them all with a single BU with S=0. As Jari observed, the draft is completely silent on the use of the S bit in deregistrations and, for that matter, BUs that update an existing registration. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 18:25:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22128 for ; Wed, 10 Jul 2002 18:25:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05069; Wed, 10 Jul 2002 16:25:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23383; Wed, 10 Jul 2002 15:25:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AMOSk7017755 for ; Wed, 10 Jul 2002 15:24:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AMORE6017754 for mobile-ip-dist; Wed, 10 Jul 2002 15:24:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AMOOk7017747 for ; Wed, 10 Jul 2002 15:24:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25777 for ; Wed, 10 Jul 2002 15:24:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14644 for ; Wed, 10 Jul 2002 16:24:32 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13461; Wed, 10 Jul 2002 15:24:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AMOVH07468; Wed, 10 Jul 2002 15:24:31 -0700 X-mProtect: <200207102224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd902oYb; Wed, 10 Jul 2002 15:24:28 PDT Message-ID: <3D2CB41C.E81CC05@iprg.nokia.com> Date: Wed, 10 Jul 2002 15:24:28 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Miles CC: "'Jari Arkko'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <00b501c2285a$7962f010$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > > Vijay Devarapalli wrote: > > > anyway, in our implementation, the binding cache entries created > > for a BU with S=0 are linked. there are pointers from the BCE > > created for the HoA in the BU. I dont have to search all BCEs > > with matching IIDs. > > > So if the BCEs were created independently with S=1, presumably they would not be > linked. In which case, a single deregistration BU with S=0 could not be used to > deregister them. Correct? right (in our implementation). > This is what I'm trying to get clarified. Is it permissible, under any > circumstances, for the MN to change the value of the S bit in successive BUs > that relate to the same binding(s)? I cannot see anything in the draft that > prohibits it. Currently, it would appear that an MN could use multiple BUs with IMO, it would be simpler if the draft prohibits it. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 19:38:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23392 for ; Wed, 10 Jul 2002 19:38:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25610; Wed, 10 Jul 2002 17:39:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25965; Wed, 10 Jul 2002 16:39:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ANbsk7017926 for ; Wed, 10 Jul 2002 16:37:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ANbsg3017925 for mobile-ip-dist; Wed, 10 Jul 2002 16:37:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ANbpk7017918 for ; Wed, 10 Jul 2002 16:37:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12874 for ; Wed, 10 Jul 2002 16:37:58 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25043 for ; Wed, 10 Jul 2002 17:37:57 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ANcSi03234 for ; Thu, 11 Jul 2002 02:38:28 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Jul 2002 02:37:56 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 02:37:54 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 18:37:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Fast Handovers for Mobile IPv6 Date: Wed, 10 Jul 2002 18:36:54 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440969A8@daebe007.NOE.Nokia.com> Thread-Topic: Fast Handovers for Mobile IPv6 Thread-Index: AcIoaqvqvrrtATi+SheIt+qiSHHpjA== To: X-OriginalArrivalTime: 10 Jul 2002 23:37:52.0874 (UTC) FILETIME=[CF4364A0:01C2286A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6ANbpk7017919 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, We have some unresolved issues with the fast handover draft version 05 that was recently announced. Changes to the draft have yet to be run by the WG and hence at this time we would like to continue the discussion at the WG meeting in IETF54 based on draft version 04 which is still the WG I-D. Please treat draft version 04 as the WG consensus document and the basis for any discussion at this time. Rajeev Koodli (Draft editor) will be running the proposed changes and issues by the WG to obtain consensus before issuing the next version of the draft (i.e 05). -Chairs From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 10 21:44:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26036 for ; Wed, 10 Jul 2002 21:44:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06043; Wed, 10 Jul 2002 19:44:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09185; Wed, 10 Jul 2002 18:44:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B1hBk7018254 for ; Wed, 10 Jul 2002 18:43:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B1hBfa018253 for mobile-ip-dist; Wed, 10 Jul 2002 18:43:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B1h8k7018246 for ; Wed, 10 Jul 2002 18:43:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24778 for ; Wed, 10 Jul 2002 18:43:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00481 for ; Wed, 10 Jul 2002 19:43:14 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA23459 for ; Wed, 10 Jul 2002 18:43:13 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6B1hCY18496 for ; Wed, 10 Jul 2002 18:43:12 -0700 X-mProtect: <200207110143> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdu307S4; Wed, 10 Jul 2002 18:43:09 PDT Message-ID: <3D2CE2AE.715A0F9F@iprg.nokia.com> Date: Wed, 10 Jul 2002 18:43:10 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fast Handover draft: proposed revisions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, here is a list of proposed changes to the fast handover draft v04, meant to initiate discussion and arrive at consensus. Please comment. Thanks, -Rajeev the proposed revisions: 1. Always allow the MN to use its Previous CoA during handover to both send and receive IP packets Change from v04: In v04, PCoA was used only when it was not acceptable to use a New CoA. New Implications: NAR must always have a host route entry for PCoA (until the MN begins to use NCoA). This is in addition to the proxy neighbor cache entry that NAR creates when NCoA is acceptable to use. Result: The MN is able to send and receive IP packets while it establishes itself as a Mobile IP end-point. 2. Allow a MN to send FBU to Previous AR to tunnel packets arriving at PCoA to NAR. Change from v04: In v04, only an FBU sent with PCoA as source IP address would cause packets to be tunneled to NAR. New implications: a) If NAR has not received a HI, it SHOULD forward FBU to PAR. b) If PAR has not received PrRtSol, but receives an FBU, it SHOULD send a HI to NAR Result: the protocol can be initiated after the MN establishes connectivity with NAR. 3. Allow L2 triggers to used Change from v04: Define generic, L2 independent constructs (to be done). New implications: define exact trigger formats elsewhere. The handover messages should be able to operate transparently. Introduce a Handover Solicit from NAR (when a trigger indicates that the MN is attached to it) to PAR to request a HI ? And, here are the new features - the MN should be able to maintain uninterrupted IP connectivity (i.e., is able to send and receive IP packets) for its existing sessions while it expeditiously establishes itself as a Mobile IP end-point. - during the Binding Update procedure, the MN uses its PCoA to send and receive IP packets - the protocol can be initiated when the MN is on the old link (via RtSolPr/PrRtAdv) or on the new link (via FBU) From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 04:39:05 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13318 for ; Thu, 11 Jul 2002 04:39:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27144; Thu, 11 Jul 2002 01:39:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17629; Thu, 11 Jul 2002 01:39:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8cAk7018905 for ; Thu, 11 Jul 2002 01:38:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B8cAOH018904 for mobile-ip-dist; Thu, 11 Jul 2002 01:38:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8c7k7018897 for ; Thu, 11 Jul 2002 01:38:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02338 for ; Thu, 11 Jul 2002 01:38:14 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10520 for ; Thu, 11 Jul 2002 01:38:13 -0700 (PDT) Received: from kmilesw2k (ams-clip-vpn-dhcp4110.cisco.com [10.50.16.13]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id JAA10364; Thu, 11 Jul 2002 09:37:58 +0100 (BST) From: "Kevin Miles" To: "'Vijay Devarapalli'" Cc: "'Jari Arkko'" , Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Thu, 11 Jul 2002 09:37:55 +0100 Message-ID: <00b801c228b6$4118d2e0$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3D2CB41C.E81CC05@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Kevin Miles wrote: > > > > > This is what I'm trying to get clarified. Is it > permissible, under any > > circumstances, for the MN to change the value of the S bit > in successive BUs > > that relate to the same binding(s)? I cannot see anything > in the draft that > > prohibits it. Currently, it would appear that an MN could > use multiple BUs with > > IMO, it would be simpler if the draft prohibits it. > Works for me. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 12:55:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25356 for ; Thu, 11 Jul 2002 12:55:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05387; Thu, 11 Jul 2002 10:55:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26162; Thu, 11 Jul 2002 09:55:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BGsNk7019741 for ; Thu, 11 Jul 2002 09:54:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BGsNg5019740 for mobile-ip-dist; Thu, 11 Jul 2002 09:54:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BGsKk7019733 for ; Thu, 11 Jul 2002 09:54:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25685 for ; Thu, 11 Jul 2002 09:54:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17112 for ; Thu, 11 Jul 2002 10:54:26 -0600 (MDT) Message-ID: <011101c228fb$61f84c80$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 09:52:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, We implemented draft 04 and we feel that it was basically sound except it needed some editorial tightening. Therefore, the rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back to previous drafts, say 01, where many details were not as tightly specified as draft 04. In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but I believe we had WG concensus to put this into the draft and I would like to see them back. However, we have found that implementation is aided by having the specification be very precise about when L2 information is needed and what information is needed. The FMIPv4 draft has this information in it, as does draft 04, and it has been very useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain sufficiently detailed information, especially for Postregv6 but also for Preregv6. Many cases that will be common for particular link layers like standard 802.11 or cellular are relegated to Section 4.1, the Error Cases. The detailed information on the relationship between L2 events and FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another. Remarks on you comments below. > 1. Always allow the MN to use its Previous CoA during > handover to both send and receive IP packets > > Change from v04: In v04, PCoA was used only when > it was not acceptable to use a New CoA. > > New Implications: NAR must always have a host route > entry for PCoA (until the MN begins to use NCoA). This > is in addition to the proxy neighbor cache entry that NAR > creates when NCoA is acceptable to use. > > Result: The MN is able to send and receive IP packets > while it establishes itself as a Mobile IP end-point. > OK. > > 2. Allow a MN to send FBU to Previous AR to tunnel > packets arriving at PCoA to NAR. > > Change from v04: In v04, only an FBU sent with PCoA as > source IP address would cause packets to be tunneled to > NAR. > > New implications: > a) If NAR has not received a HI, it SHOULD > forward FBU to PAR. > b) If PAR has not received PrRtSol, but receives an FBU, > it SHOULD send a HI to NAR > > Result: the protocol can be initiated after the MN establishes > connectivity with NAR. > OK. But it must also be possible to do this in the absence of any prehandover signaling, for those link layers that specify no standard prehandover L2 triggers. The current draft treats this as an error case, and it would not be clear to an implementor on such a link layer that this would be possible and correct. > 3. Allow L2 triggers to used > > Change from v04: Define generic, L2 independent constructs > (to be done). > > New implications: define exact trigger formats elsewhere. > The handover messages should be able to operate transparently. > Introduce a Handover Solicit from NAR (when a trigger indicates > that the MN is attached to it) to PAR to request a HI ? > The information about when the L2 information is used and where needs to be specified somewhere. This draft is not sufficiently precise about that. > And, here are the new features > > - the MN should be able to maintain uninterrupted IP connectivity > (i.e., is able to send and receive IP packets) for its existing > sessions while it expeditiously establishes itself as a Mobile IP > end-point. Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused by the mobile node changing links. > - during the Binding Update procedure, the MN uses its PCoA > to send and receive IP packets Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled. > - the protocol can be initiated when the MN is on the old link > (via RtSolPr/PrRtAdv) or on the new link (via FBU) > Addition of initiation on the new link is a plus, but it is not clear from this description that this is allowed in the general case. It is couched as an error case. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 13:37:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27109 for ; Thu, 11 Jul 2002 13:37:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00171; Thu, 11 Jul 2002 11:38:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21695; Thu, 11 Jul 2002 10:37:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHaok7019900 for ; Thu, 11 Jul 2002 10:36:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BHaovr019899 for mobile-ip-dist; Thu, 11 Jul 2002 10:36:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHalk7019892 for ; Thu, 11 Jul 2002 10:36:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21161 for ; Thu, 11 Jul 2002 10:36:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08029 for ; Thu, 11 Jul 2002 11:36:52 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28548; Thu, 11 Jul 2002 10:36:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BHapV10471; Thu, 11 Jul 2002 10:36:51 -0700 X-mProtect: <200207111736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeI7grv; Thu, 11 Jul 2002 10:36:49 PDT Message-ID: <3D2DC231.A45F988F@iprg.nokia.com> Date: Thu, 11 Jul 2002 10:36:49 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > In particular, Section 3.3 and 3.4 were dropped from the draft. These are > critical for describing how Postregv6 (aka BETH) can be implemented. It is possible to imagine a post-registration scheme for handovers that does not use BETH. For instance, one could send a Binding Update to the previous access router, as is specified in the base draft. > If there is some problem with too much reference to L2 triggers, > we can discuss sanitizing them, but I believe we had WG concensus > to put this into the draft and I would like to see them back. I think we should characterize the layer-2 triggers by what action they trigger (e.g., "Handover Solicitation Trigger", or "Handover Initiate Trigger"). Then, we can point out in the draft the actions that are taken when a layer-2 trigger happens. This approach has the following benefits: 1) The protocol actions that are specified are layer-2 actions. 2) The layer 2 triggers can arise from whatever layer 2 satisfies the appropriate timing conditions 3) We can identify what layer-3 protocol actions are displaced by the availability of the layer-2 triggers. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 13:40:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27296 for ; Thu, 11 Jul 2002 13:40:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26421; Thu, 11 Jul 2002 11:41:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14600; Thu, 11 Jul 2002 10:41:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHeRk7020009 for ; Thu, 11 Jul 2002 10:40:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BHeRb6020008 for mobile-ip-dist; Thu, 11 Jul 2002 10:40:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHeOk7020001 for ; Thu, 11 Jul 2002 10:40:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14299 for ; Thu, 11 Jul 2002 10:40:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09829 for ; Thu, 11 Jul 2002 11:40:28 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28842; Thu, 11 Jul 2002 10:40:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BHeRo16192; Thu, 11 Jul 2002 10:40:27 -0700 X-mProtect: <200207111740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJaMSca; Thu, 11 Jul 2002 10:40:24 PDT Message-ID: <3D2DC308.1B5D3C4D@iprg.nokia.com> Date: Thu, 11 Jul 2002 10:40:24 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: MISTAKE! Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I made a drastic typo in my previous note! "Charles E. Perkins" wrote: .............. > I think we should characterize the layer-2 triggers by what action > they trigger (e.g., "Handover Solicitation Trigger", or > "Handover Initiate Trigger"). Then, we can point out in the > draft the actions that are taken when a layer-2 trigger happens. > This approach has the following benefits: > > 1) The protocol actions that are specified are layer-2 actions. I meant, "layer-3" actions!!! > 2) The layer 2 triggers can arise from whatever layer 2 satisfies > the appropriate timing conditions > 3) We can identify what layer-3 protocol actions are displaced by > the availability of the layer-2 triggers. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 13:44:01 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27484 for ; Thu, 11 Jul 2002 13:44:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28510; Thu, 11 Jul 2002 11:44:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24668; Thu, 11 Jul 2002 10:44:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHhik7020147 for ; Thu, 11 Jul 2002 10:43:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BHhi6r020146 for mobile-ip-dist; Thu, 11 Jul 2002 10:43:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BHhek7020139 for ; Thu, 11 Jul 2002 10:43:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15771 for ; Thu, 11 Jul 2002 10:43:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12242 for ; Thu, 11 Jul 2002 11:43:46 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29091; Thu, 11 Jul 2002 10:43:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BHhj823097; Thu, 11 Jul 2002 10:43:45 -0700 X-mProtect: <200207111743> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqczsMl; Thu, 11 Jul 2002 10:43:43 PDT Message-ID: <3D2DC3CF.DF289243@iprg.nokia.com> Date: Thu, 11 Jul 2002 10:43:43 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > Rajeev, > > We implemented draft 04 and we feel that it was basically sound except it needed some editorial tightening. Therefore, the > rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back to > previous drafts, say 01, where many details were not as tightly specified as draft 04. > You didn't exactly say what _proposed_ change is drastic. I have itemized the changes below under issues. Please comment on them. > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can > be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but Ibelieve > we had WG concensus to put this into the draft and I would like to see them back. > Ok. Let's discuss how to accommodate L2 triggers _without_ normative dependency on all link types that do and don't have such things. Do you have a proposal ? I would like to be able to define generic constructs that can serve as triggers for the protocol to be initiated. > > However, we have found that implementation is aided by having the specification be very precise about when L2 information is > needed and what information is needed. The FMIPv4 draft has this information in it, as does draft 04, and it has been very > useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain sufficiently detailed information, especially > for Postregv6 but also for Preregv6. Many cases that will be common for particular link layers like standard 802.11 or > cellular are relegated to Section 4.1, the Error Cases. The detailed information on the relationship between L2 events and > FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another. Let's seek the WG opinion on this. I think the base protocol should concern itself with IP messages while allowing any L2 feature to be used. The base protocol itself could define generic L2 constructs that can initiate the protocol operation. Others ? > > > > But it must also be possible to do this in the absence of any prehandover signaling, for those link layers that specify no > standard prehandover L2 triggers. The current draft treats this as an error case, and it would not be clear to an > implementor on such a link layer that this would be possible and correct. The reason for this is that proposed v05 is an adaptation of v04, in which a MN attempts to send an FBU prior to moving. Also, an implementor has to read the Error cases if he/she wishes to implement a robust protocol. If the WG agrees that the text should be under a different section, that's fine with me. > > > > 3. Allow L2 triggers to used > > > > Change from v04: Define generic, L2 independent constructs > > (to be done). > > > > New implications: define exact trigger formats elsewhere. > > The handover messages should be able to operate transparently. > > Introduce a Handover Solicit from NAR (when a trigger indicates > > that the MN is attached to it) to PAR to request a HI ? > > > > The information about when the L2 information is used and where needs to be specified somewhere. This draft is not > sufficiently precise about that. > Ok. What does the rest of the WG think about what L2 specific information should be in the draft ? > > > And, here are the new features > > > > - the MN should be able to maintain uninterrupted IP connectivity > > (i.e., is able to send and receive IP packets) for its existing > > sessions while it expeditiously establishes itself as a Mobile IP > > end-point. > > Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused > by the mobile node changing links. I don't see how "IP connectivity" translates to "IP is a connection oriented protocol". "Internet connectivity" does not translate to "Internet is connection oriented", does it ? Anyway, the parenthesis should help. What do others think ? > > > > - during the Binding Update procedure, the MN uses its PCoA > > to send and receive IP packets > > Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled. > I didn't see the connection between the two on this bullet.. > > > - the protocol can be initiated when the MN is on the old link > > (via RtSolPr/PrRtAdv) or on the new link (via FBU) > > > > Addition of initiation on the new link is a plus, but it is not clear from this description that this is allowed in the > general case. It is couched as an error case. > Ok. I can include text that allows specific usage. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 14:00:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28529 for ; Thu, 11 Jul 2002 14:00:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22584; Thu, 11 Jul 2002 12:01:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02459; Thu, 11 Jul 2002 11:01:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BI0Dk7020292 for ; Thu, 11 Jul 2002 11:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BI0DjN020291 for mobile-ip-dist; Thu, 11 Jul 2002 11:00:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BI09k7020284 for ; Thu, 11 Jul 2002 11:00:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01950 for ; Thu, 11 Jul 2002 11:00:15 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21562 for ; Thu, 11 Jul 2002 12:00:15 -0600 (MDT) Message-ID: <026901c22904$933fb8b0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 10:58:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, > It is possible to imagine a post-registration scheme for handovers > that does not use BETH. For instance, one could send a Binding Update > to the previous access router, as is specified in the base draft. > It is not only possible to imagine, but critical to have in the draft. Some link layers may not support access point or router triggers, nor any prehandover triggering at all, so the option must be there. The problem with draft 05 is that this case is not clearly specified as a valid option. It is only specified as an error case. It is not an option in the current WG draft, and that needs to be fixed. But, additionally, there must be protocol to support when triggers are available just on the access point or router, or when these triggers will provide the best performance. Our experience is that these typically get the best performance for low bandwidth, high latency links, such as are used for WAN cellular voice traffic (which is why we are interested). The draft 05 doesn't clearly specify these cases, whereas Sections 3.3 and 3.4 in the current WG draft do. > I think we should characterize the layer-2 triggers by what action > they trigger (e.g., "Handover Solicitation Trigger", or > "Handover Initiate Trigger"). Then, we can point out in the > draft the actions that are taken when a layer-2 trigger happens. > This approach has the following benefits: > > 1) The protocol actions that are specified are layer-2 actions. > 2) The layer 2 triggers can arise from whatever layer 2 satisfies > the appropriate timing conditions > 3) We can identify what layer-3 protocol actions are displaced by > the availability of the layer-2 triggers. > > In addition: 4) What information is provided by layer 2 to layer 3. We would need to discuss the actual wording but in principle this is what draft-manyfolks-l2-req-xx.txt is trying to do. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 14:06:34 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28737 for ; Thu, 11 Jul 2002 14:06:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20589; Thu, 11 Jul 2002 11:06:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24335; Thu, 11 Jul 2002 11:06:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BI5Qk7020417 for ; Thu, 11 Jul 2002 11:05:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BI5QX8020416 for mobile-ip-dist; Thu, 11 Jul 2002 11:05:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BI5Mk7020409 for ; Thu, 11 Jul 2002 11:05:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04378 for ; Thu, 11 Jul 2002 11:05:29 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19933 for ; Thu, 11 Jul 2002 11:05:28 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id OAA06365 for ; Thu, 11 Jul 2002 14:05:27 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt Date: Thu, 11 Jul 2002 11:07:26 -0700 Message-ID: <003e01c22905$d12826c0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00b801c228b6$4118d2e0$0401010a@emea.cisco.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1. The requirements for IPv6 routers and nodes would be better addressed in a separate ID. Similarly the security issues (i.e. BU authentication etc.) can also be better addressed in a separate ID. 2. A justification for "return routability" as the way it is done with HoTI/HoT and CoTI/CoT should be there. Also some details about why both HoTI and CoTI are needed, rather than just HoTI. 3. The various conceptual data structures in HA, MN, and CN would be better described through pictures. 4. The BCE of the CN is indexed by the home-address of the MN. The spec as it is now allows link-local addresses. So is there a possibility that two MN's may end up having the same l-l address in a CN? 5. In a hypothetical situation, a MN may visit a foreign network and acquires the same CoA address and the l-l HoA. Is it a possibility? Are CoA's always global? Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Kevin Miles Sent: Thursday, July 11, 2002 1:38 AM To: 'Vijay Devarapalli' Cc: 'Jari Arkko'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Vijay Devarapalli wrote: > > Kevin Miles wrote: > > > > > This is what I'm trying to get clarified. Is it > permissible, under any > > circumstances, for the MN to change the value of the S bit > in successive BUs > > that relate to the same binding(s)? I cannot see anything > in the draft that > > prohibits it. Currently, it would appear that an MN could > use multiple BUs with > > IMO, it would be simpler if the draft prohibits it. > Works for me. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 14:37:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00348 for ; Thu, 11 Jul 2002 14:37:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02673; Thu, 11 Jul 2002 12:38:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19900; Thu, 11 Jul 2002 11:38:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIbOk7020610 for ; Thu, 11 Jul 2002 11:37:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BIbOf9020609 for mobile-ip-dist; Thu, 11 Jul 2002 11:37:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIbLk7020602 for ; Thu, 11 Jul 2002 11:37:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19428 for ; Thu, 11 Jul 2002 11:37:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11977 for ; Thu, 11 Jul 2002 12:37:26 -0600 (MDT) Message-ID: <028301c22909$c4ea0230$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 11:35:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > You didn't exactly say what _proposed_ change is drastic. I have itemized the > changes below under issues. Please comment on them. > Below is an itemized list of what was removed in draft 05 which we found valuable in or *complete* implemetation of the current working group draft. In particular, there were a couple important issues that came up in WG discussion which we have spent lots of time and design cycles on trying to solve which have been ignored or fuzzed over in the current draft but were clearly if perhaps inaccurately specified in the previous draft: Draft 05 is missing Sections 3.4 and 3.5 as mentioned. All the protocol support for source and target triggered network handover has been removed from the message formats. Sections 3.1: This contains important details about the linking between particular kinds of L2 handover sequencing information and Preregv6 signaling. This was invaluable for our implementation. Section 3.5: Tunnel termination conditions. As I recall from the mailing list discussion a year and a half ago (we can check the archives) this was a hot issue when tunnel based handover was initially introduced into the draft. We've done lots of work in our implementation to make this possible, in order to conserve access router resources, and we have some suggested changes to the current WG draft on this. Draft 05 dodges the issue completely by specifying that the tunnel just times out. Section 4: Interoperability between Prereg and Postreg was another hot issue. We've done lots of work in our implementation on this, and we now have what we think is a workable interoperability solution. This was completely eliminated from draft 05. Section 6: Draft 05 removes important details about handling error cases, which are necessary for implementation. We have additional details that came out of our implemetation effort which are not included in draft 05. Draft 05 also makes cases that are normal for particular link layers into error cases. Section 8: Here is what draft 05 has to say about security (from Section 3, Paragraph 3): In order to ensure that the target of traffic redirection is not an unsuspecting innocent host, the PAR has to determine that the target address belongs to NAR, with which PAR has trust relationships. The PAR takes these precautions before it associates PCoA with another address. This is not sufficient to secure the protocol. Draft 05 Section 9, Security Considerations, is similarly vague about what must be done. Section 8 in the current WG draft isn't sufficiently precise either, but if draft 05 is supposed to move the current WG draft forward, then it should be more precise. Instead, draft 05 removes the framework about how to secure the protocol for network and mobile triggered handover. Prior to your issuing draft 05, I offered to send you a list of the changes we saw required in the current working group draft that came out of our implementation experince, but you recommended that I wait until after you had issued draft 05. I agreed thinking that minor editorial changes would be made in the current WG draft, as is fairly typical with WG drafts at this stage (two years on) of development, but I was suprised to find, when draft 05 came out, that it was a complete rewrite removing many important details (which I have outlined above) that were important to our implementation, such that it would be very difficult to map the changes we saw needed in the current working group draft to draft 05. Frankly, after two years of working on this protocol, I had thought the draft text had settled down to a state in which it was implementable with minor changes. Drastically rewriting the draft was unnecessary to introduce the material you describe in the list below. What do other people in the WG think (if anybody cares)? Do we need a complete rewrite of this draft? > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can > > be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but Ibelieve > > we had WG concensus to put this into the draft and I would like to see them back. > > > > Ok. Let's discuss how to accommodate L2 triggers _without_ normative dependency on > all link types that do and don't have such things. Do you have a proposal ? > I would like to be able to define generic constructs that can serve as triggers for the > protocol to be initiated. > It is not clear that there is WG concensus for removing L2 specific event descriptions from the draft. We have been discussing a L2 triggers draft, and we could put this information into the draft as we did for FMIPv4. I would like for us to start with the current WG draft and use that as a base for figuring out what should be done. Draft 05 has eliminated too many details to make it useful. Perhaps we can come up with something based on the current WG draft that describes how L2 events are utilized that is acceptable to you. > > Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused > > by the mobile node changing links. > > I don't see how "IP connectivity" translates to "IP is a connection oriented protocol". > "Internet connectivity" does not translate to "Internet is connection oriented", does it ? > Anyway, the parenthesis should help. What's happening is a change in routing. One needs to be precise about this. There is no connection-oriented context being set up. > > > - during the Binding Update procedure, the MN uses its PCoA > > > to send and receive IP packets > > > > Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled. > > > > I didn't see the connection between the two on this bullet.. > The text in draft 05 is not sufficiently clear or precise to present this as an option to an implementor. It looks like every handover must consist of Preregv6 signaling, even if that is impossible to do on a particular link layer. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 14:40:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00453 for ; Thu, 11 Jul 2002 14:40:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16034; Thu, 11 Jul 2002 12:41:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01193; Thu, 11 Jul 2002 11:41:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIdwk7020687 for ; Thu, 11 Jul 2002 11:39:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BIdwFs020683 for mobile-ip-dist; Thu, 11 Jul 2002 11:39:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIdrk7020667 for ; Thu, 11 Jul 2002 11:39:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20543 for ; Thu, 11 Jul 2002 11:40:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05138 for ; Thu, 11 Jul 2002 11:39:59 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA03358; Thu, 11 Jul 2002 11:39:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BIdw023956; Thu, 11 Jul 2002 11:39:58 -0700 X-mProtect: <200207111839> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdu3RV6X; Thu, 11 Jul 2002 11:38:47 PDT Message-ID: <3D2DD09A.318679D9@iprg.nokia.com> Date: Thu, 11 Jul 2002 11:38:18 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <026901c22904$933fb8b0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, newlines inserted for shorter linewidths, hope that's O.K. Plus I fixed my typo. James Kempf wrote: > But, additionally, there must be protocol to support when triggers > are available just on the access point or router, or when > these triggers will provide the best performance. Our experience > is that these typically get the best performance for low > bandwidth, high latency links, such as are used for WAN cellular > voice traffic (which is why we are interested). Not all protocol is layer-3 protocol. Often, layer-2 triggers trigger actions that are layer-2 actions, but have no layer-3 effects. This is true especially for some of the sorts of cellular handovers that I am familiar with, and I wouldn't expect much controversy. But we ought to be careful to use layer-3 controls just where they are needed. >> I think we should characterize the layer-2 triggers by what action >> they trigger (e.g., "Handover Solicitation Trigger", or >> "Handover Initiate Trigger"). Then, we can point out in the >> draft the actions that are taken when a layer-2 trigger happens. >> This approach has the following benefits: >> >> 1) The protocol actions that are specified are layer-3 actions. >> 2) The layer 2 triggers can arise from whatever layer 2 satisfies >> the appropriate timing conditions >> 3) We can identify what layer-3 protocol actions are displaced by >> the availability of the layer-2 triggers. >> >> > > In addition: > > 4) What information is provided by layer 2 to layer 3. Agreed. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 14:43:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00596 for ; Thu, 11 Jul 2002 14:43:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05681; Thu, 11 Jul 2002 12:44:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02337; Thu, 11 Jul 2002 11:43:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIgdk7020794 for ; Thu, 11 Jul 2002 11:42:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BIgdDX020793 for mobile-ip-dist; Thu, 11 Jul 2002 11:42:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BIgZk7020781 for ; Thu, 11 Jul 2002 11:42:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09718 for ; Thu, 11 Jul 2002 11:42:42 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01527 for ; Thu, 11 Jul 2002 12:42:42 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA23455 for ; Thu, 11 Jul 2002 11:42:38 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA09839 for ; Thu, 11 Jul 2002 11:42:49 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 11 Jul 2002 13:42:37 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 13:42:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev, Please find my inline comments. regards, ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, July 11, 2002 12:44 PM To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Hello Jim, James Kempf wrote: > Rajeev, > > We implemented draft 04 and we feel that it was basically sound except it needed some editorial tightening. Therefore, the > rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back to > previous drafts, say 01, where many details were not as tightly specified as draft 04. > You didn't exactly say what _proposed_ change is drastic. I have itemized the changes below under issues. Please comment on them. > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can > be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but Ibelieve > we had WG concensus to put this into the draft and I would like to see them back. > Ok. Let's discuss how to accommodate L2 triggers _without_ normative dependency on all link types that do and don't have such things. Do you have a proposal ? I would like to be able to define generic constructs that can serve as triggers for the protocol to be initiated. Ajoy: L2 trigger is an abstraction. I do not think we need to provide references to specific link layers. > > However, we have found that implementation is aided by having the specification be very precise about when L2 information is > needed and what information is needed. The FMIPv4 draft has this information in it, as does draft 04, and it has been very > useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain sufficiently detailed information, especially > for Postregv6 but also for Preregv6. Many cases that will be common for particular link layers like standard 802.11 or > cellular are relegated to Section 4.1, the Error Cases. The detailed information on the relationship between L2 events and > FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another. Let's seek the WG opinion on this. I think the base protocol should concern itself with IP messages while allowing any L2 feature to be used. The base protocol itself could define generic L2 constructs that can initiate the protocol operation. Others ? Ajoy-> We already had WG consensus about this. As per cancerous, it was decided that BETH will be included in base FMIPV6 draft. So, I do not see why are you asking such questions again? > > > > But it must also be possible to do this in the absence of any prehandover signaling, for those link layers that specify no > standard prehandover L2 triggers. The current draft treats this as an error case, and it would not be clear to an > implementor on such a link layer that this would be possible and correct. The reason for this is that proposed v05 is an adaptation of v04, in which a MN attempts to send an FBU prior to moving. Also, an implementor has to read the Error cases if he/she wishes to implement a robust protocol. If the WG agrees that the text should be under a different section, that's fine with me. > > > > 3. Allow L2 triggers to used > > > > Change from v04: Define generic, L2 independent constructs > > (to be done). > > > > New implications: define exact trigger formats elsewhere. > > The handover messages should be able to operate transparently. > > Introduce a Handover Solicit from NAR (when a trigger indicates > > that the MN is attached to it) to PAR to request a HI ? > > > > The information about when the L2 information is used and where needs to be specified somewhere. This draft is not > sufficiently precise about that. > Ok. What does the rest of the WG think about what L2 specific information should be in the draft ? > > > And, here are the new features > > > > - the MN should be able to maintain uninterrupted IP connectivity > > (i.e., is able to send and receive IP packets) for its existing > > sessions while it expeditiously establishes itself as a Mobile IP > > end-point. > > Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused > by the mobile node changing links. I don't see how "IP connectivity" translates to "IP is a connection oriented protocol". "Internet connectivity" does not translate to "Internet is connection oriented", does it ? Anyway, the parenthesis should help. What do others think ? > > > > - during the Binding Update procedure, the MN uses its PCoA > > to send and receive IP packets > > Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled. > I didn't see the connection between the two on this bullet.. > > > - the protocol can be initiated when the MN is on the old link > > (via RtSolPr/PrRtAdv) or on the new link (via FBU) > > > > Addition of initiation on the new link is a plus, but it is not clear from this description that this is allowed in the > general case. It is couched as an error case. > Ok. I can include text that allows specific usage. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 15:07:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01417 for ; Thu, 11 Jul 2002 15:07:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17676; Thu, 11 Jul 2002 13:07:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04338; Thu, 11 Jul 2002 12:07:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BJ6ak7020997 for ; Thu, 11 Jul 2002 12:06:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BJ6ZSl020996 for mobile-ip-dist; Thu, 11 Jul 2002 12:06:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BJ6Wk7020989 for ; Thu, 11 Jul 2002 12:06:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19420 for ; Thu, 11 Jul 2002 12:06:40 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22717 for ; Thu, 11 Jul 2002 12:06:39 -0700 (PDT) Message-ID: <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Charles E. Perkins" , "James Kempf" Cc: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 12:01:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, > It is possible to imagine a post-registration scheme for handovers > that does not use BETH. For instance, one could send a Binding Update > to the previous access router, as is specified in the base draft. Actually we worked out a protocol that basically does this. http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt This is a stand alone solution itself. It doesn't require anything but a link-up trigger. A similar approach was presented in the base draft, as an error case handling. We, the authors, believe that this can be worked into a complete solution, but of course there were some details that needed to be worked out (which the fmipv6 draft missed). Cheers, alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 15:14:42 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01693 for ; Thu, 11 Jul 2002 15:14:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26595; Thu, 11 Jul 2002 12:15:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07259; Thu, 11 Jul 2002 12:14:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BJE2k7021110 for ; Thu, 11 Jul 2002 12:14:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BJE2XI021109 for mobile-ip-dist; Thu, 11 Jul 2002 12:14:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BJDxk7021102 for ; Thu, 11 Jul 2002 12:13:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22327 for ; Thu, 11 Jul 2002 12:14:06 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03109 for ; Thu, 11 Jul 2002 13:14:06 -0600 (MDT) Message-ID: <02dc01c2290e$e5359450$4f6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <026901c22904$933fb8b0$4f6015ac@T23KEMPF> <3D2DD09A.318679D9@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 12:12:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, > Not all protocol is layer-3 protocol. Often, layer-2 > triggers trigger actions that are layer-2 actions, but > have no layer-3 effects. This is true especially for some > of the sorts of cellular handovers that I am familiar with, > and I wouldn't expect much controversy. But we ought to > be careful to use layer-3 controls just where they are needed. > No disagreement there. > >> 1) The protocol actions that are specified are layer-3 actions. The problem here is that Layer 3 needs to know what is going on at Layer 2. So there needs to be a specification of what the event is at Layer 2 that is triggering the protocol action at Layer 3. For example: Layer 2 Layer 3 ............ ............. Link goes down Start tunneling packets to NAR Is this what you have in mind? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:19:37 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15101 for ; Thu, 11 Jul 2002 20:19:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11377; Thu, 11 Jul 2002 17:19:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01959; Thu, 11 Jul 2002 17:19:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0AkoN000474 for ; Thu, 11 Jul 2002 17:10:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0AkhN000473 for mobile-ip-dist; Thu, 11 Jul 2002 17:10:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0AhoN000466 for ; Thu, 11 Jul 2002 17:10:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03250 for ; Thu, 11 Jul 2002 17:10:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16160 for ; Thu, 11 Jul 2002 17:10:49 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA22553; Thu, 11 Jul 2002 17:10:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C0Ak627662; Thu, 11 Jul 2002 17:10:46 -0700 X-mProtect: <200207120010> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4fEzq3; Thu, 11 Jul 2002 17:10:42 PDT Message-ID: <3D2E1E83.2CD19EC0@iprg.nokia.com> Date: Thu, 11 Jul 2002 17:10:43 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt References: <003e01c22905$d12826c0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, "Dr. Subrata Goswami" wrote: > 4. The BCE of the CN is indexed by the home-address of the MN. The spec > as it is now allows link-local addresses. So is there a possibility that > two MN's may end up having the same l-l address in a CN? I dont understand this. how did the link local address of the MN reach the CN? a binding cache entry for a link local address would exist only on a Home Agent. not on the CN. > 5. In a hypothetical situation, a MN may visit a foreign network and > acquires the same CoA address and the l-l HoA. Is it a possibility? Are > CoA's always global? yes. they are! the CoA is configured when the MN receives a router advert in the foreign network. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:22:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15206 for ; Thu, 11 Jul 2002 20:22:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11907; Thu, 11 Jul 2002 18:23:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07969; Thu, 11 Jul 2002 17:23:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0IxoN000521 for ; Thu, 11 Jul 2002 17:18:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0IxKt000520 for mobile-ip-dist; Thu, 11 Jul 2002 17:18:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0IuoN000513 for ; Thu, 11 Jul 2002 17:18:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18140 for ; Thu, 11 Jul 2002 16:18:30 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01676 for ; Thu, 11 Jul 2002 17:18:29 -0600 (MDT) Message-ID: <038901c22931$06cd7660$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> <3D2E0819.EDDDB916@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 16:16:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > this is a proposal to define the base protocol with IP messages > alone while allowing L2 triggers to be used. The intention was not > to take out anything without seeking consensus. A message from > the chairs yesterday indicated that v04 is the reference document > and v05 would be updated based on the WG discussion and consensus > on proposed changes. > That's not how I read Raj's note. Raj's note says that draft 04 is the concensus document, and draft 05 will be issued based on discussion of the currently proposed strawman draft that you issued, and concensus resolution to the list of issues. That does not necessarily mean that changes will be merged into the current strawman, IHMO. It could equally mean that changes from the strawman are merged into draft 04, which is what I maintain should be done (based on our success using draft 04 for implementation, and my lack of confidence that that would be possible, without massive revision, on the current strawman). Perhaps the WG chairs can clarify. > So, what is here is a list of proposed changes. I am proposing that the base > document should define generic L2 constructs that trigger protocol > operation. The exact format definitions, which depend on particular > link layers, should be spcified elsewhere. > Please point out to me in draft 04 where there are specific formats based on specific L2s. > I am willing to revise the draft by accommodating whatever the WG > desires. That's what I have to do. Would you like to help ? If yes, and > I hope you would, we may start by defining the generic L2 trigger > definitions that Charlie indicated and ensure that the base draft is > independent of specific L2 features. Is this acceptable ? > I am certainly willing to help, in fact, I am co-author on a draft, draft-manyfolks-l2-req-xx.txt, which does precisely this. But so far this draft has not got a lot of traction in IETF, which is why I think we may have to describe the coupling between the handover protocol and L2 directly in the handover document. The coupling description doesn't have to be for a specific L2, but can be similar to the email Charlie and I exchanged. Then, in separate documents, the exact implementation on a particular link layer can be described, with the exact L2 protocol. I really don't think our disagreement has to do with how to incorporate L2 specific information. I think the disagreement is about whether the current strawman draft 5 contains the kinds of implementation details that were so important to our implementation effort, especially for Postregv6/BETH, that are in draft 4. I don't see that level of detail, but rather, I see another year of trying to implement from the draft and trying to get the details up to where they were in draft 4. So I think a more fruitful course would be to take the new and important changes, like being able to send FBU after handover, and folding them into draft 4. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:22:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15254 for ; Thu, 11 Jul 2002 20:22:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12468; Thu, 11 Jul 2002 18:23:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03262; Thu, 11 Jul 2002 17:23:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0JBoN000531 for ; Thu, 11 Jul 2002 17:19:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0JBaU000530 for mobile-ip-dist; Thu, 11 Jul 2002 17:19:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0J8oN000523 for ; Thu, 11 Jul 2002 17:19:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06285 for ; Thu, 11 Jul 2002 17:19:14 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19082 for ; Thu, 11 Jul 2002 17:19:13 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id UAA26084 for ; Thu, 11 Jul 2002 20:19:11 -0400 (EDT) From: "Subrata Goswami" To: Subject: FW: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt Date: Thu, 11 Jul 2002 17:21:09 -0700 Message-ID: <00b701c2293a$05d321c0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, I was referring to the following in section 9.1. "Each Binding Cache entry conceptually contains the following fields: - The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the ........................." Subrata -----Original Message----- From: vijayd@darkstar.iprg.nokia.com [mailto:vijayd@darkstar.iprg.nokia.com] On Behalf Of Vijay Devarapalli Sent: Thursday, July 11, 2002 5:11 PM To: Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt hi, "Dr. Subrata Goswami" wrote: > 4. The BCE of the CN is indexed by the home-address of the MN. The spec > as it is now allows link-local addresses. So is there a possibility that > two MN's may end up having the same l-l address in a CN? I dont understand this. how did the link local address of the MN reach the CN? a binding cache entry for a link local address would exist only on a Home Agent. not on the CN. > 5. In a hypothetical situation, a MN may visit a foreign network and > acquires the same CoA address and the l-l HoA. Is it a possibility? Are > CoA's always global? yes. they are! the CoA is configured when the MN receives a router advert in the foreign network. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:27:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15430 for ; Thu, 11 Jul 2002 20:27:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10331; Thu, 11 Jul 2002 18:28:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10286; Thu, 11 Jul 2002 17:28:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0RPoN000951 for ; Thu, 11 Jul 2002 17:27:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0RPVk000950 for mobile-ip-dist; Thu, 11 Jul 2002 17:27:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0RMoN000943 for ; Thu, 11 Jul 2002 17:27:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03414 for ; Thu, 11 Jul 2002 15:35:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28561 for ; Thu, 11 Jul 2002 16:35:11 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA17830; Thu, 11 Jul 2002 15:35:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BMZ9024170; Thu, 11 Jul 2002 15:35:09 -0700 X-mProtect: <200207112235> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9rnAhJ; Thu, 11 Jul 2002 15:35:05 PDT Message-ID: <3D2E0819.EDDDB916@iprg.nokia.com> Date: Thu, 11 Jul 2002 15:35:05 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, this is a proposal to define the base protocol with IP messages alone while allowing L2 triggers to be used. The intention was not to take out anything without seeking consensus. A message from the chairs yesterday indicated that v04 is the reference document and v05 would be updated based on the WG discussion and consensus on proposed changes. So, what is here is a list of proposed changes. I am proposing that the base document should define generic L2 constructs that trigger protocol operation. The exact format definitions, which depend on particular link layers, should be spcified elsewhere. I am willing to revise the draft by accommodating whatever the WG desires. That's what I have to do. Would you like to help ? If yes, and I hope you would, we may start by defining the generic L2 trigger definitions that Charlie indicated and ensure that the base draft is independent of specific L2 features. Is this acceptable ? -Rajeev James Kempf wrote: > Rajeev, > > > You didn't exactly say what _proposed_ change is drastic. I have itemized the > > changes below under issues. Please comment on them. > > > > Below is an itemized list of what was removed in draft 05 which we found valuable in or *complete* implemetation of the > current working group draft. In particular, there were a couple important issues that came up in WG discussion which we have > spent lots of time and design cycles on trying to solve which have been ignored or fuzzed over in the current draft but were > clearly if perhaps inaccurately specified in the previous draft: > > Draft 05 is missing Sections 3.4 and 3.5 as mentioned. All the protocol support for source and target triggered network > handover has been removed from the message formats. > > Sections 3.1: This contains important details about the linking between particular kinds of L2 handover sequencing > information and Preregv6 signaling. This was invaluable for our implementation. > > Section 3.5: Tunnel termination conditions. As I recall from the mailing list discussion a year and a half ago (we can check > the archives) this was a hot issue when tunnel based handover was initially introduced into the draft. We've done lots of > work in our implementation to make this possible, in order to conserve access router resources, and we have some suggested > changes to the current WG draft on this. Draft 05 dodges the issue completely by specifying that the tunnel just times out. > > Section 4: Interoperability between Prereg and Postreg was another hot issue. We've done lots of work in our implementation > on this, and we now have what we think is a workable interoperability solution. This was completely eliminated from draft 05. > > Section 6: Draft 05 removes important details about handling error cases, which are necessary for implementation. We have > additional details that came out of our implemetation effort which are not included in draft 05. Draft 05 also makes cases > that are normal for particular link layers into error cases. > > Section 8: Here is what draft 05 has to say about security (from Section 3, Paragraph 3): > > In order to ensure that the target of traffic redirection is not an unsuspecting innocent host, the PAR has to > determine that the target address belongs to NAR, with which PAR has trust relationships. The > PAR takes these precautions before it associates PCoA with another address. > > This is not sufficient to secure the protocol. Draft 05 Section 9, Security Considerations, is similarly vague about what > must be done. Section 8 in the current WG draft isn't sufficiently precise either, but if draft 05 is supposed to move the > current WG draft forward, then it should be more precise. Instead, draft 05 removes the framework about how to secure the > protocol for network and mobile triggered handover. > > Prior to your issuing draft 05, I offered to send you a list of the changes we saw required in the current working group > draft that came out of our implementation experince, but you recommended that I wait until after you had issued draft 05. I > agreed thinking that minor editorial changes would be made in the current WG draft, as is fairly typical with WG drafts at > this stage (two years on) of development, but I was suprised to find, when draft 05 came out, that it was a complete rewrite > removing many important details (which I have outlined above) that were important to our implementation, such that it would > be very difficult to map the changes we saw needed in the current working group draft to draft 05. > > Frankly, after two years of working on this protocol, I had thought the draft text had settled down to a state in which it > was implementable with minor changes. Drastically rewriting the draft was unnecessary to introduce the material you describe > in the list below. > > What do other people in the WG think (if anybody cares)? Do we need a complete rewrite of this draft? > > > > > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka > BETH) can > > > be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but > Ibelieve > > > we had WG concensus to put this into the draft and I would like to see them back. > > > > > > > Ok. Let's discuss how to accommodate L2 triggers _without_ normative dependency on > > all link types that do and don't have such things. Do you have a proposal ? > > I would like to be able to define generic constructs that can serve as triggers for the > > protocol to be initiated. > > > > It is not clear that there is WG concensus for removing L2 specific event descriptions from the draft. We have been > discussing a L2 triggers draft, and we could put this information into the draft as we did for FMIPv4. > > I would like for us to start with the current WG draft and use that as a base for figuring out what should be done. Draft 05 > has eliminated too many details to make it useful. Perhaps we can come up with something based on the current WG draft that > describes how L2 events are utilized that is acceptable to you. > > > > Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure > caused > > > by the mobile node changing links. > > > > I don't see how "IP connectivity" translates to "IP is a connection oriented protocol". > > "Internet connectivity" does not translate to "Internet is connection oriented", does it ? > > Anyway, the parenthesis should help. > > What's happening is a change in routing. One needs to be precise about this. There is no connection-oriented context being > set up. > > > > > - during the Binding Update procedure, the MN uses its PCoA > > > > to send and receive IP packets > > > > > > Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled. > > > > > > > I didn't see the connection between the two on this bullet.. > > > > The text in draft 05 is not sufficiently clear or precise to present this as an option to an implementor. It looks like every > handover must consist of Preregv6 signaling, even if that is impossible to do on a particular link layer. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:41:17 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15974 for ; Thu, 11 Jul 2002 20:41:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20246; Thu, 11 Jul 2002 17:41:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09712; Thu, 11 Jul 2002 17:41:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0eEoN001204 for ; Thu, 11 Jul 2002 17:40:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0eELt001203 for mobile-ip-dist; Thu, 11 Jul 2002 17:40:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0eBoN001196 for ; Thu, 11 Jul 2002 17:40:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15272 for ; Thu, 11 Jul 2002 17:40:18 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14168 for ; Thu, 11 Jul 2002 18:40:12 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA23788; Thu, 11 Jul 2002 17:40:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C0eAf31143; Thu, 11 Jul 2002 17:40:10 -0700 X-mProtect: <200207120040> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNPyCYI; Thu, 11 Jul 2002 17:40:08 PDT Message-ID: <3D2E2569.1837696B@iprg.nokia.com> Date: Thu, 11 Jul 2002 17:40:09 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jim, I formatted your text a bit. they were wrapping around too much. James Kempf wrote: > > Rajeev, > > We implemented draft 04 and we feel that it was basically sound except > it needed some editorial tightening. Therefore, the > rather drastic revision represented by 05 is not particularly helpful toward > moving this forward. It is actually going back > to previous drafts, say 01, where many details were not as tightly specified as > draft 04. this is an extremely unreasonable statement to make. I went through draft 5. having been one of the two persons who has implemented draft 4, there is nothing missing in draft 5 for doing fast handovers that was in draft 4. the only thing that is missing is how to do tunnel handovers based on some L2 triggers. infact draft 5 simplifies so many things by eliminating too many different handover scenarios in draft 4. draft 4 was a nightmare to implement and interoperate (sorry Gopal, you were not to blame). ask Jon Wood and Alper Yegin. they were there. we spent 4 days at Connectathon 2002 and could do only a fraction of testing that we wanted to do. we didnt have one complete successful handover :( IMO, it is a big joke if somebody says draft 4 was better than draft 5 when it comes to implementing FMIPv6. > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical > for describing how Postregv6 (aka BETH) > can be implemented. If there is some problem with too much reference to L2 Section 3.3 and 3.4 also critically depend on L2 triggers to work. BTW, I still havent figured out how to implement L2 triggers on our testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers draft becomes a standard. right?? and the L2 triggers document does not even have a permanent home (WG). can you do Postregv6 without using L2 triggers? it can be done in draft 5. > triggers, we can discuss sanitizing them, but I this is better. if there is some way we can do this, we should do this. not put L2 stuff in the draft. > useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain > sufficiently detailed information, especially > for Postregv6 but also for Preregv6. Many cases that will be common for particular that is something which can be fixed if you feel it is not there. anyway IMO, draft 5 does both Postregv6 and Preregv6. and I certainly dont agree that it does not have enough information for implementing Preregv6 > But it must also be possible to do this in the absence of any prehandover > signaling, for those link layers that specify no > standard prehandover L2 triggers. The current draft treats this as an error case, > and it would not be clear to an > implementor on such a link layer that this would be possible and correct. this can be explicitly specified. I dont see a problem in it. > > - during the Binding Update procedure, the MN uses its PCoA > > to send and receive IP packets > > Agree. But the removal of the L2 triggers information seemingly excludes Postreg, > both mobile and network controlled. no. Postreg can be done without L2 triggers. > Addition of initiation on the new link is a plus, but it is not clear from this > description that this is allowed in the > general case. It is couched as an error case. again this is something which can be clarified. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:46:13 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16228 for ; Thu, 11 Jul 2002 20:46:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22733; Thu, 11 Jul 2002 17:46:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11642; Thu, 11 Jul 2002 17:46:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0jYoN001359 for ; Thu, 11 Jul 2002 17:45:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0jX24001358 for mobile-ip-dist; Thu, 11 Jul 2002 17:45:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0jUoN001351 for ; Thu, 11 Jul 2002 17:45:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18055 for ; Thu, 11 Jul 2002 17:45:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20978 for ; Thu, 11 Jul 2002 18:45:36 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA24059; Thu, 11 Jul 2002 17:45:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C0jYx08106; Thu, 11 Jul 2002 17:45:34 -0700 X-mProtect: <200207120045> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhDALeq; Thu, 11 Jul 2002 17:45:33 PDT Message-ID: <3D2E26AE.5B6CED6E@iprg.nokia.com> Date: Thu, 11 Jul 2002 17:45:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Subrata Goswami CC: mobile-ip@sunroof.eng.sun.com Subject: Re: FW: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt References: <00b701c2293a$05d321c0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit as I told you earlier, a BCE for a link local address would not exist on a CN. maybe this should be clarified if it not clear in the draft. and regarding the earlier message, the Home Agent defends the link local address of the MN (if the L bit was set in the BU). that does not mean there exists a binding cache entry for the link local address at the Home Agent. Vijay Subrata Goswami wrote: > > Hi Vijay, I was referring to the following in section 9.1. > > "Each Binding Cache entry conceptually contains the following fields: > > - The home address of the mobile node for which this is the Binding > Cache entry. This field is used as the key for searching the > ........................." > > Subrata > > -----Original Message----- > From: vijayd@darkstar.iprg.nokia.com > [mailto:vijayd@darkstar.iprg.nokia.com] On Behalf Of Vijay Devarapalli > Sent: Thursday, July 11, 2002 5:11 PM > To: Dr. Subrata Goswami > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt > > hi, > > "Dr. Subrata Goswami" wrote: > > > 4. The BCE of the CN is indexed by the home-address of the MN. The > spec > > as it is now allows link-local addresses. So is there a possibility > that > > two MN's may end up having the same l-l address in a CN? > > I dont understand this. how did the link local address of the MN > reach the CN? a binding cache entry for a link local address would > exist only on a Home Agent. not on the CN. > > > 5. In a hypothetical situation, a MN may visit a foreign network and > > acquires the same CoA address and the l-l HoA. Is it a possibility? > Are > > CoA's always global? > > yes. they are! the CoA is configured when the MN receives a router > advert in the foreign network. > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:54:58 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16493 for ; Thu, 11 Jul 2002 20:54:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19523; Thu, 11 Jul 2002 18:55:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18828; Thu, 11 Jul 2002 17:55:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0sboN001523 for ; Thu, 11 Jul 2002 17:54:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0sb2Z001522 for mobile-ip-dist; Thu, 11 Jul 2002 17:54:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0sXoN001515 for ; Thu, 11 Jul 2002 17:54:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13656 for ; Thu, 11 Jul 2002 17:54:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25702 for ; Thu, 11 Jul 2002 17:54:41 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA24455; Thu, 11 Jul 2002 17:54:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C0sdR17280; Thu, 11 Jul 2002 17:54:39 -0700 X-mProtect: <200207120054> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4nBfs2; Thu, 11 Jul 2002 17:54:37 PDT Message-ID: <3D2E28CE.41CE0D10@iprg.nokia.com> Date: Thu, 11 Jul 2002 17:54:38 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: "Charles E. Perkins" , James Kempf , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Alper E. YEGIN" wrote: > > Hi Charlie, > > > It is possible to imagine a post-registration scheme for handovers > > that does not use BETH. For instance, one could send a Binding Update > > to the previous access router, as is specified in the base draft. > > Actually we worked out a protocol that basically does this. > > http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt > > This is a stand alone solution itself. It doesn't require anything > but a link-up trigger. A similar approach was presented in the it can done without the link-up trigger, right?? like receiving a router advert on the new link. why cant we design a generic solution that would not depend on any L2 triggers. and make sure the solution does not prohibit using L2 triggers if available. I do agree that you can get better handover performance if you have L2 triggers. but it is also important, IMO, that the fast handover spec advances without having to depend on L2 triggers. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 20:58:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16653 for ; Thu, 11 Jul 2002 20:58:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25794; Thu, 11 Jul 2002 18:59:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14778; Thu, 11 Jul 2002 17:58:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0vpoN001661 for ; Thu, 11 Jul 2002 17:57:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C0vplH001660 for mobile-ip-dist; Thu, 11 Jul 2002 17:57:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C0vmoN001650 for ; Thu, 11 Jul 2002 17:57:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14504 for ; Thu, 11 Jul 2002 17:57:55 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20128 for ; Thu, 11 Jul 2002 18:57:54 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id UAA27812 for ; Thu, 11 Jul 2002 20:57:53 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: FW: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt Date: Thu, 11 Jul 2002 17:59:47 -0700 Message-ID: <00c001c2293f$6d66fe60$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D2E26AE.5B6CED6E@iprg.nokia.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, I would think it would be a good idea to mention in the draft how it is impossible for to have an l-l HoA in the CN's BCE. I can see some situations where that can happen - trying to confirm these. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Vijay Devarapalli Sent: Thursday, July 11, 2002 5:46 PM To: Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: FW: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt as I told you earlier, a BCE for a link local address would not exist on a CN. maybe this should be clarified if it not clear in the draft. and regarding the earlier message, the Home Agent defends the link local address of the MN (if the L bit was set in the BU). that does not mean there exists a binding cache entry for the link local address at the Home Agent. Vijay Subrata Goswami wrote: > > Hi Vijay, I was referring to the following in section 9.1. > > "Each Binding Cache entry conceptually contains the following fields: > > - The home address of the mobile node for which this is the Binding > Cache entry. This field is used as the key for searching the > ........................." > > Subrata > > -----Original Message----- > From: vijayd@darkstar.iprg.nokia.com > [mailto:vijayd@darkstar.iprg.nokia.com] On Behalf Of Vijay Devarapalli > Sent: Thursday, July 11, 2002 5:11 PM > To: Dr. Subrata Goswami > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt > > hi, > > "Dr. Subrata Goswami" wrote: > > > 4. The BCE of the CN is indexed by the home-address of the MN. The > spec > > as it is now allows link-local addresses. So is there a possibility > that > > two MN's may end up having the same l-l address in a CN? > > I dont understand this. how did the link local address of the MN > reach the CN? a binding cache entry for a link local address would > exist only on a Home Agent. not on the CN. > > > 5. In a hypothetical situation, a MN may visit a foreign network and > > acquires the same CoA address and the l-l HoA. Is it a possibility? > Are > > CoA's always global? > > yes. they are! the CoA is configured when the MN receives a router > advert in the foreign network. > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:10:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17144 for ; Thu, 11 Jul 2002 21:10:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28633; Thu, 11 Jul 2002 19:10:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17976; Thu, 11 Jul 2002 18:10:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C19LoN001843 for ; Thu, 11 Jul 2002 18:09:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C19Lmm001842 for mobile-ip-dist; Thu, 11 Jul 2002 18:09:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C19IoN001835 for ; Thu, 11 Jul 2002 18:09:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23892 for ; Thu, 11 Jul 2002 18:09:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12711 for ; Thu, 11 Jul 2002 19:09:25 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA24981; Thu, 11 Jul 2002 18:09:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C19OP01468; Thu, 11 Jul 2002 18:09:24 -0700 X-mProtect: <200207120109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3Iasgl; Thu, 11 Jul 2002 18:09:20 PDT Message-ID: <3D2E2C40.ECA04E5A@iprg.nokia.com> Date: Thu, 11 Jul 2002 18:09:20 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > Section 3.5: Tunnel termination conditions. As I recall from the mailing list > discussion a year and a half ago (we can check > the archives) this was a hot issue when tunnel based handover was initially > introduced into the draft. We've done lots of > work in our implementation to make this possible, in order to conserve access > router resources, and we have some suggested > changes to the current WG draft on this. Draft 05 dodges the issue completely by > specifying that the tunnel just times out. thats because 'Tunnel termination' was a critical issue in BETH. the BETH protocol does not work without it. it is not the case in anticipated handover (as defind in draft 4) that is why. > Section 4: Interoperability between Prereg and Postreg was another hot issue. > We've done lots of work in our implementation > on this, and we now have what we think is a workable interoperability solution. > This was completely eliminated from draft 05. thats because BETH was so different. it includes supressing router adverts from the routers. you had a problem with respect to interoperability between anticipated part and BETH part because the MN and the access router needed to be told exactly which protocol it was running. draft 05 has simplified that IMO. > Section 6: Draft 05 removes important details about handling error cases, which > are necessary for implementation. We have > additional details that came out of our implemetation effort which are not like what? I have Alper's Connectathon report here. I think Rajeev went through them. if these additional details are something other than what we found at Connectathon, lets discuss them. > Frankly, after two years of working on this protocol, I had thought the draft text > had settled down to a state in which it > was implementable with minor changes. Drastically rewriting the draft was > unnecessary to introduce the material you describe > in the list below. frankly, it was needed. we spent four days without one complete successful fast handover. it was frustrating to say the least. I would call neither implementation (yours nor ours) succesful (sorry Jon). Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:14:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17480 for ; Thu, 11 Jul 2002 21:14:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02056; Thu, 11 Jul 2002 19:14:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25417; Thu, 11 Jul 2002 18:14:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1DqoN001964 for ; Thu, 11 Jul 2002 18:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1Dqfc001963 for mobile-ip-dist; Thu, 11 Jul 2002 18:13:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1DnoN001956 for ; Thu, 11 Jul 2002 18:13:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28594 for ; Thu, 11 Jul 2002 18:13:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14216 for ; Thu, 11 Jul 2002 19:13:55 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA25722; Thu, 11 Jul 2002 18:13:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C1Dt807813; Thu, 11 Jul 2002 18:13:55 -0700 X-mProtect: <200207120113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjeRLoh; Thu, 11 Jul 2002 18:13:53 PDT Message-ID: <3D2E2D51.27963D7F@iprg.nokia.com> Date: Thu, 11 Jul 2002 18:13:53 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> <3D2E2C40.ECA04E5A@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > thats because 'Tunnel termination' was a critical issue in BETH. the > BETH protocol does not work without it. it is not the case in > anticipated handover (as defind in draft 4) I wanted to say draft 5. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:23:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17937 for ; Thu, 11 Jul 2002 21:23:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28633; Thu, 11 Jul 2002 19:24:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27904; Thu, 11 Jul 2002 18:23:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1MmoN002151 for ; Thu, 11 Jul 2002 18:22:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1Mmkr002150 for mobile-ip-dist; Thu, 11 Jul 2002 18:22:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1MioN002143 for ; Thu, 11 Jul 2002 18:22:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13206 for ; Thu, 11 Jul 2002 16:13:54 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12696 for ; Thu, 11 Jul 2002 17:13:53 -0600 (MDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id BFF0DE00794 for ; Thu, 11 Jul 2002 16:13:47 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA15286; Thu, 11 Jul 2002 16:14:21 -0700 (PDT) Date: Thu, 11 Jul 2002 16:14:21 -0700 (PDT) From: Joe Lau Message-Id: <200207112314.QAA15286@strtio1.cup.hp.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIPv6 draft 18 In-Reply-To: <3D1B71F0.4090501@kolumbus.fi> Cc: jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I found some minor inconsistencies and editorial improvements in the MIPv6 ID-18 draft. I am not sure if those itmes have been reported before by other people. Regards, Joe Lau ------------------------------------------------------------------------- 1. Unique Identifier option allowed on Home Test Init and Care-of Test Init? Page 25: Mobility options .... This specification does not define any options valid for the Home Test Init message. Page 26: Mobility options ... This specification does not define any options valid for the Care-of Test Init message. Page 119: If the Binding Refresh Request for which the Binding Update is being returned contains a Unique Identifier mobility option, the resulting Home Test Init, Care-of Test Init, and Update messages MUST also include a Unique Identifier mobility option. 2. Whether Home Address destination option MUST be included in BUs sent to HA. Page 12: ... In order for the home address of the mobile node to be visible when the policy check is made, the mobile node MUST use the Home Address destination option in Binding Updates sent to the home agent. Page 116: - The Home Address destination option MUST be attached to the message, unless the Source Address is the home address of the mobile node. Page 121 (Returning Home): ... The mobile node MUST NOT include a Home Address option in this Binding Update. It would be nice to have a single statement on when Home Address destination option MUST be and when MUST NOT be included in BUs sent to HA. 3. Purpose of Home Test Init. Page 16: The mobile node sends a Care-of Test Init message to the correspondent node to acquire the care-of cookie. But the draft does not state: The mobile node sends a Home Test Init message to the correspondent node to acquire the home cookie. 4. Binding Authorization Data option is valid for what messages? Page 39: The Binding Authorization Data option is valid only in the Binding Refresh Request, Binding Update, and Binding Acknowledgment messages. [then later, the draft says:] ... For this procedure, this option can only appear in a Binding Update message and rules for calculating ^^^^ ???? the Authenticator value are described in Section 6.1.7. ^^^^^ 5.2.6 5. Sequence number modulo arithmatics (15 or 16?) Page 64: 2**15 Page 67: 2**16 Page 92: 2**15 Page 116: 2**16 Page 131: 2**15 6. Duplicated text (about 57 lines) Page 100: ... On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [12], the mobile node performs the following steps, in addition to any steps already required of it by Neighbor Discovery. - If the Home Agent (H) bit in the Router Advertisement is not set, and the sending node currently has an entry in the node's Home Agents List, delete the corresponding entry. Subsequently, skip all of the following steps. .... A mobile node SHOULD maintain an entry in its Home Agents List for each such valid home agent address until that entry's lifetime expires, after which time the entry MUST be deleted. -------------------------------------------------------------------- The above block of text is almost identical to that on page 84. Duplicated text suffers the same problem as duplicated code in programming. 7. Duplicated text Page 124: 11.6.9. Rate Limiting Binding Updates A mobile node MUST NOT send Binding Update messages for the same binding to any individual node more often than once per MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive messages to a particular node with the same care-of address, the mobile node SHOULD reduce its rate of sending these messages to that node, to the rate of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send these messages at this slower rate indefinitely, in hopes that the node will eventually be able to process a Binding Update, and begin to route its packets directly to the mobile node at its new care-of address. --------------- The above block of text is almost identical to that on pag 111. It would be nice to have a single paragraph on Rate limiting procedure. 3. Typo error Page 15: Due to the nearly simultaneous message delivery, the return routability procedure completes in about roundtrip between the mobile node and the correspondent. ^^^^^^^^^ How many? 7. Typo error. Page 91: The rules for maintaining a Home Agents List are same for home agents and correspondent nodes, and have been described in Section 10.1. ^^^^^^^^^^^^^^^^^^^ mobile nodes ...Note that the mobile node SHOULD NOT respond Binding Requests from previously unknown correspondent nodes due to ... ^ Refresh From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:24:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17978 for ; Thu, 11 Jul 2002 21:24:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05287; Thu, 11 Jul 2002 19:25:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28307; Thu, 11 Jul 2002 18:24:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1NroN002168 for ; Thu, 11 Jul 2002 18:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1Nr1g002167 for mobile-ip-dist; Thu, 11 Jul 2002 18:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1NnoN002160 for ; Thu, 11 Jul 2002 18:23:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27985 for ; Thu, 11 Jul 2002 18:23:57 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14783 for ; Thu, 11 Jul 2002 18:23:57 -0700 (PDT) Message-ID: <04a601c22942$23b881f0$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Vijay Devarapalli" Cc: "Charles E. Perkins" , "James Kempf" , "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 18:19:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, > > > It is possible to imagine a post-registration scheme for handovers > > > that does not use BETH. For instance, one could send a Binding Update > > > to the previous access router, as is specified in the base draft. > > > > Actually we worked out a protocol that basically does this. > > > > http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt > > > > This is a stand alone solution itself. It doesn't require anything > > but a link-up trigger. A similar approach was presented in the > > it can done without the link-up trigger, right?? like receiving a > router advert on the new link. why cant we design a generic solution > that would not depend on any L2 triggers. and make sure the solution > does not prohibit using L2 triggers if available. I don't think we can have a reasonable fast handover solution without relying at least on a link-up trigger on the mobile node. alper > > I do agree that you can get better handover performance if you have > L2 triggers. but it is also important, IMO, that the fast handover > spec advances without having to depend on L2 triggers. > > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:38:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18552 for ; Thu, 11 Jul 2002 21:38:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10020; Thu, 11 Jul 2002 19:39:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24939; Thu, 11 Jul 2002 18:39:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1aroN002428 for ; Thu, 11 Jul 2002 18:36:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1arTD002427 for mobile-ip-dist; Thu, 11 Jul 2002 18:36:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1anoN002420 for ; Thu, 11 Jul 2002 18:36:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06958 for ; Thu, 11 Jul 2002 18:36:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02708 for ; Thu, 11 Jul 2002 19:36:56 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA27182; Thu, 11 Jul 2002 18:36:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C1auW11081; Thu, 11 Jul 2002 18:36:56 -0700 X-mProtect: <200207120136> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWx8pf8; Thu, 11 Jul 2002 18:36:53 PDT Message-ID: <3D2E32B6.2D1F2E4E@iprg.nokia.com> Date: Thu, 11 Jul 2002 18:36:54 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: "Charles E. Perkins" , James Kempf , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Alper E. YEGIN" wrote: > I don't think we can have a reasonable fast handover solution > without relying at least on a link-up trigger on the mobile node. is the link-up trigger available on all mobile nodes? if the answer is no, then we are stuck without a generic fast handover solution. OTOH, with sufficiently fast router advertisements you can have a reasonably fast handover. agreed, it is wont be as good when you have a link-up trigger. but I didnt say you should not take help from a link-up trigger. seriously, do you think we can advance the FMIPv6 draft to a Proposed Standard without having a L2 triggers specification? anybody has an answer to this question? Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 21:40:17 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18623 for ; Thu, 11 Jul 2002 21:40:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20414; Thu, 11 Jul 2002 18:40:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02408; Thu, 11 Jul 2002 18:40:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1dVoN002469 for ; Thu, 11 Jul 2002 18:39:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1dV8h002468 for mobile-ip-dist; Thu, 11 Jul 2002 18:39:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1dRoN002458 for ; Thu, 11 Jul 2002 18:39:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07602 for ; Thu, 11 Jul 2002 18:39:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07791 for ; Thu, 11 Jul 2002 19:39:34 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA27246; Thu, 11 Jul 2002 18:39:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C1dXM12735; Thu, 11 Jul 2002 18:39:33 -0700 X-mProtect: <200207120139> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB8n49m; Thu, 11 Jul 2002 18:39:31 PDT Message-ID: <3D2E32FD.D1888C8E@iprg.nokia.com> Date: Thu, 11 Jul 2002 18:38:06 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Alper, "Alper E. YEGIN" wrote: > I don't think we can have a reasonable fast handover solution > without relying at least on a link-up trigger on the mobile node. But we have an implementation that shows otherwise. One can have an implementation that works well. > > I do agree that you can get better handover performance if you have > > L2 triggers. but it is also important, IMO, that the fast handover > > spec advances without having to depend on L2 triggers. > > > > Vijay > > I also agree with this. I think we have to make the specification so that it works as well as it can by itself, and it enables use of L2 triggers to work better whenever the triggers are supported by the particular link layer. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 22:21:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20125 for ; Thu, 11 Jul 2002 22:21:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21930; Thu, 11 Jul 2002 20:22:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20432; Thu, 11 Jul 2002 19:22:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C2KhoN002816 for ; Thu, 11 Jul 2002 19:20:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C2KhJn002815 for mobile-ip-dist; Thu, 11 Jul 2002 19:20:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C2KdoN002808 for ; Thu, 11 Jul 2002 19:20:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05189 for ; Thu, 11 Jul 2002 19:20:47 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15806 for ; Thu, 11 Jul 2002 20:20:45 -0600 (MDT) Received: from Bukok ([202.106.136.212]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id LAA19126 for ; Fri, 12 Jul 2002 11:26:13 +0900 (CDT) Date: Fri, 12 Jul 2002 11:26:13 +0900 (CDT) Message-Id: <200207120226.LAA19126@mail1.beijingnet.com> From: tjc To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fw:mobile-ip,sos! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=M86aR3CFJ787936A618p Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --M86aR3CFJ787936A618p Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --M86aR3CFJ787936A618p Content-Type: audio/x-midi; name=»ªÄÏÀí¹¤¼ÆËã»úÓëÍøÂ繤³ÌѧԺ.scr Content-ID: Content-Transfer-Encoding: base64 --M86aR3CFJ787936A618p Content-Type: application/octet-stream; name=»ªÄÏÀí¹¤¼ÆËã»úÓëÍøÂ繤³ÌѧԺ.doc Content-Transfer-Encoding: base64 Content-ID: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALAAAAAAA AAAAEAAALgAAAAEAAAD+////AAAAACsAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEATQAJBAAACFK/AAAAAAAAEAAAAAAABAAA lgwAAA4AYmpiaicyJzIAAAAAAAAAAAAAAAAAAAAAAAAECBYAMhQAAEVYAABFWAAASwQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAADwBAAAAAAAAPAEAADwBAAAAAAAAPAEAAAAAAAA8AQAA AAAAADwBAAAAAAAAPAEAABQAAAAAAAAAAAAAAFABAAAAAAAAUAEAAAAAAABQAQAAAAAAAFAB AAAAAAAAUAEAAAwAAABcAQAADAAAAFABAAAAAAAAugUAAGoBAAB0AQAAFgAAAIoBAAAAAAAA igEAAAAAAACKAQAAAAAAAIoBAAAAAAAAZQIAAAAAAABlAgAAAAAAAGUCAAAAAAAAfwUAAAIA AACBBQAAAAAAAIEFAAAAAAAAgQUAAAAAAACBBQAAAAAAAIEFAAAAAAAAgQUAACQAAAAkBwAA 9AEAABgJAABCAAAApQUAABUAAAAAAAAAAAAAAAAAAAAAAAAAPAEAAAAAAABlAgAAAAAAAAAA AAAAAAAAAAAAAAAAAABlAgAAAAAAAGUCAAAAAAAAZQIAAAAAAABlAgAAAAAAAKUFAAAAAAAA swQAAAAAAAA8AQAAAAAAADwBAAAAAAAAigEAAAAAAAAAAAAAAAAAAIoBAADbAAAAdAEAAAAA AACzBAAAAAAAALMEAAAAAAAAswQAAAAAAABlAgAACAIAADwBAAAAAAAAigEAAAAAAAA8AQAA AAAAAIoBAAAAAAAAfwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAEAAAAAAABQAQAAAAAAADwB AAAAAAAAPAEAAAAAAAA8AQAAAAAAADwBAAAAAAAAZQIAAAAAAAB/BQAAAAAAALMEAADMAAAA swQAAAAAAAAAAAAAAAAAAH8FAAAAAAAAPAEAAAAAAAA8AQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfwUAAAAAAACKAQAA AAAAAGgBAAAMAAAAIDiE2wt+wQFQAQAAAAAAAFABAAAAAAAAbQQAAEYAAAB/BQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATlNXUwZ05V0nWWZbDQATACAASABZAFAARQBSAEwA SQBOAEsAIAAiAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBzAGMAdQB0AC4AZQBkAHUALgBjAG4A LwAiACAAAQAUAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBzAGMAdQB0AC4AZQBkAHUALgBjAG4A LwAVAA0AoYuXezpnb4/2Tg5OUX/cfuVdC3pmW2KWgHvLTiAADQAAMAAwMgAwADAAMQB0XjUA CGdOU1dTBnTlXSdZZlsOTn9eHE4Bd+FPb2CnThpOhVN+e3J/T1Oui7NRmltxUfpeTlNXUwZ0 5V0nWWZboYuXezpnb4/2Tg5OUX/cfuVdC3pmW2KWDP+hi5d7Omdvj/ZODk5Rf9x+5V0LemZb YpblTmZbIWifU2VnhHahi5d7Omf7fAEwUX/cfi1Ow18BMKGLl3stTsNfOk47TlNPxH4QYgIw CwAAMAAwZltilu52TVLlYglnoYuXezpn0XlmWw5OgGIvZ1pT61hmW01PiGOITkNnDP/lYgln oYuXezpn+3zfftN+hGcBMKGLl3s6Z2+P9k4OTgZ0uosBMKGLl3s6Z5ReKHWAYi9nCU4qToxO p35mW9F5VXjrWLlwCP9VeOtYuXBQn2hRCf8M/76LCWehi5d7Omdvj/ZOATChi5d7OmeUXih1 ATAnWYtXcGVuYwRZBnQBMFF/3H7lXQt6SXssZ9F5E04aTrllEVQCMAsAADAAMKGLl3s6Z2+P 9k4OTlF/3H7lXQt6ZltilrBzCWcTTvtOWWUIXjYAMABZT7pODP9ZZYWPuk5YVDMAMAC6Tgz/ dlEtTllliGMxADMAuk4M/29SWWWIYwEw2JqnfuVdC3oIXjIAOAC6Tgz/WlPrWB91/FsIXjgA uk4M/1V461gfdfxbCF4yADAAGlm6Tgz/WXVmW1JfZWeEdlllCF4xADAAuk4CMDQANQCBXOVO C06Edi1OUpd0XlllCF6mfmBTNgAwACUADP93UQlnWlPrWGZbTU8xADUAuk4M/1V461hmW01P MwAwALpOAjDudk1SZltilvJdEJBla2JfEGKGTtN+hGcIVAZ0hHZZZQher2gflgIwCwAAMAAw ZltilrBzCWcEVHt8ZlsfdXFRoYsyADQAMAAwABpZuk4M/3ZRLU4sZ9F5H3UxADEANwAwALpO DP8QYrpOE05HUyxnZlsfdTMAMAAzALpODP+Fj+5PEWJilhNOGk7lTspTLHuMThNOGk6EdmZb H3UJZzQAMAAwABpZuk4M/1V461gUeHZ6H3UxADQAMAC6Tgz/WlPrWB91MgAwALpODP/lXQt6 VXjrWA5OFHh2eh9124/uT+1zCWc0ADAAMAAaWbpOAjALAAAwADDRj+BRdF5lZwz/oYuXezpn +HZzUWZb0XlxUX9ixWKGTv1WtlvqgTZx0XlmW/pX0ZE0AHmYDP/9VrZbOAA2ADMAoYsSUjQA eZgM/wF36JDUWTEAMQB5mAz/f14cTgF36oE2cdF5Zlv6V9GRMQAyAHmYDP8qahFU0XkUeHmY 7nYzADAAGll5mAz/QGIJZ9F5FHh5mO52z345jTtgoYs4ADYAMAAaWQdOQ1Eb/9FTaIi6i4dl MgAwADAAGlnHexv/Zltilu52TVLlYglnNQAqTmZbL2fiVh+WCP+hi5d7OmdRf9x+gGIvZwEw b4/2TgBf0VOvc4NYDk7hT29g+3zffsaWEGIBMHpm/YChi5d7gGIvZwEwGlmSWlNPgGIvZ4xU /lZiX/5Wz1AEWQZ0jFRRf9x+WWWygHNRLpWAYi9nCf+MVDIAKk5ZZWZb4lYflgj/oYuXezpn bFFxUf6LWWVmW4xUoYuXezpn+ldAeP6LWWVmWwn/AjALAAAwADChi5d7Omdvj/ZODk5Rf9x+ 5V0LemZbYpblYglnSQBCAE0AoYuXezpngGIvZy1Ow18BMKGLl3stTsNfATAtTv1WWWWygNF5 FHhRf05TV1MtTsNfATB/XhxOAXdZZbKAhVOhi5d7OmdRf9x+zZG5cJ5bjJqkW0l7GlkqTtia NGxzXp5bjJqkWwIwMXWOTmZbIWiEds2RuXCVYmVRjFSXXzBSSQBCAE0AbFH4U0l7/VaFURZZ V4QNVAFPGk6Edl6NqVIvZQFjDP+eW4yavosHWfJdvo8wUv1WhVEATkFtNGxzXgIwnluMmqRb RI2nTjtgPFCFjcePMQC/TkNRuk4RbAFeAjALAAAwADChi5d7Omdvj/ZODk5Rf9x+5V0LemZb YpYvZmhR/VZ5citSL2Z/XhxOAXdJAFQATIgaTtF5ZluAYi9njFShewZ0uk5NYoR2+Vd7UfpX MFcM/xBiOk5/XhxOAXehi5d7Omdvj/ZOjFRRf9x+c1EulYBiL2cUeHZ6AF/RU/pXMFcCMAsA IAANAGZbYpYLTr6LoYuXezpn5V0Leg5O0XlmW/t8DP/lYglnoYuXezpngGIvZy1Ow18BMKGL l3s6Z1llZlueW4yaLU7DX4xUoYuXezpnUX/cfuVdC3rNkblwnluMmqRbAjAJZ6GLl3s6Z5Re KHWAYi9nWlPrWGZbTU+IY4hOuXAb/6GLl3s6Z2+P9k4OTgZ0uosBMKGLl3s6Z5ReKHWAYi9n ATChi5d7Omf7fN9+036EZwlOKk5VeOtYZltNT4hjiE65cBv/oYuXezpn0XlmWw5OgGIvZyxn 0XkTThpOAjC+iwlnoYuXezpnb4/2TgEwoYuXezpnlF4odQEwJ1mLV3BlbmMEWQZ0ATBRf9x+ 5V0Lekl7E04aTrllEVQCMCAADQANAAAwIWhAVxr/f17eXQJeKVmzbDpTlE5xXO+NIAALAAAw rpAWfxr/NQAxADAANgA0ADEAIAALAAAwNXXdixr/OAA2AC0AMgAwAC0AOAA3ADEAMQAwADAA MAAwAAsADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMBAAA DgQAABAEAAAoBAAAVgQAAFoEAABcBAAAXgQAAIwEAACOBAAAkAQAALAEAAC0BAAAFgsAABgL AAA2DAAAOAwAAHYMAACCDAAAlAwAAJYMAAD59Ov0+fTf69fr9M3Jw8m7tK6mrvQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DkIqD09KAwBRSgMAbygBAAtCKg9PSgMAUUoDAAxAiCgAT0oDAFFKAwAAD0CIKABPSgMAUUoD AG8oAQtAiBQAQ0oVAG8oAQdDShUAbygBEjUIgUNKHABPSgMAUUoDAG8oAQAPMEoQAE9KAwBR SgMAbygBFwIIgQNqAAAAAAYIAU9KAwBRSgMAVQgBEQNqAAAAAE9KAwBRSgMAVQgBCE9KAwBR SgMAAAtPSgMAUUoDAG8oAQAVAAQAAA4EAACQBAAAsAQAABgLAAA2DAAAOAwAAJYMAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAwAAEYQ8AgAEDwASZGgBAQADAAADJAEAAQAAAAcABAAADgQAAJAE AACwBAAAGAsAADIMAAA0DAAAbAwAAJYMAAAAAAD9+/v7AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgEBAAMCDwAACDAAMZA4ATJQAgAfsIIuILDGQSGwCAcisAgHI5CgBSSQoAUlsAAA F7BTAxiw4AMMkKkBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1QAAAEQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAGAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBz AGMAdQB0AC4AZQBkAHUALgBjAG4ALwAAAODJ6nn5us4RjIIAqgBLqQswAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAHMAYwB1AHQALgBlAGQAdQAuAGMAbgAvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEgAKAAEAWwAPAAIAAAADAAAA RgAAQPH/AgBGAAwAAgBja4dlAAALAAAAAyQDMSQAYSQDACQAQ0oVAEtIAgBQSgMAX0gBBGFK GABtSAkEbkgECHNICQR0SAQIAAAAAAAAAAAAAAAAAAAAAAAAHABBQPL/oQAcAAwABgDYnqSL tWs9hFdbU08AAAAAAAAAAAAAAABSAP5PAQDyAFIADAAIAG5mGpAgACgAVwBlAGIAKQAAAB8A DwADJAASZBD/AAATpGQAFKRkADEkAVskAVwkAWEkAAAQAENKEgBLSAAAT0oDAFFKAwAkAFVA ogABASQADAAEAIWNp37+lKVjAAAMAD4qAUIqAnBoAAD/ACwAVkCiABEBLAAMAAgA8l2/i+6V hHaFjad+/pSlYwAADAA+KgFCKgxwaIAAgAAAAAAASwQAAAUAABQAAAAA/////wAEAACWDAAA BwAAAAAEAACWDAAACAAAAAAEAACWDAAACQAAAAcAAAAuAAAARgAAAEsEAAATWBT/FYQPAADw OAAAAAAABvAYAAAAAggAAAIAAAABAAAAAQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICA gAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAA DgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAA AAAABgAAAF4AAABfAAAAYAAAALEAAAC0AAAAFgEAABkBAAArAQAALQEAADQBAAA2AQAAPAEA AD4BAABJAQAASwEAAFIBAABTAQAAWgEAAFwBAABmAQAAaAEAAGoBAABsAQAAdwEAAHoBAACB AQAAgwEAAIkBAACLAQAAoQEAAKQBAACuAQAAsgEAALoBAAC+AQAAxwEAAMoBAADcAQAA3wEA AOcBAADqAQAA7wEAAPEBAAD/AQAAAgIAAAUCAAAIAgAAIAIAACECAAAlAgAAKAIAACoCAAAr AgAAMAIAADICAAA9AgAAPwIAAEcCAABJAgAAVgIAAFkCAABhAgAAZAIAAG0CAABuAgAAqAIA AKkCAADCAgAAxQIAANMCAADWAgAAFQMAABgDAAA/AwAAQAMAAEYDAACMAwAAGQQAAB0EAAAp BAAALAQAAC8EAAA6BAAAOwQAAE0EAAAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcAAAAAAKQBAAAIAgAASQMAAIsDAACM AwAAuwMAAPoDAAAbBAAAHQQAAEoEAABNBAAABwAFAAcABQAHAAUABwAEAAcABQAHAP//BAAA AAMATABpAHUAIgBDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAE5TV1MGdOVdoYuX ezpnDk5Rf9x+5V0LemZbYpYuAGQAbwBjAAMAagBoAHkANwBDADoAXABXAEkATgBEAE8AVwBT AFwARABlAHMAawB0AG8AcABcAEkAUAB2ADYAA4zlZ6ViSlRcAEkAUAB2ADYAA4zlZ6ViSlRc AE5TV1MGdOVdoYuXezpnDk5Rf9x+5V0LemZbYpYuAGQAbwBjAP9AAYABABoEAAAaBAAAUCQb AkYARgAaBAAAAAAAABkEAAAAAAAAAhAAAAAAAAAASwQAAFAAAAQAAAAABgAAAEcWkAEAAAIC BgMFBAUCAwSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIA bwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkA bQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIA aQBhAGwAAAAtBpABhgACAQYAAwEBAQEBAQAAAAAADggQAAAAAAAAAAAABAAAAAAAi1tTTwAA LQaQAYYAAgEGAAMBAQEBAQEAAAAAAA4IEAAAAAAAAAAAAAQAAAAAANGeU08AAFcSkAEACAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAGUAbgB0AHUAcgB5AAAAVABpAG0A ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAgAAQA8QiIGAAApAEAAGgBAAAAAO56W4YJM1yG AAAAAAMADgAAAFoAAABkAAAAAQABAAAABAADEAQAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAA IQMAAAAAAAADAC0AEwAhACkALAAuADoAOwA/AF0AfQCoALcAxwLJAhUgFiAZIB0gJiA2IgEw AjADMAUwCTALMA0wDzARMBUwFzAB/wL/B/8J/wz/Dv8a/xv/H/89/0D/XP9d/17/4P8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KABbAHsAtwAYIBwgCDAKMAwwDjAQMBQwFjAI/w7/O/9b/+H/5f8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQA nACCgHIAAAAQABkAZAAAABkAAAB8AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVQMAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAAGAE5T V1MGdOVdJ1lmWwAAAAAAAAMATABpAHUAAwBMAGkAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA 4IWf8vlPaBCrkQgAKyez2TAAAABoAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAsAAAAAQA AAC8AAAABQAAAMgAAAAGAAAA1AAAAAcAAADgAAAACAAAAPAAAAAJAAAA/AAAABIAAAAIAQAA CgAAACQBAAAMAAAAMAEAAA0AAAA8AQAADgAAAEgBAAAPAAAAUAEAABAAAABYAQAAEwAAAGAB AAACAAAAqAMAAB4AAAANAAAAu6rEz8DtuaS089GnAABvAB4AAAABAAAAAKrEzx4AAAAEAAAA TGl1AB4AAAABAAAAAGl1AB4AAAABAAAAAGl1AB4AAAAHAAAATm9ybWFsAKQeAAAABAAAAExp dQAeAAAAAgAAADMAdQAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAAQAAAAADUrfQBAAAA QAAAAAAMXgqIbcEBQAAAAAAWlrsLfsEBAwAAAAEAAAADAAAAWgAAAAMAAABkAAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQ k5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjgBAAD0AAAADAAAAAEAAABoAAAADwAAAHAA AAAFAAAAfAAAAAYAAACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAA rAAAABYAAAC0AAAADQAAALwAAAAMAAAA1QAAAAIAAACoAwAAHgAAAAQAAABCSUkAAwAAAAQA AAADAAAAAQAAAAMAAAB8AgAAAwAAAPEOCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAB4QAAABAAAADQAAALuqxM/A7bmktPPRpwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAJAEAAAQAAAAAAAAAKAAAAAEAAABSAAAAAgAAAFoAAAADAAAAsgAAAAIAAAACAAAA CgAAAF9QSURfR1VJRAADAAAADAAAAF9QSURfSExJTktTAAIAAACoAwAAQQAAAE4AAAB7ADAA NABDAEYARgBFADAAOAAtAEUAQQAyAEYALQAxADEARAA1AC0AQQBCADcAMgAtADAAMABFADAA NABDAEQARAAyADUAQgBCAH0AAAAAAEEAAABoAAAABgAAAAMAAAA0ACcAAwAAAAAAAAADAAAA AAAAAAMAAAAFAAAAHwAAABgAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcwBjAHUAdAAuAGUA ZAB1AC4AYwBuAC8AAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAD+//// DAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAAP7///8UAAAAFQAAABYAAAAXAAAAGAAAABkA AAAaAAAA/v///xwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAD+////JAAAACUAAAAmAAAA JwAAACgAAAApAAAAKgAAAP7////9////LQAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIA eQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAZzuDWcMEB4F+N2wt+wQEvAAAAgAAAAAAA AABEAGEAdABhAAAAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAsAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAdQBtAGUAbgB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAAAAAQAAAAAAAAVwBvAHIAZABEAG8A YwB1AG0AZQBuAHQAAABtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MhQAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABsAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIwAAAAAQAAAAAAAAAQBDAG8A bQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGApBANYBAPDMDQAA4A0AAAEAAAD+//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhQAAABNaWNyb3NvZnQgV29yZCDO xLW1AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=9 --M86aR3CFJ787936A618p-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 11 23:48:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23705 for ; Thu, 11 Jul 2002 23:48:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09772; Thu, 11 Jul 2002 21:49:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23748; Thu, 11 Jul 2002 20:48:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C3kdoN004288 for ; Thu, 11 Jul 2002 20:46:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C3kdPt004287 for mobile-ip-dist; Thu, 11 Jul 2002 20:46:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C3kaoN004280 for ; Thu, 11 Jul 2002 20:46:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13265 for ; Thu, 11 Jul 2002 20:46:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17609 for ; Thu, 11 Jul 2002 20:46:43 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA01607; Thu, 11 Jul 2002 20:46:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6C3kfL18619; Thu, 11 Jul 2002 20:46:41 -0700 X-mProtect: <200207120346> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqXSEii; Thu, 11 Jul 2002 20:46:39 PDT Message-ID: <3D2E511F.10BA6589@iprg.nokia.com> Date: Thu, 11 Jul 2002 20:46:39 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: Vijay Devarapalli , "Charles E. Perkins" , James Kempf , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Alper, "Alper E. YEGIN" wrote: > Hi Vijay, > > > > > It is possible to imagine a post-registration scheme for handovers > > > > that does not use BETH. For instance, one could send a Binding Update > > > > to the previous access router, as is specified in the base draft. > > > > > > Actually we worked out a protocol that basically does this. > > > > > > > http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt > > > > > > This is a stand alone solution itself. It doesn't require anything > > > but a link-up trigger. A similar approach was presented in the > > > > it can done without the link-up trigger, right?? like receiving a > > router advert on the new link. why cant we design a generic solution > > that would not depend on any L2 triggers. and make sure the solution > > does not prohibit using L2 triggers if available. > > I don't think we can have a reasonable fast handover solution > without relying at least on a link-up trigger on the mobile node. > we should allow the use, and benefit from it. In fact, Linux v6 stack already provides an "upcall" that forces a RS to be sent when a new interface is detected. However, to say that fast handover won't work when such a feature is not available is analogous to saying that the particular link type is not suited for fast handover. We should not make that conclusion. We should allow all possible hooks for L2-specific customizations, while not relying on them. See you in Yokohama.. -Rajeev > > alper > > > > > I do agree that you can get better handover performance if you have > > L2 triggers. but it is also important, IMO, that the fast handover > > spec advances without having to depend on L2 triggers. > > > > Vijay > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 01:56:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28128 for ; Fri, 12 Jul 2002 01:56:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13128; Thu, 11 Jul 2002 23:57:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17187; Thu, 11 Jul 2002 22:57:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C5tSoN004843 for ; Thu, 11 Jul 2002 22:55:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C5tSEv004842 for mobile-ip-dist; Thu, 11 Jul 2002 22:55:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C5tPoN004835 for ; Thu, 11 Jul 2002 22:55:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27666 for ; Thu, 11 Jul 2002 22:55:33 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05877 for ; Thu, 11 Jul 2002 22:55:32 -0700 (PDT) Message-ID: <001b01c22967$8eb4f770$5d6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Vijay Devarapalli" Cc: "Charles E. Perkins" , "James Kempf" , "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32B6.2D1F2E4E@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 22:47:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, > > I don't think we can have a reasonable fast handover solution > > without relying at least on a link-up trigger on the mobile node. > > is the link-up trigger available on all mobile nodes? if the > answer is no, then we are stuck without a generic fast handover > solution. The answer is no (as expected :) But I think this can be fixed. And if a client wants to do fast handovers, it better be using one of those "fixed" wireless interfaces. If it doesn't have one, then it is stuck. It's not good to have such dependencies, but I think this time it's unavoidable... > > OTOH, with sufficiently fast router advertisements you can have > a reasonably fast handover. agreed, it is wont be as good when > you have a link-up trigger. How fast? Note that starting to hear another prefix doesn't mean that mobile node has handed over. This needs to be coupled with "not hearing your current prefix" as well. Also, people are even trying to avoid sending "any" unsolicited router advertisements over the air due to bandwidth and dormancy reasons... Sending high volume of such signaling is very problematic. This is not an acceptable solution, imo. > > but I didnt say you should not take help from a link-up trigger. > > seriously, do you think we can advance the FMIPv6 draft to a > Proposed Standard without having a L2 triggers specification? > anybody has an answer to this question? > > Vijay alper > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 01:57:07 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28149 for ; Fri, 12 Jul 2002 01:57:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24546; Thu, 11 Jul 2002 22:57:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28155; Thu, 11 Jul 2002 22:57:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C5uNoN004853 for ; Thu, 11 Jul 2002 22:56:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C5uNQo004852 for mobile-ip-dist; Thu, 11 Jul 2002 22:56:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C5uJoN004845 for ; Thu, 11 Jul 2002 22:56:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17844 for ; Thu, 11 Jul 2002 22:56:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12829 for ; Thu, 11 Jul 2002 23:56:27 -0600 (MDT) Message-ID: <002101c22968$087220b0$5d6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Charlie Perkins" Cc: References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32FD.D1888C8E@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 11 Jul 2002 22:50:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, > > I don't think we can have a reasonable fast handover solution > > without relying at least on a link-up trigger on the mobile node. > > But we have an implementation that shows otherwise. > > One can have an implementation that works well. > Sure. But some details are critical here. As I was asking Vijay, what is the advertisement frequency? How soon can the mobile node realize that it needs to handover? alper > > > I do agree that you can get better handover performance if you have > > > L2 triggers. but it is also important, IMO, that the fast handover > > > spec advances without having to depend on L2 triggers. > > > > > > Vijay > > > > > I also agree with this. > > I think we have to make the specification so that it works as > well as it can by itself, and it enables use of L2 triggers to > work better whenever the triggers are supported by the particular > link layer. > > Regards, > Charlie P. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 02:51:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08675 for ; Fri, 12 Jul 2002 02:51:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00123; Fri, 12 Jul 2002 00:51:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09508; Thu, 11 Jul 2002 23:51:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6oDoN005590 for ; Thu, 11 Jul 2002 23:50:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C6oDmB005589 for mobile-ip-dist; Thu, 11 Jul 2002 23:50:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6oAoN005582 for ; Thu, 11 Jul 2002 23:50:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01204 for ; Thu, 11 Jul 2002 23:50:09 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27127 for ; Fri, 12 Jul 2002 00:50:07 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 02:44:52 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] V6 fast handover Date: Fri, 12 Jul 2002 02:44:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So there are a couple of things that need to be addressed here. First there was some miscommunication in the handling of the update from version 4 to version 5. I fully accept responsibility for not paying enough attention to this communication to keep folks from getting upset. Raj sent a note saying that version 4 is the current consensus version and I agree with that. We will move to a version 5, but we have to be careful to get consensus about the changes that go into that doc before we go there. Let me take this opportunity to remind editors of working group documents about their role. What finally belongs in a working group document is subject to the consensus of the working group. The editor has a great deal of influence on what goes in and how it is presented. In circumstances when the content of a document is controversial the editor should take special care to discuss the proposed changes on the mailing list. Misunderstandings and mistakes will occur, and our last call processes and IESG review are the ultimate guardians against mistakes, but all of you who are editors can greatly help the smooth operation of the working group by paying particular care to the way you handle sensitive issues. Rajeev was making an effort to do this and a misunderstanding occured. Let's move on. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 02:54:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08772 for ; Fri, 12 Jul 2002 02:54:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10563; Fri, 12 Jul 2002 00:54:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29269; Thu, 11 Jul 2002 23:54:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6rUoN005688 for ; Thu, 11 Jul 2002 23:53:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C6rUx6005687 for mobile-ip-dist; Thu, 11 Jul 2002 23:53:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6rQoN005671 for ; Thu, 11 Jul 2002 23:53:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09733 for ; Thu, 11 Jul 2002 23:53:26 -0700 (PDT) Received: from r2d2.densitet.net ([195.84.15.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16401 for ; Fri, 12 Jul 2002 00:53:25 -0600 (MDT) Received: (from root@localhost) by r2d2.densitet.net (8.11.5/8.11.1) id g6C6rKe25952 for mobile-ip@sunroof.eng.sun.com; Fri, 12 Jul 2002 08:53:20 +0200 (CEST) (envelope-from t98pth@student.bth.se) Received: from student.bth.se (honung.rsn.bth.se [194.47.145.52]) by r2d2.densitet.net (8.11.5/8.11.1av) with ESMTP id g6C6rJu25944 for ; Fri, 12 Jul 2002 08:53:19 +0200 (CEST) (envelope-from t98pth@student.bth.se) Message-ID: <3D2E7CF9.1050202@student.bth.se> Date: Fri, 12 Jul 2002 08:53:45 +0200 From: =?ISO-8859-1?Q?P=E4r_Thor=E9n?= Organization: Student User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] LIN6 and MobileIPv6 X-Enigmail-Version: 0.60.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by Densitech AntiVirus Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi! What is the relationship between the LIN6 project (http://www.lin6.net/) and Mobile IPv6. Do they complement each other or do they compete with each other to produce a standard to support seamless host mobility support in IPv6? Any general comments on the LIN6 project? regards Pär From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 03:17:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09548 for ; Fri, 12 Jul 2002 03:17:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18328; Fri, 12 Jul 2002 01:17:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07250; Fri, 12 Jul 2002 00:16:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C7DLoN005943 for ; Fri, 12 Jul 2002 00:13:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C7DLdq005942 for mobile-ip-dist; Fri, 12 Jul 2002 00:13:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C7DIoN005935 for ; Fri, 12 Jul 2002 00:13:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06425 for ; Fri, 12 Jul 2002 00:13:18 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03623 for ; Fri, 12 Jul 2002 00:13:17 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 03:08:02 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] fast MIPv6 approach Date: Fri, 12 Jul 2002 03:07:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So there are a few. A short list might include: what is the role of layer 2 triggers in fast handoff operation? what is the significance of particular layer 2 capabilities/architecture/link characteristics? should the handoff operation be mobile controlled or network controlled? how fast is fast enough? So far we've tried to accommodate differences of opinion on these issues by the inclusion of various methods in the document and write a specification that allow the operation over technologies with different underlying capabilities and with different assumptions about the role of the network. It is difficult to believe that we're going to reach consensus as a working group on resolution of the above difficult issues. We can spend a lot of time arguing about it, but these disagreements were evident in the original design team and the recent discussion confirms they are still around. Could we step back and have a discussion on the meta issue of whether we should continue to have an approach of a single specification that covers all cases, or consider some approach to organizing the work that takes a new course? One way to go might be to have a base specification that described the tools needed for implementing fast handovers (messages and packet formats) and a few specifications that described fast handover for various kinds of network technologies. Experience with the latter could refine the former, and could certainly give very concrete specificity to the operation of the protocol in a particular environment. It could also help implementors of access routers determine what exactly needed to be implemented for interfaces that supported links on a particular technology. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 04:13:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11056 for ; Fri, 12 Jul 2002 04:13:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16073; Fri, 12 Jul 2002 02:13:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13766; Fri, 12 Jul 2002 01:13:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C89noN006284 for ; Fri, 12 Jul 2002 01:09:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C89nBh006283 for mobile-ip-dist; Fri, 12 Jul 2002 01:09:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C89koN006276 for ; Fri, 12 Jul 2002 01:09:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20377 for ; Fri, 12 Jul 2002 01:09:46 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06606 for ; Fri, 12 Jul 2002 02:09:45 -0600 (MDT) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA03582 for ; Fri, 12 Jul 2002 09:09:44 +0100 (BST) Received: from login (IDENT:lBdQEji98NAbdLb96bvCTBuRTaW8BY2M@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g6C89igA005274 for ; Fri, 12 Jul 2002 09:09:44 +0100 Date: Fri, 12 Jul 2002 09:09:44 +0100 (BST) From: Tim Chown To: mobile-ip@sunroof.eng.sun.com Subject: Re: {VIRUS?} [mobile-ip] Fw:mobile-ip,sos! In-Reply-To: <200207120226.LAA19126@mail1.beijingnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, The recent message titled "mibile-ip, sos" sent to the list, containing a virus, originated from a user on beijingnet.com. It appears that the virused user's address book was used to pick a bogus From: line, or maybe it's plain spam rather than a secondary virus? Perhpas the list owner can see if a beijingnet.com user is on the list and alert them. It's quite surprising how many recipient end systems send you virus alerts. Tim ---------- Date: Fri, 12 Jul 2002 11:26:13 +0900 (CDT) Message-Id: <200207120226.LAA19126@mail1.beijingnet.com> From: tjc To: mobile-ip@sunroof.eng.sun.com From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 08:21:53 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19037 for ; Fri, 12 Jul 2002 08:21:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08914; Fri, 12 Jul 2002 05:20:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01269; Fri, 12 Jul 2002 05:20:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CCImoN006741 for ; Fri, 12 Jul 2002 05:18:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CCIl2m006740 for mobile-ip-dist; Fri, 12 Jul 2002 05:18:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CCIioN006733 for ; Fri, 12 Jul 2002 05:18:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13273 for ; Fri, 12 Jul 2002 05:18:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29690 for ; Fri, 12 Jul 2002 05:18:45 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6CCIgK30959; Fri, 12 Jul 2002 15:18:42 +0300 Date: Fri, 12 Jul 2002 15:18:41 +0300 (EEST) From: Pekka Savola To: =?ISO-8859-1?Q?P=E4r_Thor=E9n?= cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LIN6 and MobileIPv6 In-Reply-To: <3D2E7CF9.1050202@student.bth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8BIT On Fri, 12 Jul 2002, Pär Thorén wrote: > Any general comments on the LIN6 project? Patented. Who cares? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 11:17:32 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27122 for ; Fri, 12 Jul 2002 11:17:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19914; Fri, 12 Jul 2002 08:16:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11008; Fri, 12 Jul 2002 08:16:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CFEfoN007056 for ; Fri, 12 Jul 2002 08:14:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CFEfGC007055 for mobile-ip-dist; Fri, 12 Jul 2002 08:14:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CFEboN007048 for ; Fri, 12 Jul 2002 08:14:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22732 for ; Fri, 12 Jul 2002 08:14:39 -0700 (PDT) Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06876 for ; Fri, 12 Jul 2002 09:14:38 -0600 (MDT) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 16:14:37 +0100 Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Jul 2002 16:14:37 +0100 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 16:14:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [mobile-ip] Minor comments on MIPv6 v18 draft Date: Fri, 12 Jul 2002 16:14:37 +0100 Message-ID: Thread-Topic: Minor comments on MIPv6 v18 draft Thread-Index: AcIptpve0XeTbxASRP2ho2LJuSAY1w== From: "Greg O'Shea" To: X-OriginalArrivalTime: 12 Jul 2002 15:14:37.0164 (UTC) FILETIME=[D60B32C0:01C229B6] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229B6.D6255106" ------_=_NextPart_001_01C229B6.D6255106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. The lifetimes of a BU and a BA are both encoded in 16-bit ints. The unit of a BU lifetime is 16secs and the unit of a BA lifetime is 4secs, so there are (large) valid BU lifetimes which are impossible to ack. (Or maybe I misunderstood something?) 2. The status code values in section 6.1.8 are out of sync with those in the body of the text e.g. see 9.5, 10.3, 10.2, 9.4.1, 11.6.1 Apologies if these are already known on the list. =20 ------_=_NextPart_001_01C229B6.D6255106 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minor comments on MIPv6 v18 draft

1. The lifetimes of a BU and a BA are = both encoded in 16-bit ints. The unit of a BU lifetime is 16secs and the = unit of a BA lifetime is 4secs, so there are (large) valid BU lifetimes = which are impossible to ack. (Or maybe I misunderstood = something?)

2. The status code values in section = 6.1.8 are out of sync with those in the body of the text e.g. see 9.5, = 10.3, 10.2, 9.4.1, 11.6.1

Apologies if these are already known on = the list.
 

------_=_NextPart_001_01C229B6.D6255106-- --------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 11:45:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28854 for ; Fri, 12 Jul 2002 11:45:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03170; Fri, 12 Jul 2002 08:41:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20243; Fri, 12 Jul 2002 08:41:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CFetoN007229 for ; Fri, 12 Jul 2002 08:40:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CFetL3007228 for mobile-ip-dist; Fri, 12 Jul 2002 08:40:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CFeqoN007221 for ; Fri, 12 Jul 2002 08:40:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20126 for ; Fri, 12 Jul 2002 08:40:53 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20075 for ; Fri, 12 Jul 2002 09:40:52 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 074176A901; Fri, 12 Jul 2002 18:40:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BC16D6A905; Fri, 12 Jul 2002 18:40:25 +0300 (EEST) Message-ID: <3D2EF8D2.2090406@kolumbus.fi> Date: Fri, 12 Jul 2002 18:42:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Greg O'Shea" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Minor comments on MIPv6 v18 draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg O'Shea wrote: > 1. The lifetimes of a BU and a BA are both encoded in 16-bit ints. The > unit of a BU lifetime is 16secs and the unit of a BA lifetime is 4secs, > so there are (large) valid BU lifetimes which are impossible to ack. (Or > maybe I misunderstood something?) This is a mistake. Both units should be 4 secs... a result of last-minute editing where we changed the units from 16->4s... this will be corrected. > 2. The status code values in section 6.1.8 are out of sync with those in > the body of the text e.g. see 9.5, 10.3, 10.2, 9.4.1, 11.6.1 Yet another editorial mistake. Will also be corrected. Thanks for pointing these out! This will be registered as issue #58. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 12:59:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03590 for ; Fri, 12 Jul 2002 12:59:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25760; Fri, 12 Jul 2002 10:59:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28024; Fri, 12 Jul 2002 09:59:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CGwGoN007475 for ; Fri, 12 Jul 2002 09:58:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CGwGRc007474 for mobile-ip-dist; Fri, 12 Jul 2002 09:58:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CGwDoN007467 for ; Fri, 12 Jul 2002 09:58:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21152 for ; Fri, 12 Jul 2002 09:58:15 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00010 for ; Fri, 12 Jul 2002 10:58:14 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CGwix11730 for ; Fri, 12 Jul 2002 11:58:44 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 11:58:10 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 11:58:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] V6 fast handover Date: Fri, 12 Jul 2002 11:58:06 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13141@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] V6 fast handover Thread-Index: AcIpcKABWLRJGPf3Qhqrq4YOYPVdWAAVD75A To: , X-OriginalArrivalTime: 12 Jul 2002 16:58:06.0884 (UTC) FILETIME=[4B534640:01C229C5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6CGwDoN007468 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit And to just add one more thing to what Phil said in his note: The changes to the fast handover draft in 05 are what is being proposed to the WG, as Rajeev (editor)has said in an earlier note. Of course the WG consensus is what will finally decide the content of this draft. > > > So there are a couple of things that need to be addressed here. > > First there was some miscommunication in the handling of the > update from > version 4 to version 5. I fully accept responsibility > for not paying enough attention to this communication to keep > folks from > getting upset. Raj sent a note saying that > version 4 is the current consensus version and I agree with > that. We will > move to a version 5, but we have to be careful > to get consensus about the changes that go into that doc > before we go there. > > Let me take this opportunity to remind editors of working > group documents > about their role. What finally belongs > in a working group document is subject to the consensus of the working > group. The editor has a great deal of influence > on what goes in and how it is presented. In circumstances > when the content > of a document is controversial the editor > should take special care to discuss the proposed changes on > the mailing > list. Misunderstandings and mistakes will > occur, and our last call processes and IESG review are the ultimate > guardians against mistakes, but all of you who are > editors can greatly help the smooth operation of the working > group by paying > particular care to the way you handle > sensitive issues. > > Rajeev was making an effort to do this and a misunderstanding occured. > Let's move on. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 13:32:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05075 for ; Fri, 12 Jul 2002 13:32:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04890; Fri, 12 Jul 2002 10:31:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28528; Fri, 12 Jul 2002 10:31:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHUMoN007683 for ; Fri, 12 Jul 2002 10:30:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CHUMfD007682 for mobile-ip-dist; Fri, 12 Jul 2002 10:30:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHUJoN007675 for ; Fri, 12 Jul 2002 10:30:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28131 for ; Fri, 12 Jul 2002 10:30:19 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29073 for ; Fri, 12 Jul 2002 10:30:19 -0700 (PDT) Message-ID: <003101c229c9$36190590$516015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" Cc: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2E2569.1837696B@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 10:25:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical > > for describing how Postregv6 (aka BETH) > > can be implemented. If there is some problem with too much reference to L2 > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > BTW, I still havent figured out how to implement L2 triggers on our > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > draft becomes a standard. right?? and the L2 triggers document does > not even have a permanent home (WG). > If you want to know how to implement L2 triggers, either I or Jon Wood can help you. I implemented them on the Solaris emulator and Jon on our Linux/BSD emulator. Jon is also in the process of implementing L2 triggered 802.11 handover, in a manner that is consistent with the 802.11 spec and doesn't depend on proprietary extensions. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 13:38:28 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05272 for ; Fri, 12 Jul 2002 13:38:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07558; Fri, 12 Jul 2002 10:37:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08171; Fri, 12 Jul 2002 10:37:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHaFoN007808 for ; Fri, 12 Jul 2002 10:36:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CHaFh8007807 for mobile-ip-dist; Fri, 12 Jul 2002 10:36:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHaCoN007798 for ; Fri, 12 Jul 2002 10:36:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07733 for ; Fri, 12 Jul 2002 10:36:12 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15588 for ; Fri, 12 Jul 2002 11:36:12 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g6CHYrO19699; Fri, 12 Jul 2002 12:34:53 -0500 (CDT) Message-ID: <3D2F135C.5060509@alcatel.com> Date: Fri, 12 Jul 2002 12:35:24 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie Perkins CC: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32FD.D1888C8E@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------070409000804090509050901" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------070409000804090509050901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I concur with Charlie. At the moment we do not know what will happen to L2 triggers in IETF. We expect that a decision will be made soon as to grant a BOF on this subject. It is not clear in my mind if the BOF happens and L2 triggers (on handover) which are already in some drafts become RFCs, would that cause a problem? What about the other cases? Regards, Charlie Perkins wrote: >Hello Alper, > >"Alper E. YEGIN" wrote: > >>I don't think we can have a reasonable fast handover solution >>without relying at least on a link-up trigger on the mobile node. >> > >But we have an implementation that shows otherwise. > >One can have an implementation that works well. > >>>I do agree that you can get better handover performance if you have >>>L2 triggers. but it is also important, IMO, that the fast handover >>>spec advances without having to depend on L2 triggers. >>> >>>Vijay >>> > >I also agree with this. > >I think we have to make the specification so that it works as >well as it can by itself, and it enables use of L2 triggers to >work better whenever the triggers are supported by the particular >link layer. > >Regards, >Charlie P. > > -- Behcet --------------070409000804090509050901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I concur with Charlie. At the moment we do not know what will happen to L2 triggers in IETF. We expect that a decision will be made soon as to grant a BOF on this subject.
  It is not clear in my mind if the BOF happens and L2 triggers (on handover) which are already in some drafts become RFCs, would that cause a problem? What about the other cases?

Regards,

Charlie Perkins wrote:
Hello Alper,

"Alper E. YEGIN" wrote:

I don't think we can have a reasonable fast handover solution
without relying at least on a link-up trigger on the mobile node.

But we have an implementation that shows otherwise.

One can have an implementation that works well.

I do agree that you can get better handover performance if you have
L2 triggers. but it is also important, IMO, that the fast handover
spec advances without having to depend on L2 triggers.

Vijay


I also agree with this.

I think we have to make the specification so that it works as
well as it can by itself, and it enables use of  L2 triggers to
work better whenever the triggers are supported by the particular
link layer.

Regards,
Charlie P.



-- 
Behcet

--------------070409000804090509050901-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 13:49:55 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05797 for ; Fri, 12 Jul 2002 13:49:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14612; Fri, 12 Jul 2002 10:47:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16492; Fri, 12 Jul 2002 10:47:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHkpoN007965 for ; Fri, 12 Jul 2002 10:46:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CHkpOW007964 for mobile-ip-dist; Fri, 12 Jul 2002 10:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHkmoN007957 for ; Fri, 12 Jul 2002 10:46:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16084 for ; Fri, 12 Jul 2002 10:46:49 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24050 for ; Fri, 12 Jul 2002 11:46:48 -0600 (MDT) Message-ID: <004c01c229cb$83d269a0$516015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" Cc: "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> <3D2E2C40.ECA04E5A@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 10:42:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, > thats because 'Tunnel termination' was a critical issue in BETH. the > BETH protocol does not work without it. it is not the case in > anticipated handover (as defind in draft 4) > > that is why. > As Ajoy said, we had working group concensus to include BETH. It is not acceptable to drop it from the draft without concensus to drop. Neither Ajoy nor I want it dropped. Furthermore, anticipated handover doesn't cover all cases. For link layers where the mobile node only finds out after it has moved, but before receiving a new RA beacon, i.e. reactive handover, the mobile should be able to set up the tunnel. The current draft only covers this as an error case. It must make clear that this is an acceptable alternative, and that no prehandover signaling is required (because there can't be any for reactive handover). > > Section 4: Interoperability between Prereg and Postreg was another hot issue. > > We've done lots of work in our implementation > > on this, and we now have what we think is a workable interoperability solution. > > This was completely eliminated from draft 05. > > thats because BETH was so different. it includes supressing router > adverts from the routers. you had a problem with respect to > interoperability between anticipated part and BETH part because the > MN and the access router needed to be told exactly which protocol > it was running. draft 05 has simplified that IMO. > The same point holds for a mobile node enabled to do Prereg but starting in a standard MIP coverage area. I don't think we want it hammering on the router with PrxyRtSol messages when the router doesn't understand them, especially not over a wireless link. The current draft has nothing to cover this. Furthermore, I believe there is working group concensus for including BETH with inter-router movement with RAs suppressed. It was included in draft 04. Again, it is not acceptable to drop this. This optimization is critical for low bandwidth, high latency links, and these are the kinds of links the wireless network operators care about because they are costly. 802.11 is not the same thing, it will work fine with over the air signaling as long as there are not too many mobiles in the cell. And the spectrum is free. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 13:52:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05895 for ; Fri, 12 Jul 2002 13:52:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24258; Fri, 12 Jul 2002 11:52:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15936; Fri, 12 Jul 2002 10:52:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHq3oN008090 for ; Fri, 12 Jul 2002 10:52:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CHq35n008089 for mobile-ip-dist; Fri, 12 Jul 2002 10:52:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHq0oN008082 for ; Fri, 12 Jul 2002 10:52:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06917 for ; Fri, 12 Jul 2002 10:52:00 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23869 for ; Fri, 12 Jul 2002 11:51:59 -0600 (MDT) Message-ID: <006801c229cc$10c1d1c0$516015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , "Alper E. YEGIN" Cc: "Charles E. Perkins" , "Rajeev Koodli" , References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32B6.2D1F2E4E@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 10:46:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > seriously, do you think we can advance the FMIPv6 draft to a > Proposed Standard without having a L2 triggers specification? > anybody has an answer to this question? > I think the MIPv6 fast handovers draft needs to specify the interaction with Layer 2 in an abstract sense, as Charlie and I were discussing yesterday. Whether that requires a specific L2 triggers specification is another issue. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 13:54:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05982 for ; Fri, 12 Jul 2002 13:54:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01418; Fri, 12 Jul 2002 11:54:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08087; Fri, 12 Jul 2002 10:54:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHruoN008164 for ; Fri, 12 Jul 2002 10:53:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CHrtS3008163 for mobile-ip-dist; Fri, 12 Jul 2002 10:53:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CHrqoN008153 for ; Fri, 12 Jul 2002 10:53:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16464 for ; Fri, 12 Jul 2002 10:53:53 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14993 for ; Fri, 12 Jul 2002 10:53:52 -0700 (PDT) Message-ID: <007a01c229cc$ae9a4c10$516015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , "Alper E. YEGIN" Cc: References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32FD.D1888C8E@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 10:50:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, > I think we have to make the specification so that it works as > well as it can by itself, and it enables use of L2 triggers to > work better whenever the triggers are supported by the particular > link layer. > Can you give me an example of how a mobile node might hand over without any help from L2? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 14:16:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06894 for ; Fri, 12 Jul 2002 14:16:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12128; Fri, 12 Jul 2002 12:16:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27197; Fri, 12 Jul 2002 11:16:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CIEroN008388 for ; Fri, 12 Jul 2002 11:14:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CIErix008387 for mobile-ip-dist; Fri, 12 Jul 2002 11:14:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CIEooN008380 for ; Fri, 12 Jul 2002 11:14:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26700 for ; Fri, 12 Jul 2002 11:14:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07572 for ; Fri, 12 Jul 2002 12:14:50 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA04029; Fri, 12 Jul 2002 11:14:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CIEn727472; Fri, 12 Jul 2002 11:14:49 -0700 X-mProtect: <200207121814> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjoenca; Fri, 12 Jul 2002 11:14:47 PDT Message-ID: <3D2F1C97.3CABBEA7@iprg.nokia.com> Date: Fri, 12 Jul 2002 11:14:47 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC231.A45F988F@iprg.nokia.com> <011401c2290d$6f6726e0$8b6015ac@AlperVAIO> <3D2E28CE.41CE0D10@iprg.nokia.com> <04a601c22942$23b881f0$8b6015ac@AlperVAIO> <3D2E32FD. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, I can give an example, and I will do so, but I think the danger would be that then the example would become the point of contention, diverting attention from what is really important. I think what is really important is to get to the point where: 1) The layer-3 protocol supports the required functionality 2) The layer-3 protocol supports replacement of some of the layer-3 signaling by layer-2 signaling (e.g., "L2 trigger") 3) The layer-3 protocol supports as many layer-2s as is possible, including low-bandwidth links (e.g., < 10kb/s). Here is my example: Suppose the access routers are beaconing 60 times per second, and the mobile node hears a new beacon. Then it can solicit a handover from the previous access router and get packets delivered to the new access router within 25 ms of the time it first moved within range of the new access router. In this example, source triggers, target triggers, and mobile triggers from Layer 2 can all act to improve the performance and/or eliminate the need for beaconing. There are plenty of variations, depending on whether you like mobile-controlled or network-controlled, or whether your physical medium doesn't have enough bandwidth for the beacons, or whether the handover is reactive or predictive, or ... However, all of these cases can be served by the existing fast handover document as I understand it to have evolved from the original design team document. What is needed, as you have mentioned before, is the clean description of how layer-2 signals can cause layer-3 actions that otherwise would require layer-3 signals to have occurred. Regards, Charlie P. PS. I guess your mailer doesn't like newlines as much as mine. I hope you don't mind if I put one of them into your message text. James Kempf wrote: > > Charlie, > > > I think we have to make the specification so that it works as > > well as it can by itself, and it enables use of L2 triggers to > > work better whenever the triggers are supported by the particular > > link layer. > > > > Can you give me an example of how a mobile node might hand over > without any help from L2? > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 14:49:08 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08434 for ; Fri, 12 Jul 2002 14:49:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18096; Fri, 12 Jul 2002 11:46:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29640; Fri, 12 Jul 2002 11:46:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CIj9oN008579 for ; Fri, 12 Jul 2002 11:45:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CIj9vX008578 for mobile-ip-dist; Fri, 12 Jul 2002 11:45:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CIj6oN008571 for ; Fri, 12 Jul 2002 11:45:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28557 for ; Fri, 12 Jul 2002 11:45:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11814 for ; Fri, 12 Jul 2002 11:45:07 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA05924; Fri, 12 Jul 2002 11:45:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CIj5502894; Fri, 12 Jul 2002 11:45:05 -0700 X-mProtect: <200207121845> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzVCKC5; Fri, 12 Jul 2002 11:45:03 PDT Message-ID: <3D2F23B0.B9E22905@iprg.nokia.com> Date: Fri, 12 Jul 2002 11:45:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2E2569.1837696B@iprg.nokia.com> <003101c229c9$36190590$516015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > If you want to know how to implement L2 triggers, either I or Jon Wood can help you. I implemented them on the Solaris > emulator and Jon on our Linux/BSD emulator. this was done on an emulator. > Jon is also in the process of > implementing L2 triggered 802.11 handover, in a > manner that is consistent with the 802.11 spec and doesn't depend on proprietary extensions. but that needs to be specified somewhere, right? are they IP messages? Jim, I am not against using L2 triggers. I use them too (I use the L2-up trigger at the MN). but what I also want to see is FMIPv6 advancing without having to depend on L2 triggers. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 15:05:04 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09405 for ; Fri, 12 Jul 2002 15:05:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21603; Fri, 12 Jul 2002 12:03:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06230; Fri, 12 Jul 2002 12:03:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ29oN008765 for ; Fri, 12 Jul 2002 12:02:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CJ29QI008764 for mobile-ip-dist; Fri, 12 Jul 2002 12:02:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ24oN008757 for ; Fri, 12 Jul 2002 12:02:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05697 for ; Fri, 12 Jul 2002 12:02:05 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25549 for ; Fri, 12 Jul 2002 12:02:01 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA11667 for ; Fri, 12 Jul 2002 12:02:00 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA14193 for ; Fri, 12 Jul 2002 12:02:00 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 12 Jul 2002 14:01:59 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Vijay Devarapalli Cc: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 14:01:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Vijay, We have implemented FMIPv4 in our prototype 3G Cellular testbed. We have implemented both source as well as target triggers required to support Post-Reg (FMIPv4 version of BETH). So, I do not understand why are you complaining about L2 triggers? BTW, can you explain how can you implement FMIPv6 without using Link layer triggers? regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 12, 2002 12:26 PM To: Vijay Devarapalli Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical > > for describing how Postregv6 (aka BETH) > > can be implemented. If there is some problem with too much reference to L2 > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > BTW, I still havent figured out how to implement L2 triggers on our > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > draft becomes a standard. right?? and the L2 triggers document does > not even have a permanent home (WG). > If you want to know how to implement L2 triggers, either I or Jon Wood can help you. I implemented them on the Solaris emulator and Jon on our Linux/BSD emulator. Jon is also in the process of implementing L2 triggered 802.11 handover, in a manner that is consistent with the 802.11 spec and doesn't depend on proprietary extensions. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 15:07:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09536 for ; Fri, 12 Jul 2002 15:07:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27633; Fri, 12 Jul 2002 12:06:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21713; Fri, 12 Jul 2002 12:06:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ5FoN008836 for ; Fri, 12 Jul 2002 12:05:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CJ5FUl008835 for mobile-ip-dist; Fri, 12 Jul 2002 12:05:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ58oN008827 for ; Fri, 12 Jul 2002 12:05:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07123 for ; Fri, 12 Jul 2002 12:05:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09958 for ; Fri, 12 Jul 2002 13:05:08 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA07192; Fri, 12 Jul 2002 12:05:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CJ56j03462; Fri, 12 Jul 2002 12:05:06 -0700 X-mProtect: <200207121905> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzipqrB; Fri, 12 Jul 2002 12:05:03 PDT Message-ID: <3D2F285F.F0472B9B@iprg.nokia.com> Date: Fri, 12 Jul 2002 12:05:03 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2CE2AE.715A0F9F@iprg.nokia.com> <011101c228fb$61f84c80$4f6015ac@T23KEMPF> <3D2DC3CF.DF289243@iprg.nokia.com> <028301c22909$c4ea0230$4f6015ac@T23KEMPF> <3D2E2C40.ECA04E5A@iprg.nokia.com> <004c01c229cb$83d269a0$516015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > Vijay, > > > thats because 'Tunnel termination' was a critical issue in BETH. the > > BETH protocol does not work without it. it is not the case in > > anticipated handover (as defind in draft 4) > > > > that is why. > > > > As Ajoy said, we had working group concensus to include BETH. It is not acceptable to drop it from the draft without > concensus to drop. Neither Ajoy nor I want it dropped. Jim, what was dropped was the description how to setup tunnels between access routers using L2 triggers. you can set up tunnels between access routers based on explicit signaling. that is there in draft 5. what we now need to do now is make sure we can take advantage of L2 triggers when they are available. > Furthermore, anticipated handover doesn't cover all cases. For link layers where the mobile node only finds out after it has > moved, but before receiving a new RA beacon, i.e. reactive handover, the mobile should be able to set up the tunnel. The > current draft only covers this as an error case. It must make clear that this is an acceptable alternative, and that no > prehandover signaling is required (because there can't be any for reactive handover). Rajeev has already agreed to this. I think it can be made more explicit. > The same point holds for a mobile node enabled to do Prereg but starting in a standard MIP coverage area. no it doesnt. in the first place, FMIPv6 draft 5 does not affect MIPv6 draft 18 functionality on a MN. please let me know if I am missing something. > I don't think we > want it hammering on the router with PrxyRtSol messages when the router doesn't understand them, especially not over a > wireless link. The current draft has nothing to cover this. thats not right. the current draft tells you not to hammer the access router with PrxyRtSol. from Section 5.1.1 in draft 5 A MN sends this message if it wishes to initiate fast handover. It indicates its destination with the New Attachment Point Link-Layer Address. A Proxy Router Advertisement message should be received in response. If such a message is not received in a short time period but no less than twice the typical round trip time (RTT) over the access link or 100 ms if RTT is not known, it SHOULD resend RtSolPr message at most twice, waiting for the same time during each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD attempt to send FBU as described in Section 4.1. A proxy router solicitation is resent atmost twice. > Furthermore, I believe there is working group concensus for including BETH with inter-router movement with RAs suppressed. It > was included in draft 04. Again, it is not acceptable to drop this. I am not disputing that there was WG concensus to include BETH. my point was tunnel termination and suppressed RAs were central for BETH to work. they are not needed for a generic FMIPv6 solution to work. > This optimization is critical for low bandwidth, high > latency links, and these are the kinds of links the wireless network operators care about because they are costly. 802.11 is > not the same thing, it will work fine with over the air signaling as long as there are not too many mobiles in the cell. And > the spectrum is free. why did you assume I am talking about 802.11? its true that our prototype is based on 802.11 (yours as well). thats because that is what is feasible in a lab. I am concerned about cellular operators too. I work for Nokia. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 15:09:19 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09591 for ; Fri, 12 Jul 2002 15:09:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05451; Fri, 12 Jul 2002 13:09:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08738; Fri, 12 Jul 2002 12:09:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ8KoN009014 for ; Fri, 12 Jul 2002 12:08:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CJ8JDY009013 for mobile-ip-dist; Fri, 12 Jul 2002 12:08:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJ8FoN008999 for ; Fri, 12 Jul 2002 12:08:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22442 for ; Fri, 12 Jul 2002 12:08:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04012 for ; Fri, 12 Jul 2002 13:08:16 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA07407; Fri, 12 Jul 2002 12:08:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CJ8Ei08634; Fri, 12 Jul 2002 12:08:14 -0700 X-mProtect: <200207121908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv8YnXx; Fri, 12 Jul 2002 12:08:13 PDT Message-ID: <3D2F291E.B8516A1@iprg.nokia.com> Date: Fri, 12 Jul 2002 12:08:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ajoy, you got me wrong. I am not against using L2 triggers. I know you need them to get the most optimized handovers. but we also need a generic FMIPv6 solution (I dont know how manys times I have said this now) that does not depend on L2 triggers. we need an RFC soon (dont you?). Vijay Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > We have implemented both source as well as target triggers required > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > why are you complaining about L2 triggers? BTW, can you explain how > can you implement FMIPv6 without using Link layer triggers? > regards, > ajoy > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 12, 2002 12:26 PM > To: Vijay Devarapalli > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These > are critical > > > for describing how Postregv6 (aka BETH) > > > can be implemented. If there is some problem with too much reference to > L2 > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > BTW, I still havent figured out how to implement L2 triggers on our > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > draft becomes a standard. right?? and the L2 triggers document does > > not even have a permanent home (WG). > > > > If you want to know how to implement L2 triggers, either I or Jon Wood can > help you. I implemented them on the Solaris > emulator and Jon on our Linux/BSD emulator. Jon is also in the process of > implementing L2 triggered 802.11 handover, in a > manner that is consistent with the 802.11 spec and doesn't depend on > proprietary extensions. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 15:27:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10717 for ; Fri, 12 Jul 2002 15:27:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20140; Fri, 12 Jul 2002 13:27:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00396; Fri, 12 Jul 2002 12:27:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJQioN009191 for ; Fri, 12 Jul 2002 12:26:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CJQhlo009190 for mobile-ip-dist; Fri, 12 Jul 2002 12:26:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CJQeoN009183 for ; Fri, 12 Jul 2002 12:26:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00053 for ; Fri, 12 Jul 2002 12:26:42 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06396 for ; Fri, 12 Jul 2002 12:26:41 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA11096 for ; Fri, 12 Jul 2002 12:26:41 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA27063 for ; Fri, 12 Jul 2002 12:26:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ49K8>; Fri, 12 Jul 2002 14:26:41 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 14:26:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Vijay, Thanks for your email. BTW, can you please explain how can we implement fast handoff without any link layer support? I also do not understand why standardization of FMIPv6 will get delayed because of L2 triggers. Is it not enough to document various L2 triggers and the actions to be taken based upon the L2 triggers? Do we need anything more than this? regards, ajoy -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Friday, July 12, 2002 2:08 PM To: Singh Ajoy-ASINGH1 Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, you got me wrong. I am not against using L2 triggers. I know you need them to get the most optimized handovers. but we also need a generic FMIPv6 solution (I dont know how manys times I have said this now) that does not depend on L2 triggers. we need an RFC soon (dont you?). Vijay Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > We have implemented both source as well as target triggers required > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > why are you complaining about L2 triggers? BTW, can you explain how > can you implement FMIPv6 without using Link layer triggers? > regards, > ajoy > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 12, 2002 12:26 PM > To: Vijay Devarapalli > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These > are critical > > > for describing how Postregv6 (aka BETH) > > > can be implemented. If there is some problem with too much reference to > L2 > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > BTW, I still havent figured out how to implement L2 triggers on our > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > draft becomes a standard. right?? and the L2 triggers document does > > not even have a permanent home (WG). > > > > If you want to know how to implement L2 triggers, either I or Jon Wood can > help you. I implemented them on the Solaris > emulator and Jon on our Linux/BSD emulator. Jon is also in the process of > implementing L2 triggered 802.11 handover, in a > manner that is consistent with the 802.11 spec and doesn't depend on > proprietary extensions. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 16:22:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13388 for ; Fri, 12 Jul 2002 16:22:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15362; Fri, 12 Jul 2002 14:22:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17848; Fri, 12 Jul 2002 13:22:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CKLkoN009378 for ; Fri, 12 Jul 2002 13:21:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CKLkxA009377 for mobile-ip-dist; Fri, 12 Jul 2002 13:21:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CKLhoN009370 for ; Fri, 12 Jul 2002 13:21:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17498 for ; Fri, 12 Jul 2002 13:21:45 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29939 for ; Fri, 12 Jul 2002 13:21:44 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CKPRj00526 for ; Fri, 12 Jul 2002 15:25:27 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 15:21:40 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 15:21:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 15:21:27 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13149@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Fast Handover draft: proposed revisions Thread-Index: AcIp2jew8sGWVomeT3aPDuYcQapoqgABpUsA To: , Cc: , , X-OriginalArrivalTime: 12 Jul 2002 20:21:27.0801 (UTC) FILETIME=[B3A37690:01C229E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6CKLhoN009371 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit The Fast HO draft is not intended to specify L2 triggers. Its primary focus is on L3 signaling to enable MIPv6 nodes to perform fast HOs. I guess everybody acknowledges that it is dependent on L2 triggers but in terms of what is actually specified in the base draft w.r.t L2 triggers can be quite abstract. The draft can simply say that a certain type of HO or signaling is initiated as a result of some trigger from L2. Other drafts can specify what triggers and how fast HO is done for specific link layers. I do not believe that this draft is the one that should be specifying what L2 triggers exist that are the basis for fast HO. > > Hello Vijay, > Thanks for your email. BTW, can you please > explain how can we implement fast handoff without > any link layer support? I also do not understand > why standardization of FMIPv6 will get delayed > because of L2 triggers. Is it not enough to > document various L2 triggers and the actions to be taken > based upon the L2 triggers? Do we need anything more than this? > regards, > ajoy > > > Ajoy, > > you got me wrong. I am not against using L2 triggers. I know you > need them to get the most optimized handovers. but we also need > a generic FMIPv6 solution (I dont know how manys times I have > said this now) that does not depend on L2 triggers. we need an > RFC soon (dont you?). > > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:07:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14638 for ; Fri, 12 Jul 2002 17:07:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18099; Fri, 12 Jul 2002 14:05:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05962; Fri, 12 Jul 2002 14:05:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CL4goN009554 for ; Fri, 12 Jul 2002 14:04:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CL4gjT009553 for mobile-ip-dist; Fri, 12 Jul 2002 14:04:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CL4coN009546 for ; Fri, 12 Jul 2002 14:04:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17857 for ; Fri, 12 Jul 2002 14:04:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26090 for ; Fri, 12 Jul 2002 15:04:38 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA13837; Fri, 12 Jul 2002 14:04:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CL4Yx11657; Fri, 12 Jul 2002 14:04:34 -0700 X-mProtect: <200207122104> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdG9ahb5; Fri, 12 Jul 2002 14:04:32 PDT Message-ID: <3D2F4461.F1F8E22B@iprg.nokia.com> Date: Fri, 12 Jul 2002 14:04:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Ajoy , I think Raj's email answers your question. I am afraid Section 3.2.1 of draft 4 will hold back the draft from advancing unless there is a standard way of doing L2-ST, L2-TT, L2-LD, L2-LU. even if there is a standard way of doing the triggers, there has to be some kind of reference that FMIPv6 can quote. I am afraid that is not there (or wont there when we need to advance FMIPv6) take a look at the following mail from Jack McCann, I just saw in the IPv6 WG. I hope I am not doing anything wrong by cutting and pasting this mail > The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) > contains normative references to the Scoped Addressing Architecture > (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies > on the definition of zone indices, and on the scoped address text > format defined in that document. This was flagged as an issue > during IESG review. > > To allow 2553bis to move forward and be published as an RFC without > having to wait on the scoping-arch document, we've proposed to move > those portions of the Basic API that rely on scoping-arch into a > separate document that can advance alongside the scoping-arch document. > > There are 4 items that will move from 2553bis to the new "scoping api" > document: > > 1. References to the terms "link index" and "site index" in > the definition of the sin6_scope_id field. Note that the > sin6_scope_id field will remain in 2553bis. > > 2. Use of the scoped address text format with getaddrinfo(). > > 3. Use of the scoped address text format with getnameinfo(). > > 4. The NI_NUMERICSCOPE flag. > draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the IPv6 WG, but not an RFC yet. because of this, it cannot be referenced in the API draft. L2 triggers draft has not been adopted by any WG. do you see the danger?? please dont conclude I am spreading FUD. this is a real concern. Vijay Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > Thanks for your email. BTW, can you please > explain how can we implement fast handoff without > any link layer support? I also do not understand > why standardization of FMIPv6 will get delayed > because of L2 triggers. Is it not enough to > document various L2 triggers and the actions to be taken > based upon the L2 triggers? Do we need anything more than this? > regards, > ajoy > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, July 12, 2002 2:08 PM > To: Singh Ajoy-ASINGH1 > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > Ajoy, > > you got me wrong. I am not against using L2 triggers. I know you > need them to get the most optimized handovers. but we also need > a generic FMIPv6 solution (I dont know how manys times I have > said this now) that does not depend on L2 triggers. we need an > RFC soon (dont you?). > > Vijay > > Singh Ajoy-ASINGH1 wrote: > > > > Hello Vijay, > > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > > We have implemented both source as well as target triggers required > > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > > why are you complaining about L2 triggers? BTW, can you explain how > > can you implement FMIPv6 without using Link layer triggers? > > regards, > > ajoy > > > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 12, 2002 12:26 PM > > To: Vijay Devarapalli > > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These > > are critical > > > > for describing how Postregv6 (aka BETH) > > > > can be implemented. If there is some problem with too much reference > to > > L2 > > > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > > BTW, I still havent figured out how to implement L2 triggers on our > > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > > draft becomes a standard. right?? and the L2 triggers document does > > > not even have a permanent home (WG). > > > > > > > If you want to know how to implement L2 triggers, either I or Jon Wood can > > help you. I implemented them on the Solaris > > emulator and Jon on our Linux/BSD emulator. Jon is also in the process of > > implementing L2 triggered 802.11 handover, in a > > manner that is consistent with the 802.11 spec and doesn't depend on > > proprietary extensions. > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:13:35 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14878 for ; Fri, 12 Jul 2002 17:13:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09809; Fri, 12 Jul 2002 15:13:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13244; Fri, 12 Jul 2002 14:12:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLCBoN009702 for ; Fri, 12 Jul 2002 14:12:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CLCBrU009701 for mobile-ip-dist; Fri, 12 Jul 2002 14:12:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLC7oN009694 for ; Fri, 12 Jul 2002 14:12:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20472 for ; Fri, 12 Jul 2002 14:12:07 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02486 for ; Fri, 12 Jul 2002 15:12:07 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA00570 for ; Fri, 12 Jul 2002 14:12:27 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA11622 for ; Fri, 12 Jul 2002 14:10:55 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 12 Jul 2002 16:12:04 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Basavaraj.Patil@nokia.com'" , Singh Ajoy-ASINGH1 , vijayd@iprg.nokia.com Cc: kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 16:11:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Basavraj, I am not asking to specify L2 trigger in fast handoff draft. We just have to state the appropriate L3 behaviors when specific link layer triggers are available. BTW, that is what is done in version V4 of the FMIPv6 draft. regards, ajoy -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Friday, July 12, 2002 3:21 PM To: Ajoy Singh; vijayd@iprg.nokia.com Cc: kempf@docomolabs-usa.com; rajeev@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions The Fast HO draft is not intended to specify L2 triggers. Its primary focus is on L3 signaling to enable MIPv6 nodes to perform fast HOs. I guess everybody acknowledges that it is dependent on L2 triggers but in terms of what is actually specified in the base draft w.r.t L2 triggers can be quite abstract. The draft can simply say that a certain type of HO or signaling is initiated as a result of some trigger from L2. Other drafts can specify what triggers and how fast HO is done for specific link layers. I do not believe that this draft is the one that should be specifying what L2 triggers exist that are the basis for fast HO. > > Hello Vijay, > Thanks for your email. BTW, can you please > explain how can we implement fast handoff without > any link layer support? I also do not understand > why standardization of FMIPv6 will get delayed > because of L2 triggers. Is it not enough to > document various L2 triggers and the actions to be taken > based upon the L2 triggers? Do we need anything more than this? > regards, > ajoy > > > Ajoy, > > you got me wrong. I am not against using L2 triggers. I know you > need them to get the most optimized handovers. but we also need > a generic FMIPv6 solution (I dont know how manys times I have > said this now) that does not depend on L2 triggers. we need an > RFC soon (dont you?). > > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:24:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15279 for ; Fri, 12 Jul 2002 17:24:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15083; Fri, 12 Jul 2002 15:24:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24875; Fri, 12 Jul 2002 14:24:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLN2oN009841 for ; Fri, 12 Jul 2002 14:23:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CLN25c009840 for mobile-ip-dist; Fri, 12 Jul 2002 14:23:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLMxoN009833 for ; Fri, 12 Jul 2002 14:22:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18319 for ; Fri, 12 Jul 2002 14:23:00 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25857 for ; Fri, 12 Jul 2002 14:22:59 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CLQgj09030 for ; Fri, 12 Jul 2002 16:26:42 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 16:22:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 16:22:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 16:22:37 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440969AF@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Fast Handover draft: proposed revisions Thread-Index: AcIp6MkmXRqSxQqoRQWbxj4trzeBywAAIUoA To: , Cc: , , X-OriginalArrivalTime: 12 Jul 2002 21:22:38.0111 (UTC) FILETIME=[3F5052F0:01C229EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6CLMxoN009834 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Ajoy, > > Basavraj, > I am not asking to specify L2 trigger in fast handoff draft. > We just have to state the appropriate L3 behaviors when > specific link layer triggers are available. BTW, that is what I think we are agreeing on the general approach on how to deal with triggers. All I am saying is that if link layer X provides specific triggers to the upper layer, a separate I-D can document how fast HO will work when these triggers (which would be identified in that draft) are available. So rather than going down the path of identifying all the possible link layer triggers and the corresponding behavior at L3, the base FMIPv6 draft should simply document the L3 behavior. > is done in version V4 of the FMIPv6 draft. And my belief is that the current L2 triggers specification in the version 4 of the draft is of really no help and needs to be moved to a more appropriate draft that deals with these triggers,. > regards, > ajoy > Cheers, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:47:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15926 for ; Fri, 12 Jul 2002 17:47:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18005; Fri, 12 Jul 2002 15:47:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28671; Fri, 12 Jul 2002 14:47:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLkXoN010005 for ; Fri, 12 Jul 2002 14:46:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CLkXRG010004 for mobile-ip-dist; Fri, 12 Jul 2002 14:46:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLkUoN009997 for ; Fri, 12 Jul 2002 14:46:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21529 for ; Fri, 12 Jul 2002 14:46:31 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25244 for ; Fri, 12 Jul 2002 15:46:30 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA08956 for ; Fri, 12 Jul 2002 14:46:30 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA09414 for ; Fri, 12 Jul 2002 14:46:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZVCD6>; Fri, 12 Jul 2002 16:46:29 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Basavaraj.Patil@nokia.com'" , Singh Ajoy-ASINGH1 , vijayd@iprg.nokia.com Cc: kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 16:46:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Basavraj, Please find my inline reply. regards, ajoy So rather than going down the path of identifying all the possible link layer triggers and the corresponding behavior at L3, the base FMIPv6 draft should simply document the L3 behavior. Ajoy-> I disagree with this. We have to document important triggers at MN, oAR, nAR. Without such documentation, how can we specify fast handoff scheme. Even in case of anticipated handover, we need L2 trigger either at MN or oAR. It will be highly confusing to describe fast handoff without mentioning such triggers. BTW, I agree we do not have to explain how such triggers will be available at MN, oAR or nAR? This can be done in separate ID or may be left for implementers. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Friday, July 12, 2002 4:23 PM To: Ajoy Singh; vijayd@iprg.nokia.com Cc: kempf@docomolabs-usa.com; rajeev@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, > > Basavraj, > I am not asking to specify L2 trigger in fast handoff draft. > We just have to state the appropriate L3 behaviors when > specific link layer triggers are available. BTW, that is what I think we are agreeing on the general approach on how to deal with triggers. All I am saying is that if link layer X provides specific triggers to the upper layer, a separate I-D can document how fast HO will work when these triggers (which would be identified in that draft) are available. So rather than going down the path of identifying all the possible link layer triggers and the corresponding behavior at L3, the base FMIPv6 draft should simply document the L3 behavior. > is done in version V4 of the FMIPv6 draft. And my belief is that the current L2 triggers specification in the version 4 of the draft is of really no help and needs to be moved to a more appropriate draft that deals with these triggers,. > regards, > ajoy > Cheers, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:47:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15941 for ; Fri, 12 Jul 2002 17:47:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26066; Fri, 12 Jul 2002 15:48:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28802; Fri, 12 Jul 2002 14:48:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLl0oN010015 for ; Fri, 12 Jul 2002 14:47:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CLkxZ9010014 for mobile-ip-dist; Fri, 12 Jul 2002 14:46:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLkuoN010007 for ; Fri, 12 Jul 2002 14:46:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28232 for ; Fri, 12 Jul 2002 14:46:56 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16758 for ; Fri, 12 Jul 2002 15:46:56 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g6CLklK14712; Fri, 12 Jul 2002 16:46:48 -0500 (CDT) Message-ID: <3D2F4E65.5080505@alcatel.com> Date: Fri, 12 Jul 2002 16:47:17 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: ASINGH1@motorola.com, vijayd@iprg.nokia.com, kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <697DAA22C5004B4596E033803A7CEF440969AF@daebe007.NOE.Nokia.com> Content-Type: multipart/alternative; boundary="------------050403020201050700010901" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------050403020201050700010901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Raj, I completely agree with you. Regards, Basavaraj.Patil@nokia.com wrote: >Ajoy, > >>Basavraj, >>I am not asking to specify L2 trigger in fast handoff draft. >>We just have to state the appropriate L3 behaviors when >>specific link layer triggers are available. BTW, that is what >> > >I think we are agreeing on the general approach on how to deal >with triggers. All I am saying is that if link layer X provides >specific triggers to the upper layer, a separate I-D can >document how fast HO will work when these triggers (which would >be identified in that draft) are available. >So rather than going down the path of identifying all the possible >link layer triggers and the corresponding behavior at L3, the >base FMIPv6 draft should simply document the L3 behavior. > >>is done in version V4 of the FMIPv6 draft. >> > >And my belief is that the current L2 triggers specification in the >version 4 of the draft is of really no help and needs to be moved >to a more appropriate draft that deals with these triggers,. > >>regards, >>ajoy >> > >Cheers, >-Basavaraj > > -- Behcet --------------050403020201050700010901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Raj,
  I completely agree with you.

Regards,

Basavaraj.Patil@nokia.com wrote:
Ajoy,

Basavraj,
I am not asking to specify L2 trigger in fast handoff draft.
We just have to state the appropriate L3 behaviors when 
specific link layer triggers are available. BTW, that is what 

I think we are agreeing on the general approach on how to deal
with triggers. All I am saying is that if link layer X provides
specific triggers to the upper layer, a separate I-D can
document how fast HO will work when these triggers (which would
be identified in that draft) are available. 
So rather than going down the path of identifying all the possible
link layer triggers and the corresponding behavior at L3, the
base FMIPv6 draft should simply document the L3 behavior.

is done in version V4 of the FMIPv6 draft. 

And my belief is that the current L2 triggers specification in the
version 4 of the draft is of really no help and needs to be moved
to a more appropriate draft that deals with these triggers,.

regards,
ajoy 


Cheers,
-Basavaraj



-- 
Behcet

--------------050403020201050700010901-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 17:57:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16232 for ; Fri, 12 Jul 2002 17:57:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10989; Fri, 12 Jul 2002 14:55:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25621; Fri, 12 Jul 2002 14:55:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLsnoN010282 for ; Fri, 12 Jul 2002 14:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CLsm9P010281 for mobile-ip-dist; Fri, 12 Jul 2002 14:54:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CLsjoN010274 for ; Fri, 12 Jul 2002 14:54:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25202 for ; Fri, 12 Jul 2002 14:54:46 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19713 for ; Fri, 12 Jul 2002 15:54:45 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA15736 for ; Fri, 12 Jul 2002 14:54:44 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA22198 for ; Fri, 12 Jul 2002 14:54:56 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 12 Jul 2002 16:54:44 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Vijay Devarapalli'" , Singh Ajoy-ASINGH1 Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 16:52:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Vijay, You have not answered my question yet. BTW, I do not see any difference in BETH as well as anticipated handover scheme in this respect. Both of them need L2 triggers to enable fast handoff. In case of anticipated handover, we need L2 trigger either at MN or oAR. Please find the following text from the current fast handoff draft: 3.1.6. Mobile Initiated Handover The main difference between mobile initiated network initiated handover is that, in mobile initiated handover, MN receives predictive information about the Layer 2 handover. The MN MUST send a RtSolPr message to the oAR to trigger the PrRtAdv. 3.1.2. Network Initated Handover In network initiated handover, the oAR receives an indication that the MN is about to move and information on the nAR to which the MN will be moved. Both stateless and stateful nCoA configuration are supported, as is use of the oCoA. I do not really see why are you so opposed to 3.2.1 of the FMIPv6 (Version V4) draft ? regards, ajoy -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Friday, July 12, 2002 4:05 PM To: Singh Ajoy-ASINGH1 Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions hi Ajoy , I think Raj's email answers your question. I am afraid Section 3.2.1 of draft 4 will hold back the draft from advancing unless there is a standard way of doing L2-ST, L2-TT, L2-LD, L2-LU. even if there is a standard way of doing the triggers, there has to be some kind of reference that FMIPv6 can quote. I am afraid that is not there (or wont there when we need to advance FMIPv6) take a look at the following mail from Jack McCann, I just saw in the IPv6 WG. I hope I am not doing anything wrong by cutting and pasting this mail > The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) > contains normative references to the Scoped Addressing Architecture > (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies > on the definition of zone indices, and on the scoped address text > format defined in that document. This was flagged as an issue > during IESG review. > > To allow 2553bis to move forward and be published as an RFC without > having to wait on the scoping-arch document, we've proposed to move > those portions of the Basic API that rely on scoping-arch into a > separate document that can advance alongside the scoping-arch document. > > There are 4 items that will move from 2553bis to the new "scoping api" > document: > > 1. References to the terms "link index" and "site index" in > the definition of the sin6_scope_id field. Note that the > sin6_scope_id field will remain in 2553bis. > > 2. Use of the scoped address text format with getaddrinfo(). > > 3. Use of the scoped address text format with getnameinfo(). > > 4. The NI_NUMERICSCOPE flag. > draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the IPv6 WG, but not an RFC yet. because of this, it cannot be referenced in the API draft. L2 triggers draft has not been adopted by any WG. do you see the danger?? please dont conclude I am spreading FUD. this is a real concern. Vijay Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > Thanks for your email. BTW, can you please > explain how can we implement fast handoff without > any link layer support? I also do not understand > why standardization of FMIPv6 will get delayed > because of L2 triggers. Is it not enough to > document various L2 triggers and the actions to be taken > based upon the L2 triggers? Do we need anything more than this? > regards, > ajoy > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, July 12, 2002 2:08 PM > To: Singh Ajoy-ASINGH1 > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > Ajoy, > > you got me wrong. I am not against using L2 triggers. I know you > need them to get the most optimized handovers. but we also need > a generic FMIPv6 solution (I dont know how manys times I have > said this now) that does not depend on L2 triggers. we need an > RFC soon (dont you?). > > Vijay > > Singh Ajoy-ASINGH1 wrote: > > > > Hello Vijay, > > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > > We have implemented both source as well as target triggers required > > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > > why are you complaining about L2 triggers? BTW, can you explain how > > can you implement FMIPv6 without using Link layer triggers? > > regards, > > ajoy > > > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 12, 2002 12:26 PM > > To: Vijay Devarapalli > > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. These > > are critical > > > > for describing how Postregv6 (aka BETH) > > > > can be implemented. If there is some problem with too much reference > to > > L2 > > > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > > BTW, I still havent figured out how to implement L2 triggers on our > > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > > draft becomes a standard. right?? and the L2 triggers document does > > > not even have a permanent home (WG). > > > > > > > If you want to know how to implement L2 triggers, either I or Jon Wood can > > help you. I implemented them on the Solaris > > emulator and Jon on our Linux/BSD emulator. Jon is also in the process of > > implementing L2 triggered 802.11 handover, in a > > manner that is consistent with the 802.11 spec and doesn't depend on > > proprietary extensions. > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 18:13:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17040 for ; Fri, 12 Jul 2002 18:13:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25387; Fri, 12 Jul 2002 16:13:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12057; Fri, 12 Jul 2002 15:13:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMCSoN010444 for ; Fri, 12 Jul 2002 15:12:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CMCSwS010443 for mobile-ip-dist; Fri, 12 Jul 2002 15:12:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMCPoN010433 for ; Fri, 12 Jul 2002 15:12:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01684 for ; Fri, 12 Jul 2002 15:12:26 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24965 for ; Fri, 12 Jul 2002 16:12:25 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id BC9386A901; Sat, 13 Jul 2002 01:12:24 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F27976A904; Sat, 13 Jul 2002 01:11:47 +0300 (EEST) Message-ID: <3D2F5481.20301@kolumbus.fi> Date: Sat, 13 Jul 2002 01:13:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Miles Cc: "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <00b801c228b6$4118d2e0$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > Vijay Devarapalli wrote: > > >>Kevin Miles wrote: >> > > >>>This is what I'm trying to get clarified. Is it >>> >>permissible, under any >> >>>circumstances, for the MN to change the value of the S bit >>> >>in successive BUs >> >>>that relate to the same binding(s)? I cannot see anything >>> >>in the draft that >> >>>prohibits it. Currently, it would appear that an MN could >>> >>use multiple BUs with >> >>IMO, it would be simpler if the draft prohibits it. >> >> > Works for me. Works for me too. Let's prohibit it. Also, we need to worry about the case where the prefixes change between S=0 reg & dereg. So, my proposal is to define an S=0 dereg as a deregistration of those addresses that were registered in the original S=0 reg. If no such original S=0 reg was done, the HA will return a new BA error code. Finally, in a S=0 rereg we could implicitly dereg all address whose prefixes have disappeared between the reg & dereg. This appears unnecessary, though, as the HA would not allow the lifetime to exceed the prefix lifetimes. But this should be noted in the draft to make it clear. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 18:17:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17233 for ; Fri, 12 Jul 2002 18:17:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01119; Fri, 12 Jul 2002 16:17:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03658; Fri, 12 Jul 2002 15:17:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMGRoN010560 for ; Fri, 12 Jul 2002 15:16:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CMGRxk010559 for mobile-ip-dist; Fri, 12 Jul 2002 15:16:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMGOoN010549 for ; Fri, 12 Jul 2002 15:16:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03223 for ; Fri, 12 Jul 2002 15:16:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26565 for ; Fri, 12 Jul 2002 16:16:24 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18867; Fri, 12 Jul 2002 15:16:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CMGLN19186; Fri, 12 Jul 2002 15:16:21 -0700 X-mProtect: <200207122216> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDEBJ6N; Fri, 12 Jul 2002 15:16:18 PDT Message-ID: <3D2F5533.4F155D6E@iprg.nokia.com> Date: Fri, 12 Jul 2002 15:16:19 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Ajoy, Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > You have not answered my question yet. is this a trick question? we do the demo in a lab. in our lab and in connectathon, we trigger a handoff from userland (an ioctl call). you cannot trigger a fast handoff by moving 5 feet. all 802.11 cards see all access points. > BTW, I do not see > any difference in BETH as well as anticipated handover > scheme in this respect. Both of them need L2 triggers > to enable fast handoff. In case of anticipated handover, we need > L2 trigger either at MN or oAR. Please find the following > text from the current fast handoff draft: this is not a fair comparison. we are not talking about the same L2 triggers now. I have problems with L2 triggers where the access point sends some information to the access router about the MN, without the MN sending an IP message. (because, this is specific to each link layer and is not even available in 802.11). for example the Target Trigger (which is needed by BETH) supplies the newAR with the L2 address of the MN. my 802.11 access point cannot supply the L2 address of the MN to the newAR. the Target Trigger also supplies the L2 address of the oldAR to the newAR. how does this happen (unless the two 802.11 APs talk to each other) in the anticipated part any information obtained (for setting up the tunnels) is through IP messages. and when I said I use one L2 trigger, I use the a trigger which is internal to the MN and it just says "hey, I have an L2 connection". in response to this, the MN sends either a FNA or NA. whereas the Link Up trigger required by BETH not only says "hey, I have an L2 connection", but also "hey, heres the L2 address of the newAR". cool... I am not saying you cannot have these triggers. cellular links have these triggers already. but there is no standard which works for all link layers. therefore we need a protocol with only IP messages to do a fast handover. regards Vijay > 3.1.6. Mobile Initiated Handover > > The main difference between mobile initiated network initiated > handover is that, in mobile initiated handover, MN receives > predictive information about the Layer 2 handover. The MN MUST send a > RtSolPr message to the oAR to trigger the PrRtAdv. > > 3.1.2. Network Initated Handover > > In network initiated handover, the oAR receives an indication that > the MN is about to move and information on the nAR to which the MN > will be moved. Both stateless and stateful nCoA configuration are > supported, as is use of the oCoA. > > I do not really see why are you so opposed to 3.2.1 of the FMIPv6 (Version > V4) > draft ? > regards, > ajoy > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, July 12, 2002 4:05 PM > To: Singh Ajoy-ASINGH1 > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > hi Ajoy , > > I think Raj's email answers your question. > > I am afraid Section 3.2.1 of draft 4 will hold back the draft > from advancing unless there is a standard way of doing L2-ST, > L2-TT, L2-LD, L2-LU. even if there is a standard way of doing > the triggers, there has to be some kind of reference that FMIPv6 > can quote. I am afraid that is not there (or wont there when > we need to advance FMIPv6) > > take a look at the following mail from Jack McCann, I just saw > in the IPv6 WG. I hope I am not doing anything wrong by cutting > and pasting this mail > > > The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) > > contains normative references to the Scoped Addressing Architecture > > (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies > > on the definition of zone indices, and on the scoped address text > > format defined in that document. This was flagged as an issue > > during IESG review. > > > > To allow 2553bis to move forward and be published as an RFC without > > having to wait on the scoping-arch document, we've proposed to move > > those portions of the Basic API that rely on scoping-arch into a > > separate document that can advance alongside the scoping-arch document. > > > > There are 4 items that will move from 2553bis to the new "scoping api" > > document: > > > > 1. References to the terms "link index" and "site index" in > > the definition of the sin6_scope_id field. Note that the > > sin6_scope_id field will remain in 2553bis. > > > > 2. Use of the scoped address text format with getaddrinfo(). > > > > 3. Use of the scoped address text format with getnameinfo(). > > > > 4. The NI_NUMERICSCOPE flag. > > > > draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the > IPv6 WG, but not an RFC yet. because of this, it cannot be referenced > in the API draft. > > L2 triggers draft has not been adopted by any WG. > > do you see the danger?? please dont conclude I am spreading FUD. this > is a real concern. > > Vijay > > Singh Ajoy-ASINGH1 wrote: > > > > Hello Vijay, > > Thanks for your email. BTW, can you please > > explain how can we implement fast handoff without > > any link layer support? I also do not understand > > why standardization of FMIPv6 will get delayed > > because of L2 triggers. Is it not enough to > > document various L2 triggers and the actions to be taken > > based upon the L2 triggers? Do we need anything more than this? > > regards, > > ajoy > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Friday, July 12, 2002 2:08 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > Ajoy, > > > > you got me wrong. I am not against using L2 triggers. I know you > > need them to get the most optimized handovers. but we also need > > a generic FMIPv6 solution (I dont know how manys times I have > > said this now) that does not depend on L2 triggers. we need an > > RFC soon (dont you?). > > > > Vijay > > > > Singh Ajoy-ASINGH1 wrote: > > > > > > Hello Vijay, > > > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > > > We have implemented both source as well as target triggers required > > > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > > > why are you complaining about L2 triggers? BTW, can you explain how > > > can you implement FMIPv6 without using Link layer triggers? > > > regards, > > > ajoy > > > > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, July 12, 2002 12:26 PM > > > To: Vijay Devarapalli > > > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. > These > > > are critical > > > > > for describing how Postregv6 (aka BETH) > > > > > can be implemented. If there is some problem with too much reference > > to > > > L2 > > > > > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > > > BTW, I still havent figured out how to implement L2 triggers on our > > > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > > > draft becomes a standard. right?? and the L2 triggers document does > > > > not even have a permanent home (WG). > > > > > > > > > > If you want to know how to implement L2 triggers, either I or Jon Wood > can > > > help you. I implemented them on the Solaris > > > emulator and Jon on our Linux/BSD emulator. Jon is also in the process > of > > > implementing L2 triggered 802.11 handover, in a > > > manner that is consistent with the 802.11 spec and doesn't depend on > > > proprietary extensions. > > > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 18:48:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18271 for ; Fri, 12 Jul 2002 18:48:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12266; Fri, 12 Jul 2002 16:47:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22558; Fri, 12 Jul 2002 15:47:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMknoN010787 for ; Fri, 12 Jul 2002 15:46:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CMknft010786 for mobile-ip-dist; Fri, 12 Jul 2002 15:46:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMkkoN010779 for ; Fri, 12 Jul 2002 15:46:46 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23570 for ; Fri, 12 Jul 2002 15:46:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07107 for ; Fri, 12 Jul 2002 16:46:46 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F0BB66A904; Sat, 13 Jul 2002 01:46:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 948596A901; Sat, 13 Jul 2002 01:46:12 +0300 (EEST) Message-ID: <3D2F5C96.80903@kolumbus.fi> Date: Sat, 13 Jul 2002 01:47:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt References: <003e01c22905$d12826c0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dr. Subrata Goswami wrote: > 1. The requirements for IPv6 routers and nodes would be better addressed > in a separate ID. Similarly the security issues (i.e. BU authentication > etc.) can also be better addressed in a separate ID. This was at least partially the intention. That is, the IPv6 node requirements document would list the requirements for particular types of IPv6 nodes. The intention of section 8 is to summarize the requirements for a particular class of functionality, such as nodes that support route optimization. I think this general approach has already been agreed in the WG. However, we have a number of alternatives on doing this: 1. Have a separate requirements section plus the behaviour sections (as is now) 2. Remove the requirements section, and improve the behaviour sections to make it more clear what is mandatory to implement from e.g. correspondent node behaviour and what is not. 3. Move the contents of the requirements sections to the corresponding behaviour sections as an introduction on what is mandatory to implement. What do folks on the list feel about these alternatives? > 3. The various conceptual data structures in HA, MN, and CN would be > better described through pictures. I'd like this, but I'm not sure what we can describe. As it is now, the different data structures are quite independent from each other. So it's hard to show any kinds of relationships. And what could we show from the individual data structures then? We can't really show specific linked-list or hash table structures, all we can really show is the list of fields in an entry. And for that purpose I believe the text is already sufficient. Both items registered as issue #60. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 18:52:37 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18445 for ; Fri, 12 Jul 2002 18:52:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09244; Fri, 12 Jul 2002 16:52:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25538; Fri, 12 Jul 2002 15:52:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMpnoN010921 for ; Fri, 12 Jul 2002 15:51:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CMpmVI010920 for mobile-ip-dist; Fri, 12 Jul 2002 15:51:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CMpjoN010913 for ; Fri, 12 Jul 2002 15:51:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15127 for ; Fri, 12 Jul 2002 15:51:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21888 for ; Fri, 12 Jul 2002 16:51:46 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id D66D06A904; Sat, 13 Jul 2002 01:51:39 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 597B66A901; Sat, 13 Jul 2002 01:51:10 +0300 (EEST) Message-ID: <3D2F5DBA.50108@kolumbus.fi> Date: Sat, 13 Jul 2002 01:52:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: justification (was: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt) References: <003e01c22905$d12826c0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dr. Subrata Goswami wrote: > 2. A justification for "return routability" as the way it is done with > HoTI/HoT and CoTI/CoT should be there. Also some details about why both > HoTI and CoTI are needed, rather than just HoTI. 14.4.1 talks about some of the background, more can be found from the referred documents such as draft-aura. Is there something specific that you are missing there? Regarding the need for both HoTi and CoTi: we could indeed have just one initiation message (even if two responses are needed). However, the text in 14.4.1 about symmetric exchanges applies here... we wanted to make the protocol symmetric in all requests so that we'd have less problems with reflection through e.g. the combined hoti-coti message to an unsuspecting third party. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 19:04:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18832 for ; Fri, 12 Jul 2002 19:04:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26725; Fri, 12 Jul 2002 17:04:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29798; Fri, 12 Jul 2002 16:04:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CN3EoN011093 for ; Fri, 12 Jul 2002 16:03:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CN3DSL011092 for mobile-ip-dist; Fri, 12 Jul 2002 16:03:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CN3BoN011085 for ; Fri, 12 Jul 2002 16:03:12 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05557 for ; Fri, 12 Jul 2002 19:03:13 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g6CN3KXA015976 for ; Fri, 12 Jul 2002 19:03:20 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g6CN3K5b015975 for mobile-ip@sunroof.eng.sun.com; Fri, 12 Jul 2002 19:03:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CIfJoN008559 for ; Fri, 12 Jul 2002 11:41:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08797 for ; Fri, 12 Jul 2002 11:41:20 -0700 (PDT) Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19338 for ; Fri, 12 Jul 2002 12:41:19 -0600 (MDT) Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id LAA20244; Fri, 12 Jul 2002 11:41:18 -0700 (PDT) Received: from hplex1.hpl.hp.com (hplex1.hpl.hp.com [15.0.152.182]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with SMTP id g6CIfHE13979; Fri, 12 Jul 2002 11:41:17 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Fri, 12 Jul 2002 11:41:17 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 11:41:16 -0700 Message-ID: <40700B4C02ABD5119F0000902787664453376E@hplex1.hpl.hp.com> From: "Lee, Sung Ju" Reply-To: sjlee@hpl.hp.com To: "'sjlee@hpl.hp.com'" Cc: "Elizabeth Royer (E-mail)" Subject: [mobile-ip] MobiCom CFPosters Date: Fri, 12 Jul 2002 11:41:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ACM MobiCom 2002: Call for Student Posters! http://www.acm.org/sigmobile/mobicom/2002/cfp/posters.html ACM MobiCom 2002 is the eighth annual conference sponsored by ACM SIGMOBILE dedicated to addressing new challenges in mobile computing and networking. The MobiCom 2002 conference solicits student posters describing new and noteworthy research contributions to the field of mobile computing and networking. Student Posters: The conference solicits student posters that highlight recent and on-going research by students on mobile computing topics. Areas of interest include those that are listed on the technical paper call for papers, which can be found at http://www.acm.org/sigmobile/mobicom/2002/cfp/. Proposals should be a maximum of TWO pages in length and, while they don't need to describe completed work, the work should be advanced beyond the initial stages. The first author of all poster submissions must be a student. Poster abstracts will not be published in the proceedings but will instead be published on the web before the conference. Poster submissions will be reviewed. Authors of accepted papers must not submit a poster of the work they present in the conference. Submissions should be sent by email to Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) by July 15, 2002. Why should you submit a poster? This is a great chance for students to obtain interesting and valuable feedback on on-going work from a knowledgeable crowd at the conference. What is a poster? A poster is a 1 meter x 1.25 meter rectangular board on which you can affix visually appealing material that describes your research. How you use this is up to you: you may choose to print out several 8.5"x11" or A4 sheets of paper (e.g., paper copies of overheads) and "tile" the poster board with these pages. Or, you may choose to print a single large sheet of paper describing the work and attach that to the poster board. You may bring your own poster boards if you like. Several document companies like Kinko's produce professional-looking posters from material produced on software like Powerpoint; you may want to use such a facility. You should prepare the best material (visually appealing and succinct) that effectively communicates your research problem, techniques, and results. What, when, and where to submit? If you are a student and are interested in this, then submit the following by July 15, 2002 by email to Elizabeth Belding-Royer (ebelding@cs.ucsb.edu): 1. A maximum TWO page description (in either postscript, txt, or pdf format only!) describing the research to be presented in the poster. Include the title, authors, and institutional affiliations. 2. A draft of the poster material (either multiple "tiles" or a single sheet of paper), in pdf or postscript format. Include the title, authors, and institutional affiliations. Send your submission in one email message with the two parts. We will select approximately 20 of the most interesting and thought-provoking posters by August 7, 2002 and notify all contact authors. More details will be sent at that time. Student Posters Co-Chairs: Elizabeth Belding-Royer, UC Santa Barbara ebelding@cs.ucsb.edu Sung-Ju Lee, Hewlett Packard Laboratories From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 19:05:07 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18867 for ; Fri, 12 Jul 2002 19:05:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08133; Fri, 12 Jul 2002 16:03:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29506; Fri, 12 Jul 2002 16:03:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CN2PoN011080 for ; Fri, 12 Jul 2002 16:02:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CN2Pj2011079 for mobile-ip-dist; Fri, 12 Jul 2002 16:02:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CN2NoN011072 for ; Fri, 12 Jul 2002 16:02:23 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05384 for ; Fri, 12 Jul 2002 19:02:25 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g6CN2WXA015971 for ; Fri, 12 Jul 2002 19:02:32 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g6CN2VuE015970 for mobile-ip@sunroof.eng.sun.com; Fri, 12 Jul 2002 19:02:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CGHkoN007405 for ; Fri, 12 Jul 2002 09:17:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13253 for ; Fri, 12 Jul 2002 09:17:48 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25646 for ; Fri, 12 Jul 2002 10:17:46 -0600 (MDT) Received: from pichnet (pichnet.u-strasbg.fr [130.79.90.171]) by clarinet.u-strasbg.fr (Postfix) with SMTP id B48E7179B6; Fri, 12 Jul 2002 18:19:56 +0200 (CEST) Reply-To: From: "Nicolas Montavont" To: Subject: [mobile-ip] Multiple Interfaces Management - new I-D Date: Fri, 12 Jul 2002 18:26:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0026_01C229D1.A16AF440" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0026_01C229D1.A16AF440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I've recently wrote a new I-D, "draft-montavont-mobileip-mmi-00.txt", that I wanted to submit to the Mobile IP Working Group. As the submission deadline is exceeded, I already send you a copy of the document in attachment. It is also available at http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-mmi-00.txt For any questions or comments, feel free to ask Francis Dupont or Jean-Marie Bonnin, which are involved in our project and will be present at the meeting, or contact me by e-mail. Here the abstract: MIPv6 [MIPv6] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN of having multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (MIPv6 for Multiple Interfaces) which describes the use of MIPv6 to support multiple interfaces. These extensions focus on the MN ability to use a backup interface for communications and to redirect flows between its own interfaces. Thanks for your interest, Nicolas ------=_NextPart_000_0026_01C229D1.A16AF440 Content-Type: text/plain; name="draft-montavont-mobileip-mmi-00.txt" Content-Disposition: attachment; filename="draft-montavont-mobileip-mmi-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force N. Montavont INTERNET DRAFT T. Noel Expires in February 2003 LSIIT - ULP M. Kassi-Lahlou France Telecom R&D July 2002=20 =20 MIPv6 for Multiple Interfaces =20 Status of This Memo =20 This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. =20 Abstract MIPv6 [MIPv6] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN of having multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (MIPv6 for Multiple Interfaces) which describes the use of MIPv6 to support multiple interfaces. These extensions focus on the MN ability to use a backup interface for communications and to redirect flows between its own interfaces. draft-montavont-mobileip-mmi-00.txt [Page 1] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Table of contents=20 Status of this memo=20 Abstract =20 1. Introduction.............................................2 2. Terminology related to multiple interfaces...............3 2.1 Terminology..........................................3 2.2 Network configuration................................4 3. Motivations..............................................5 3.1 Why a MN may want to redirect a flow.................5 3.2 Scenarios............................................5 3.2.1 Two interfaces available at the same time......5 3.2.2 Only one interface available at a given time...6 4. Multiple interfaces management...........................6 4.1 Hypothesis..........................................6 4.2 MMI.................................................7 5. Future Work..............................................8 5.1 Receiving new communications.........................8 5.2 Filtering............................................8 6. References...............................................9 7. Authors' address.........................................10 Appendix A: Local Redirection...............................10 1. Introduction Future MNs will probably have multiple interfaces to be connected to different access technologies. Each technology has its specific characteristics in terms of coverage, bandwidth, reliability, etc. While MIPv6 [1] allows a MN to handover between subnets, there are no requirements to manage mobility into the MN, i.e. between several interfaces. This document presents the problematic of having multiple interfaces and proposes some simple extensions to MIPv6, called MMI (MIPv6 for Multiple Interfaces) to optimize the use of multiple interfaces. Assume a MN with two interfaces. For example, the MN can be connected to the network with only one interface. After a move, it connects to the network with the other interface and looses the network connectivity through the first. Subsequently the MN may want all the flows using the first interface to be automatically redirected on the other available interface. Or, a MN can take advantage of having multiple interfaces by using backup interface. Also, if a MN performs a handover between subnets, it may redirect its flows on another interface while it performs MIPv6 operations. This minimizes the impact of the handover on the applications. draft-montavont-mobileip-mmi-00.txt [Page 2] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 In this document, the specific operations needed to perform vertical handovers are described. In the next section, some definitions related to multiple interfaces management are given. The section 3 explains why a MN may want to redirect flows between its interfaces and gives two scenarios of a MN with multiple interfaces. Then, MMI operations are described for a generic network configuration. These operations describe the use of MIPv6 to perform vertical handovers. Finally, the document ends on further functionalities which are going to be developped later. =20 2. Terminology related to multiple interfaces =20 2.1 Terminology =20 The following terms are introduced in the document. Some definitions are taken from [2]. Available interface An interface that offers to the MN connectivity to the network. The MN can initiate and receive flows through this interface Interface down An interface is down when it is not available for flows. An interface may be down for many reasons (e.g. the interface is deactivated by the user, the interface is physically not inserted in the MN, the interface is not connected to a network) L2 handover The change of access point=20 L3 handover The change of IP subnet Horizontal handover From the IP point of view, a horizontal handover happens if the MN changes of subnet it is connected to Vertical Handover [2] In a vertical handover the MN's network interface to the access network changes. A vertical handover is typically an inter-technology handover draft-montavont-mobileip-mmi-00.txt [Page 3]=20 =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Source interface During a vertical handover, the source interface is the interface from which flow will be redirected. Target interface During a vertical handover, the target interface is the interface to which flow will be redirected. =20 2.2 Network configuration =20 This document focuses on the management of multiple network interfaces into a single MN. Each interface is either wireless or wired. This document will detail the operations needed for a MN to redirect flow between its interfaces. In each proposition, we discuss the redirection between two interfaces, but the operations are effective even if a MN has more interfaces. The proposed mechanism proposed works in all the network configurations possible, that is to say all the network configurations to which the MN is connected: - The two interfaces are connected to the same subnet, the home network for each interface - The two interfaces are connected to the same subnet, a visited network for each interface - The two interfaces are connected to the same subnet, the home network for one interface and a visited network for the other - The two interfaces are connected to different subnets, the home network for each interface - The two interfaces are connected to different subnets, a home network for one interface and a visited network for the other interface - The two interfaces are connected to different subnets, a visited network for each interface We will prove that some simple operations described in MMI are sufficient for all the above network configurations. draft-montavont-mobileip-mmi-00.txt [Page 4] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 =20 3. Motivations =20 3.1 Why a MN may want to redirect a flow =20 A MN may want to redirect its flows between its available interfaces for many reasons: - An interface in use comes down - The MN can take advantage of having multiple interfaces and redirects some or all flows from the down interface to another available interface - An interface comes up. The MN may decide that the interface which comes up is most suitable for its current flows using another interface - The MN performs a handover on an interface in use for flows. When a MN performs a horizontal handover, the handover latency (the time during which the MN can not send nor receive packets) can be long and the flows can be perturbed. If the MN wants to minimize such perturbation, it can redirect some or all the flows on another available interface. This redirection can be done in advance of the handover by the L2 triggers [3] - The network capabilities change. The MN can observe a degradation of service on one of its interface, or conversely an improvement of capacity on an interface. The MN may then decide to redirect some or all flows on another interface that it considers most suitable for the target flows. =20 3.2 Scenarios =20 3.2.1 Two interfaces available at the same time =20 Assume a global network covering wide areas, like third generation network. A MN can access to services like telephony, e-mail and web browser through an interface I1 connected to this wide network. At the same time, the MN has Internet access with a higher rate than the global network on an other interfaces I2, e.g. in WLANs or hot spots. The coverage area of this second technology is smaller than the global network and is also covered by the global network. When the mobile user enters the area covered by the technology with the higher rate (e.g. WLANs), he may want to: - Initiate new flow through I2 - Continue its current flows on I1 - Redirect some or all flows from I1 to I2 to take advantage of the technology with the higher rate =20 draft-montavont-mobileip-mmi-00.txt [Page 5] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 When the mobile user leaves the coverage area of the technology with the higher rate, he may want to: - Interrupt its flows using I2 - Redirect some or all flows from I2 to I1 =20 3.2.2 Only one interface available at a given time =20 Consider a MN with two interfaces of different technologies. Firstly, the MN is connected to the network with only one interface. Then the MN connects to the network through the other interface, typically after a move, and the MN looses its first connection. For example, assume a company offering an access to network resources like Internet access or intranet. Consider a mobile host with both a wireless and a wired interface. According to company rules, the wireless subnet can or cannot be on the same subnet than the wired subnet. The two interfaces can be used in many ways: keep a backup = interface, use each interface for pre-determined traffic... According to the availability of the interfaces, a MN may want to redirect flows between its interfaces. =20 4. Multiple interfaces management 4.1 Hypothesis =20 In the following, we assume a MN with two interfaces I1 and I2 of different access technologies. Each interface is configured with a global IPv6 address, respectively IP1 and IP2. These two global IPv6 addresses are assigned to the MN in such a way that both addresses can be used to reach the MN. The MN uses Mobile IPv6 on each of its interfaces when it moves between subnets. Then the MN has a home link for each of its interfaces and there is a router acting as a home agent on each home link. The use of MIPv6 to redirect flows between interfaces are highlight for a generic network configuration. The generic network configuration encloses all the cases listed in section 2.2. MMI allows a MN to transparently redirect its ongoing flows from its interface I2 to its interface I1 (vertical handover). draft-montavont-mobileip-mmi-00.txt [Page 6] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 4.2 MMI MMI allows a MN to register a binding on its home agent (and eventually its CNs) between two IP addresses, each allocated to one of the MN's interfaces. The main mechanism is to send a Binding Update to indicate a new CoA of a source interface through the target interface. MMI works for any configuration network, as when the MN is initially connected to the same subnet with its two interfaces as when the MN is initially connected to different subnet. To make things as clear as possible, this document discusses the flow redirection from (I2, IP2) to (I1, IP1) in order to illustrate MMI. IP1 can be the home address allocated to I1, or the current CoA allocated to I1. =20 The generic solution for the MN to redirect the flows intended to IP2 on I1 (vertical handover from the source interface I2 to the target interfaces I1) is to use the MIPv6 mechanism adapted for multiple interfaces (MMI). The MN sends a Binding Update to its home agent serving the MN for the source interface (and eventually to its CNs). The Binding Update [1] must be sent as follow: - The home address field set to the IP address bound to the source interface (IP2) - The CoA field set to the IP address bound to the target interface (IP1) This Binding Update must be sent through the target interface. When receiving the Binding Update, the home agent registers an association between IP2 and IP1 in its binding cache. Therefore, all new flows with the destination address IP2 will be intercepted by the home agent and forwarded to the current address allocated to target interface (IP1 on I1). This operation does not disturb the initial communications on the target interface I1 using IP1. Thus, MMI allows a MN to send a binding information for a source interface by using another interface, the target interface. =20 draft-montavont-mobileip-mmi-00.txt [Page 7] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 Afterwards, if the MN moves to a new subnet by using the target interface I1 (horizontal handover on I1), it obtains a new CoA (IP3). Besides the operations required in MIPv6 when a MN changes its point of attachment, the MN has to send a Binding Update to its home agent serving the source interface (and eventually to CNs of its current flows which have a binding between IP2 and IP1 in their binding cache) to update its localization. Now, the binding cache of the home agent records, among others, a binding between the home address IP2 and the CoA IP3. Thus, the movement detected on I1 is indicated to I2. Later, if the MN wants to use the source interface I2 again and had registered an association on its home agent between IP2 and IP1, it needs to update the entry in the binding cache of the home agent. If the MN is connected to a foreign network through the source interface I2 (different from the home link), it sends a Binding Update with the new IPv6 address got on the current link as the new CoA, to update the binding cache of its home agent. If the MN is connected to its home link through I2, it has to send a Binding Update to its home agent to make it invalid the binding cache for it (see returning home in [1]). =20 5. Further Work =20 In this section, we describe some further operations that can be simply added to MMI framework in order to optimize the multiple interfaces management. =20 5.1 Receiving new communications =20 Consider a MN which has redirected flows from a source interface (I2, IP2) to a target interface (I1, IP1) as described in MMI (section 4). If the MN receives a new flow forwarded by its home agent, the MN has several possibilities: it might reject the flow (e.g. the flow needs are not adapted to the network capacities provided to the MN); Or if the MN does not reject the flow, it might decide to inform the CN of the flow that its current address is IP1 and that it needs to use routing header [1]. 5.2 Filtering =20 Filtering the current flows When a MN redirects its flows between its own interfaces, MMI requires that the MN sends a Binding Update to its home agent through the target interface (I1, IP1), in order to register a new association for the source interface (I2, IP2). However, the MN may not want to redirect all the flows of the source interface (because the target interface can not support certain flows, or the MN just wants to spread again its flows on all its interfaces to optimize the network capacities). To advertise its home agent (or a CN) to only redirect some flows of the source interface, the MN should add filters in the Binding Update sent for the redirection. The filter indicates which flow is concerned by this binding [5][6]. draft-montavont-mmi-00.txt [Page 8] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 The flow identification can be the one used in the Flow Label field in the IPv6 header if set [7]. Otherwise, the flow identification can be the quintuplet source and destination ports, source and destination addresses and protocol ID. Filtering future flows Besides redirecting its current flows between its interfaces, a MN may want to advertise its home agent to only redirect a part of the future flows intended to it. We call future flows of the MN, the flows that the MN could receive in the near future, that do not exist when the MN sends the Binding Update for the redirection. If the MN wants that its home agent only redirects some of its future flows, it may add a new filter in the Binding Update sent to its home agent. The new filter in the Binding Update can indicate a protocol ID or an application ID. Therefore, as soon as a new flow is intercepted by the home agent for the MN, it checks if the filter matches with the flow to redirect the flow to the right CoA. =20 6. References =20 [1] D. Johnson, C. Perkins. "Mobility support in IPv6", draft-ietf-mobileip-ipv6-18.txt, July 2001. [2] J. Manner, M. Kojo, "Mobility related terminology", draft-manner-seamoby-terms-04.txt, May 2002. [3] J. Kempf, et. al, "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", draft-manyfolks-l2-mobilereq-02.txt, June 2002. [4] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] M. Diagne, T. Noel, "A Protocol for IPv6 Nomadic Communications", 5th IEEE Malaysia International Conference on Communications (MICC'01), Malaysia, October 2001 [6] H. Soliman, K. El Malki, C. Castelluccia, "Per-flow movement in MIPv6", draft-soliman-mobileip-flow-move-01.txt, November 2001. [7] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label-00.txt, February 2002. draft-montavont-mmi-00.txt [Page 9] =0C INTERNET-DRAFT Mobile IPv6 for Multiple interfaces July 2003 =20 7. Authors' address Nicolas Montavont LSIIT - ULP Pole API Boulevard Sebastien Brant 67400 Illkirch France E-mail: montavont@dpt-info.u-strasbg.fr Thomas Noel LSIIT - ULP Pole API Boulevard Sebastien Brant 67400 Illkirch France E-mail: noel@dpt-info.u-strasbg.fr Mohammed Kassi-Lahlou France Telecom R&D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 - France E-mail: mohamed.kassilahlou@francetelecom.com Annexe A: Local Redirection =20 There is an easier mechnanism for the MN to redirect flow between its interfaces when it is connected to the same subnet through its interfaces. The Local Redirection allows a MN to transparently redirect its ongoing flows between its interfaces without using the MIPv6 features. When a MN is connected to the same subnet though both I1 and I2 and wants to redirect all its ongoing flows intended to IP2 (assigned to I2) it can allocate IP2 to I1. The MN has to advertise its neighbors on the link that all packets with the destination address IP2 must now be forwarded to the MAC address of I1. To do so, the MN sends an unsolicited Neighbor Advertisement [4] to all nodes multicast address indicating the association between IP2 and the MAC address of I1. The 'O' bit must be set in the unsolicited Neighbor Advertisement to override the old entry associating IP2 to the MAC address of I2. This causes the neighbor nodes on the link to add the association between the MAC address of I2 with IP1. After, the MN is reachable through I1 by both IP1 and IP2. This redirection is transparent to the distant CNs. draft-montavont-mmi-00.txt [Page 10] Expires: February 2003 ------=_NextPart_000_0026_01C229D1.A16AF440-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 19:12:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19181 for ; Fri, 12 Jul 2002 19:12:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29782; Fri, 12 Jul 2002 17:12:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22950; Fri, 12 Jul 2002 16:12:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNBboN011715 for ; Fri, 12 Jul 2002 16:11:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CNBaw5011714 for mobile-ip-dist; Fri, 12 Jul 2002 16:11:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNBXoN011707 for ; Fri, 12 Jul 2002 16:11:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22800 for ; Fri, 12 Jul 2002 16:11:35 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21503 for ; Fri, 12 Jul 2002 17:11:35 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA07357 for ; Fri, 12 Jul 2002 16:11:55 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA06976 for ; Fri, 12 Jul 2002 16:11:45 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 12 Jul 2002 18:11:33 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Vijay Devarapalli'" , Singh Ajoy-ASINGH1 Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 12 Jul 2002 18:10:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Vijay, Please find my inline reply. I will only be able to answer your subsequent emails tomorrow. regards, ajoy -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Friday, July 12, 2002 5:16 PM To: Singh Ajoy-ASINGH1 Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions hi Ajoy, Singh Ajoy-ASINGH1 wrote: > > Hello Vijay, > You have not answered my question yet. is this a trick question? we do the demo in a lab. in our lab and in connectathon, we trigger a handoff from userland (an ioctl call). you cannot trigger a fast handoff by moving 5 feet. all 802.11 cards see all access points. > BTW, I do not see > any difference in BETH as well as anticipated handover > scheme in this respect. Both of them need L2 triggers > to enable fast handoff. In case of anticipated handover, we need > L2 trigger either at MN or oAR. Please find the following > text from the current fast handoff draft: this is not a fair comparison. we are not talking about the same L2 triggers now. Ajoy-> Why not? In what way network initiated L2 trigger of anticipated handover is different from BETH L2-ST? I have problems with L2 triggers where the access point sends some information to the access router about the MN, without the MN sending an IP message. (because, this is specific to each link layer and is not even available in 802.11). for example the Target Trigger (which is needed by BETH) supplies the newAR with the L2 address of the MN. Ajoy-> Target trigger will be suitable for cellular networks. BTW, even in case of WLAN, you can receive L2-TT trigger at nAP. L2TT (Re-association Request) can provide nAP the L2 address of the oldAP as well as L2 address of the mobile node. If we implement FA function at AP, then this becomes an implementation issue. If not, then you need to define some protocol between AP and AR which can be addressed in separate document. I understand that Re-Association Request is not as good as pre-trigger, but this will provide you lot better performance than standard Mobile/IP. my 802.11 access point cannot supply the L2 address of the MN to the newAR. the Target Trigger also supplies the L2 address of the oldAR to the newAR. how does this happen (unless the two 802.11 APs talk to each other) in the anticipated part any information obtained (for setting up the tunnels) is through IP messages. and when I said I use one L2 trigger, I use the a trigger which is internal to the MN and it just says "hey, I have an L2 connection". in response to this, the MN sends either a FNA or NA. whereas the Link Up trigger required by BETH not only says "hey, I have an L2 connection", but also "hey, heres the L2 address of the newAR". cool... Ajoy-> MN L2 trigger is only used for Mobile Initiated handover. What happens when handover is network initiated ? I am not saying you cannot have these triggers. cellular links have these triggers already. but there is no standard which works for all link layers. therefore we need a protocol with only IP messages to do a fast handover. Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does not work for network initiated trigger. BTW, based upon our implementation, we found anticipated handover does not provide good performance on cellular link. Hence, anticipated handover is not going to address fast handoff need for various cellular networks. regards Vijay > 3.1.6. Mobile Initiated Handover > > The main difference between mobile initiated network initiated > handover is that, in mobile initiated handover, MN receives > predictive information about the Layer 2 handover. The MN MUST send a > RtSolPr message to the oAR to trigger the PrRtAdv. > > 3.1.2. Network Initated Handover > > In network initiated handover, the oAR receives an indication that > the MN is about to move and information on the nAR to which the MN > will be moved. Both stateless and stateful nCoA configuration are > supported, as is use of the oCoA. > > I do not really see why are you so opposed to 3.2.1 of the FMIPv6 (Version > V4) > draft ? > regards, > ajoy > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, July 12, 2002 4:05 PM > To: Singh Ajoy-ASINGH1 > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > hi Ajoy , > > I think Raj's email answers your question. > > I am afraid Section 3.2.1 of draft 4 will hold back the draft > from advancing unless there is a standard way of doing L2-ST, > L2-TT, L2-LD, L2-LU. even if there is a standard way of doing > the triggers, there has to be some kind of reference that FMIPv6 > can quote. I am afraid that is not there (or wont there when > we need to advance FMIPv6) > > take a look at the following mail from Jack McCann, I just saw > in the IPv6 WG. I hope I am not doing anything wrong by cutting > and pasting this mail > > > The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) > > contains normative references to the Scoped Addressing Architecture > > (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies > > on the definition of zone indices, and on the scoped address text > > format defined in that document. This was flagged as an issue > > during IESG review. > > > > To allow 2553bis to move forward and be published as an RFC without > > having to wait on the scoping-arch document, we've proposed to move > > those portions of the Basic API that rely on scoping-arch into a > > separate document that can advance alongside the scoping-arch document. > > > > There are 4 items that will move from 2553bis to the new "scoping api" > > document: > > > > 1. References to the terms "link index" and "site index" in > > the definition of the sin6_scope_id field. Note that the > > sin6_scope_id field will remain in 2553bis. > > > > 2. Use of the scoped address text format with getaddrinfo(). > > > > 3. Use of the scoped address text format with getnameinfo(). > > > > 4. The NI_NUMERICSCOPE flag. > > > > draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the > IPv6 WG, but not an RFC yet. because of this, it cannot be referenced > in the API draft. > > L2 triggers draft has not been adopted by any WG. > > do you see the danger?? please dont conclude I am spreading FUD. this > is a real concern. > > Vijay > > Singh Ajoy-ASINGH1 wrote: > > > > Hello Vijay, > > Thanks for your email. BTW, can you please > > explain how can we implement fast handoff without > > any link layer support? I also do not understand > > why standardization of FMIPv6 will get delayed > > because of L2 triggers. Is it not enough to > > document various L2 triggers and the actions to be taken > > based upon the L2 triggers? Do we need anything more than this? > > regards, > > ajoy > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Friday, July 12, 2002 2:08 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > Ajoy, > > > > you got me wrong. I am not against using L2 triggers. I know you > > need them to get the most optimized handovers. but we also need > > a generic FMIPv6 solution (I dont know how manys times I have > > said this now) that does not depend on L2 triggers. we need an > > RFC soon (dont you?). > > > > Vijay > > > > Singh Ajoy-ASINGH1 wrote: > > > > > > Hello Vijay, > > > We have implemented FMIPv4 in our prototype 3G Cellular testbed. > > > We have implemented both source as well as target triggers required > > > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand > > > why are you complaining about L2 triggers? BTW, can you explain how > > > can you implement FMIPv6 without using Link layer triggers? > > > regards, > > > ajoy > > > > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, July 12, 2002 12:26 PM > > > To: Vijay Devarapalli > > > Cc: Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > > > In particular, Section 3.3 and 3.4 were dropped from the draft. > These > > > are critical > > > > > for describing how Postregv6 (aka BETH) > > > > > can be implemented. If there is some problem with too much reference > > to > > > L2 > > > > > > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work. > > > > BTW, I still havent figured out how to implement L2 triggers on our > > > > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers > > > > draft becomes a standard. right?? and the L2 triggers document does > > > > not even have a permanent home (WG). > > > > > > > > > > If you want to know how to implement L2 triggers, either I or Jon Wood > can > > > help you. I implemented them on the Solaris > > > emulator and Jon on our Linux/BSD emulator. Jon is also in the process > of > > > implementing L2 triggered 802.11 handover, in a > > > manner that is consistent with the 802.11 spec and doesn't depend on > > > proprietary extensions. > > > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 19:32:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19759 for ; Fri, 12 Jul 2002 19:32:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07375; Fri, 12 Jul 2002 17:32:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10491; Fri, 12 Jul 2002 16:32:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNVEoN011913 for ; Fri, 12 Jul 2002 16:31:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CNVEn8011912 for mobile-ip-dist; Fri, 12 Jul 2002 16:31:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNVBoN011905 for ; Fri, 12 Jul 2002 16:31:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09618 for ; Fri, 12 Jul 2002 16:31:12 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06872 for ; Fri, 12 Jul 2002 17:31:12 -0600 (MDT) Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 19:31:10 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C37442@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: MIPv6 draft 18 - MIP and multicast Date: Fri, 12 Jul 2002 19:31:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Just a reminder that this draft is available at; http://www.flarion.com/technology/draft-oneill-mip-multicast-00.txt. In the context of the review of -18 I would propose`that the multicast text only cover the reverse tunnelling case and leave new work to cover the foreign multicast case because I think there is much work to do here. This is I think reasonable given the lack of discussion and consensus on this issue. The other option is just to include the hybrid model only (reception via foreign multicast but origination via the home multicast system as a non-member system) because this option does not impact multicast routing protocols and is simply an MIP routing issue. I am happy to provide suitable text to cover either option..or in fact to work within a group to try to come up with solid recommendations in this area for the document. Alan. -----Original Message----- From: Alan O'Neill Sent: 08 July 2002 18:16 To: mobile-ip@sunroof.eng.sun.com Subject: MIP and multicast I have just submitted an internet-draft (abstract below) on the subject of MIPv4 and MIPv6 multicast support via the Foreign multicast system which will be available at http://www.flarion.com/technology/tech_standards.html hopefully early this week. Both MIPv4 and MIPv6 presently require the MN to use a CCoA as a foreign multicast source address. This I believe is problematic for multicast protocols that build source specific trees at cellular mobility rates. This is because each tree needs to be rebuilt on every hand-off which is going to thrash the routing system because every router on each tree is being exposed to the movement of every MN on that tree. Clearly, the more trees with MN senders the worse this problem becomes. ASM (PIM-SM) and SSM (on any protocol) all build source trees so I believe this is a major deployment barrier for foreign network multicast. In contrast, the HoA is stable across hand-offs and therefore this should be the source address and also used to populate multicast forwarding entries. To avoid the RPF check failing (expects packets from the HA and not the FA), the draft discusses various ways to initially bypass the problematic RPF checks, but in the future for multicast routing protocols to be evolved to be able to support an arbitrary RPF point (the present Multicast Designated Router of the MN). The RPF approach is optimal because each hand-off only changes the RPF interface in routers local to the hand-off and is therefore scalable. The draft does not however deal with the multicast changes in detail but is simplky intended to motivate discussion, MIP spec changes and appropriate multicast research and standards work. I will be in Yokohama from sunday to wednesday afternoon and am happy to discuss this with interested parties outside the main meeting. Regards, Alan. Mobility Management and IP Multicast Abstract Mobile IP provides a mobile node, that visits a foreign subnet, the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a redirection tunnel from a home agent on the home subnet. Mobile IP in RFC 3220 states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks. This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 19:34:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19842 for ; Fri, 12 Jul 2002 19:34:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29239; Fri, 12 Jul 2002 17:34:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11074; Fri, 12 Jul 2002 16:34:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNXjoN012002 for ; Fri, 12 Jul 2002 16:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CNXjHY012001 for mobile-ip-dist; Fri, 12 Jul 2002 16:33:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CNXgoN011994 for ; Fri, 12 Jul 2002 16:33:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11258 for ; Fri, 12 Jul 2002 16:33:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18860 for ; Fri, 12 Jul 2002 16:33:43 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id A3F406A904; Sat, 13 Jul 2002 02:33:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EF31A6A901; Sat, 13 Jul 2002 02:33:20 +0300 (EEST) Message-ID: <3D2F67AA.40103@kolumbus.fi> Date: Sat, 13 Jul 2002 02:35:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli Subject: link-locals (was: [mobile-ip] comments on draft-ietf-mobileip-ipv6-18.txt) References: <003e01c22905$d12826c0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dr. Subrata Goswami wrote: > 4. The BCE of the CN is indexed by the home-address of the MN. The spec > as it is now allows link-local addresses. So is there a possibility that > two MN's may end up having the same l-l address in a CN? You already had a discussion with Vijay, but I would add the following: A CN that is on the home link could in theory be able to create a BCE that points from a ll home address to a global coa. However, there's a problem in how route optimization could be employed with ll addresses. Assume the CN uses a link-local address, and adds a RH to a packet destined to the mobile node's ll address. The source address of this packet would have to be ll, and the destination would have to be non-ll. This appears to be against normal source address selection rules. However, I can't find anything in the draft that prohibits RO with ll addresses. So my proposal is that we prohibit RO for ll home or CN addresses. Ok for everyone? > 5. In a hypothetical situation, a MN may visit a foreign network and > acquires the same CoA address and the l-l HoA. Is it a possibility? Are > CoA's always global? As Vijay already noted, CoA's are formed from advertised prefixes, which are never link-local (SHOULD NOT in RFC 2461). Both items registered as issue #62 Jari ---- P.S. As you may recall, the issue list can be found at: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html The files on the list will be updated soon. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 20:11:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20860 for ; Fri, 12 Jul 2002 20:11:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05336; Fri, 12 Jul 2002 18:11:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25079; Fri, 12 Jul 2002 17:11:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0AooN012272 for ; Fri, 12 Jul 2002 17:10:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D0AoUm012271 for mobile-ip-dist; Fri, 12 Jul 2002 17:10:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0AkoN012264 for ; Fri, 12 Jul 2002 17:10:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21858 for ; Fri, 12 Jul 2002 17:10:48 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06045 for ; Fri, 12 Jul 2002 18:10:47 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1EAC56A904; Sat, 13 Jul 2002 03:10:41 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8F0A36A901; Sat, 13 Jul 2002 03:10:23 +0300 (EEST) Message-ID: <3D2F7058.2070406@kolumbus.fi> Date: Sat, 13 Jul 2002 03:12:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli , mobile-ip@sunroof.eng.sun.com Cc: James Kempf Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Regarding the use of alt coa... I can't name any other reason than possible use with ESP. Are there any situations where we would not have the possibility to use the new coa yet? It seems that at least for CN BUs, this isn't even possible, since we already require RR to test the CoA with CoTi/CoT. For HA BUs, it still remains a theoretical possibility. And then to the ESP-reason: as Vijay stated, SPD entries are used for restricting the right SA/HoA to be used. And these entries can't be used for restricting the right CoA, as obviously the HA has no knowledge of the current location of the MN yet. Let's discuss the implications of an attack where the CoA (= BU src) is changed. If the attacker is not a MitM, he can't forge the ESP MAC, so the BU will be dropped. If the attacker is a MitM, he can change the src address and the HA will not see the modification, and installs a wrong BCE. However, the MN will not see an ack, and will retry. For the MN, the effect is the same as any MitM could do anyway: DoS. So in that sense this attack is not serious. However, for the innocent bystander whose address is replaced as the CoA this may be more serious. All traffic destined to the MN will be tunneled to him. It looks like we need to deal with this, so in order for ESP to be used we need to have the alt coa option in the spec. However, I dislike format variants, especially when the choice depends on a user-configured SPD entry in an another part of the system. This creates an unnecessary restriction between IPv6 stack parts. Therefore, I'd like to suggest the alt coa option to be made a fixed field in the BU messages instead, and to be always used. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 20:33:13 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21572 for ; Fri, 12 Jul 2002 20:33:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07570; Fri, 12 Jul 2002 17:31:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16818; Fri, 12 Jul 2002 17:31:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0UloN012423 for ; Fri, 12 Jul 2002 17:30:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D0UlfB012422 for mobile-ip-dist; Fri, 12 Jul 2002 17:30:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0UioN012415 for ; Fri, 12 Jul 2002 17:30:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27110 for ; Fri, 12 Jul 2002 17:30:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25611 for ; Fri, 12 Jul 2002 18:30:45 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 96D306A904; Sat, 13 Jul 2002 03:30:44 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 263026A901; Sat, 13 Jul 2002 03:30:37 +0300 (EEST) Message-ID: <3D2F7516.8050904@kolumbus.fi> Date: Sat, 13 Jul 2002 03:32:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Joe Lau Cc: mobile-ip@sunroof.eng.sun.com, jlau@cup.hp.com Subject: Re: [mobile-ip] MIPv6 draft 18 References: <200207112314.QAA15286@strtio1.cup.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Joe for your feedback, it is appreciated! Assigned issue #64. Comments inline. Joe Lau wrote: > 1. Unique Identifier option allowed on Home Test Init and Care-of Test Init? > > Page 25: > Mobility options > .... This > specification does not define any options valid for the Home > Test Init message. > > Page 26: > Mobility options > ... This > specification does not define any options valid for the Care-of > Test Init message. > > Page 119: > If the Binding Refresh Request for which the Binding Update is being > returned contains a Unique Identifier mobility option, the resulting > Home Test Init, Care-of Test Init, and Update messages MUST also > include a Unique Identifier mobility option. We missed this. Page 119 is wrong. > 2. Whether Home Address destination option MUST be included in BUs sent to HA. > > Page 12: > ... In order for the home address of the mobile node to be > visible when the policy check is made, the mobile node MUST use the > Home Address destination option in Binding Updates sent to the home > agent. > > Page 116: > - The Home Address destination option MUST be attached to the > message, unless the Source Address is the home address of the > mobile node. > > Page 121 (Returning Home): > ... The > mobile node MUST NOT include a Home Address option in this Binding > Update. > > It would be nice to have a single statement on when Home Address destination > option MUST be and when MUST NOT be included in BUs sent to HA. Yes. Page 116 is right in this case... > 3. Purpose of Home Test Init. > > Page 16: > The mobile node sends a Care-of Test Init message to the > correspondent node to acquire the care-of cookie. > > But the draft does not state: > The mobile node sends a Home Test Init message to the > correspondent node to acquire the home cookie. But it does! See bullet item 1a above the point you cite. > 4. Binding Authorization Data option is valid for what messages? > > Page 39: > > The Binding Authorization Data option is valid only in the Binding > Refresh Request, Binding Update, and Binding Acknowledgment messages. > > [then later, the draft says:] > > ... For this procedure, this option > can only appear in a Binding Update message and rules for calculating > ^^^^ The intention was to allow for the Authz Data suboption to be possible on other messages as well, if some need would arise later. Just that for the RR procedure, the only one defined now, would use it for BUs and BAs. But I see now that this is just confusing. Let's clarify that it should be present in CN BUs and BAs. > ???? > the Authenticator value are described in Section 6.1.7. > ^^^^^ > 5.2.6 Ok, will be fixed. > 5. Sequence number modulo arithmatics (15 or 16?) > > Page 64: 2**15 > Page 67: 2**16 > Page 92: 2**15 > Page 116: 2**16 > Page 131: 2**15 Great... I thought we had fixed these. It's 2**16, following the terminology in e.g. TCP RFC. > 6. Duplicated text (about 57 lines) > > Page 100: > ... On receipt of a valid Router > Advertisement, as defined in the processing algorithm specified for > Neighbor Discovery [12], the mobile node performs the following > steps, in addition to any steps already required of it by Neighbor > Discovery. > > - If the Home Agent (H) bit in the Router Advertisement is not set, > and the sending node currently has an entry in the node's Home > Agents List, delete the corresponding entry. Subsequently, skip > all of the following steps. > > .... > > A mobile node SHOULD maintain an entry in its Home Agents List for > each such valid home agent address until that entry's lifetime > expires, after which time the entry MUST be deleted. > -------------------------------------------------------------------- > > The above block of text is almost identical to that on page 84. > Duplicated text suffers the same problem as duplicated code in programming. Right. Let's refer from page 100 to page 84, or put this "code" on its own little section somewhere. > 7. Duplicated text > > Page 124: > > 11.6.9. Rate Limiting Binding Updates > > A mobile node MUST NOT send Binding Update messages for the > same binding to any individual node more often than once per > MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive > messages to a particular node with the same care-of address, the > mobile node SHOULD reduce its rate of sending these messages to that > node, to the rate of SLOW_UPDATE_RATE per second. The mobile node > MAY continue to send these messages at this slower rate indefinitely, > in hopes that the node will eventually be able to process a Binding > Update, and begin to route its packets directly to the mobile node at > its new care-of address. > --------------- > > The above block of text is almost identical to that on pag 111. > It would be nice to have a single paragraph on Rate limiting procedure. Yes, let's do it. > 3. Typo error > > Page 15: > > Due to the nearly simultaneous > message delivery, the return routability procedure completes in about > roundtrip between the mobile node and the correspondent. > ^^^^^^^^^ > How many? a single roundtrip. should be fixed. > 7. Typo error. > > Page 91: > The rules for maintaining a Home Agents List are same for home agents > and correspondent nodes, and have been described in Section 10.1. > ^^^^^^^^^^^^^^^^^^^ > mobile nodes > > ...Note that the mobile node SHOULD NOT respond > Binding Requests from previously unknown correspondent nodes due to ... > ^ > Refresh Right. Thanks. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 20:59:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22530 for ; Fri, 12 Jul 2002 20:59:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15606; Fri, 12 Jul 2002 18:55:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09362; Fri, 12 Jul 2002 17:55:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0sLoN012574 for ; Fri, 12 Jul 2002 17:54:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D0sLne012573 for mobile-ip-dist; Fri, 12 Jul 2002 17:54:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D0sIoN012566 for ; Fri, 12 Jul 2002 17:54:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23006 for ; Fri, 12 Jul 2002 17:54:19 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11344 for ; Fri, 12 Jul 2002 17:54:18 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3A9E26A901; Sat, 13 Jul 2002 03:54:17 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CD9D36A904; Sat, 13 Jul 2002 03:53:54 +0300 (EEST) Message-ID: <3D2F7A8C.4090600@kolumbus.fi> Date: Sat, 13 Jul 2002 03:55:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Vijay Devarapalli Subject: [mobile-ip] rules for using IPsec for MN-HA protection Content-Type: multipart/mixed; boundary="------------050905090001090607070505" X-Spam-Status: No, hits=0.5 required=5.0 tests=LINES_OF_YELLING version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------050905090001090607070505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Due to several requests, we have created some text that describes how IPsec is set up to protect MN-HA BUs and other messages, what the order processing is, what headers will be included in the sent packets, etc. Please send us feedback on these rules. Also, let us know if you feel some of this information should go to the MIPv6 draft in some form (I think James was suggesting something like this perhaps). Jari --------------050905090001090607070505 Content-Type: text/plain; name="ipsec_usage.txt" Content-Disposition: inline; filename="ipsec_usage.txt" Content-Transfer-Encoding: 7bit USING IPSEC TO PROTECT MOBILE IPV6 July 12th, 2002 Jari Arkko and Vijay Devaparalli 1. INTRODUCTION Mobile IPv6 uses 2. SPD Entries In the following we describe the SPD and SAD entries necessary to protect BUs and BAs exchanged between the mobile node and the home agent. We assume ESP is used with manually configured SAs. MN SPD: - if src = HoA, dst = HA and proto = MH, use SA1 - if src = HA, dst = HoA and proto = MH, use SA2 MN SAD: - SA1 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 - SA2 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 HA SPD: - if src = HA, dst = HoA and proto = MH, use SA3 - if src = HoA, dst = HA and proto = MH, use SA4 HA SAD: - SA3 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 - SA4 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 In the following we describe the necessary SPD and SAD entries to protect RR signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones above take precedence over these ones: MN SPD: - if src = HoA, dst = * and proto = MH, use SA5 - if src = *, dst = HoA and proto = MH, use SA6 MN SAD: - SA5 (ESP): src = HoA, dst = *, Mode = tunnel to HA, SPI = 5 - SA6 (ESP): src = *, dst = HoA, Mode = tunnel, SPI = 6 HA SPD: - if src = *, dst = HoA and proto = MH, use SA7 - if src = HoA, dst = * and proto = MH, use SA8 HA SAD: - SA7 (ESP): src = *, dst = HoA, Mode = tunnel to HoA, SPI = 6 - SA8 (ESP): src = HoA, dst = *, Mode = tunnel, SPI = 5 It is also possible to perform some additional, optional, protection of tunneled payload packets. This protection would take place in a similar manner to the RR protection above, but would require a different value for the protocol field. For brevity, we do not repeat the SPD entries here. In the following we describe some additional SPD and SAD entries to protect prefix discovery. (Note that when actual new prefixes are discovered, there may be a need to enter new manually configured SAs to protect BUs.) MN SPD: - if src = HoA, dst = HA and proto = ICMPv6, use SA9 - if src = HA, dst = HoA and proto = ICMPv6, use SA10 MN SAD: - SA9 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 - SA10 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 HA SPD: - if src = HA, dst = HoA and proto = ICMPv6, use SA11 - if src = HoA, dst = HA and proto = ICMPv6, use SA12 HA SAD: - SA11 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 - SA12 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 3. Packet Formats In this section we describe the order of headers within the protected and tunneled packets over the wire. The BUs sent from the mobile node to the home agent look like this: IPv6 hdr (src=CoA, dst=HA) Dst Opt HAO ESP hdr Mobility hdr BU The BAs sent back to the mobile node look like this: IPv6 hdr (src=HA, dst=CoA) Routing hdr HoA ESP hdr Mobility hdr BA The HoTI messages tunneled to the HA look like this: IPv6 hdr (CoA, HA) Dst Opt HAO ESP hdr IPv6 hdr (HoA, CN) Mobility Hdr HoTI The HoT messages tunneled from the HA look like this: IPv6 hdr (HA, CoA) Routing hdr HoA ESP hdr IPv6 hdr (CN, HoA) Mobility Hdr HoT 4. Procedures 4.1. Procedures for Sending a BU to the HA - At the MN, MIPv6 module first produces the following packet IPv6 hdr (src=HoA, dst=HA) Mobility hdr BU - This packet is detected by the IPsec filters on the MN and results in IPv6 hdr (src=HoA, dst=HA) ESP hdr Mobility hdr BU - Before forwarding the packet, the HAO (home address option) is inserted into the packet IPv6 hdr (src=CoA, dst=HA) Dst Opt HAO ESP hdr Mobility hdr BU 4.2. Procedures for Receiving a BU from the MN - The following packet is received at the HA IPv6 hdr (src=CoA, dst=HA) Dst Opt HAO ESP hdr Mobility hdr BU - The home address option is processed first, which results in IPv6 hdr (src=HoA, dst=HA) Dst Opt HAO ESP hdr Mobility hdr BU - ESP hdr is processed next, resulting in IPv6 hdr (src=HoA, dst=HA) Dst Opt HAO Mobility hdr BU - This packet matches the selectors (src = HoA, dst = HA, proto = MH). - The BU is delived to the MIPv6 module. 4.3. Procedures for Sending a BA to the MN - MIPv6 produces the following packet IPv6 hdr (src=HA, dst=HoA) Mobility hdr BA - This packet is picked up by the IPsec policy filters resulting in the use of SA3: IPv6 hdr (src=HA, dst=HoA) ESP hdr Mobility hdr BA - Before forwarding the packet, the packet is compared against the binding cache and results in: IPv6 hdr (src=HA, dst=CoA) Routing hdr HoA ESP hdr Mobility hdr BA 4.4. Procedures for Receiving a BA from the HA - The following packet is received at the MN IPv6 hdr (src=HA, dst=CoA) Routing hdr HoA ESP hdr Mobility hdr BA - After the routing header is processed the packet becomes IPv6 hdr (src=HA, dst=HoA) Routing hdr CoA ESP hdr Mobility hdr BA - ESP hdr is processed next, resulting in: IPv6 hdr (src=HA, dst=HoA) Routing hdr CoA Mobility hdr BA - The BA is delived to the MIPv6 module. 4.5. Procedures for Tunneling a HoTI to the HA - The MN constructs a HoTI message: IPv6 hdr (src=HoA, dst=CN) Mobility hdr HoTI - This matches the SPD entry for IPsec processing, resulting in: IPv6 hdr (src=HoA, dst=HA) ESP hdr IPv6 hdr (src=HoA, dst=CN) Mobility hdr HoTI - The MIPv6 code adds a Home Address option: IPv6 hdr (src=CoA, dst=HA) Dst Opt HAO ESP hdr IPv6 hdr (src=HoA, dst=CN) Mobility Hdr HoTI 4.6. Procedures for Receiving a Tunneled HoTI from the MN - The HA receives the following packet: IPv6 hdr (src=CoA, dst=HA) Dst Opt HAO ESP hdr IPv6 hdr (src=HoA, dst=CN) Mobility Hdr HoTI - The home address option is processed first, which results in IPv6 hdr (src=HoA, dst=HA) Dst Opt CoA ESP hdr IPv6 hdr (src=HoA, dst=CN) Mobility Hdr HoTI - ESP is processed next, resulting in IPv6 hdr (src=HoA, dst=CN) Mobility Hdr HoTI - The packet is then forwarded towards the CN 4.7. Procedures for Tunneling a HoT to the MN - The HA receives a HoT packet from the CN: IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI - This matches the IPsec SPD entries, resulting in the application of SA7: IPv6 hdr (src=HA, dst=HoA) ESP hdr IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI - After the routing header is processed the packet becomes IPv6 hdr (src=HA, dst=CoA) Routing hdr HoA ESP hdr IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI 4.8. Procedures for Receiving a Tunneled HoT from the HA - The MN receives the following packet: IPv6 hdr (src=HA, dst=CoA) Routing hdr HoA ESP hdr IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI - After the routing header is processed the packet becomes IPv6 hdr (src=HA, dst=HoA) Routing hdr CoA ESP hdr IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI - ESP is processed next, resulting in: IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI - This matches the selectors (src = *, dst = HoA) and the packet is given to MIPv6 processing. 5. Conclusions All addresses in the SPD entries, in the selectors, and in the tunnel gateway settings shall use the home address of the mobile node, and not the care-of address. For outbound packets, IPsec processing shall take place before mobility processing (routing headers, HAO, tunnel headers). For inbound packets, mobility processing shall take place before IPsec. All this is normal behaviour in any case. Some packets -- such as HoTI and HoT -- are protected by IPsec when tunneled via the home agent. At the HA, packet interception shall be followed by IPsec processing, and mobility delivery processing shall take place after IPsec processing. If IPsec processing does not add anything (like for example a data packet from CN to MN), the BC lookup will result in the addition of a tunnel (src = HA, dest = CoA, no routing header) to the data packet. if IPsec processing adds something (like a tunnel for HoT message), BC lookup will result in the addition of a routing header. --------------050905090001090607070505-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 12 21:01:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22592 for ; Fri, 12 Jul 2002 21:01:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03927; Fri, 12 Jul 2002 19:01:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11573; Fri, 12 Jul 2002 18:01:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D11BoN012729 for ; Fri, 12 Jul 2002 18:01:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D11BQK012728 for mobile-ip-dist; Fri, 12 Jul 2002 18:01:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D118oN012720 for ; Fri, 12 Jul 2002 18:01:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24714 for ; Fri, 12 Jul 2002 18:01:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03696 for ; Fri, 12 Jul 2002 19:01:08 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA28362; Fri, 12 Jul 2002 18:01:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6D117F20036; Fri, 12 Jul 2002 18:01:07 -0700 X-mProtect: <200207130101> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbh6Gzw; Fri, 12 Jul 2002 18:01:05 PDT Message-ID: <3D2F7BD1.BCC68477@iprg.nokia.com> Date: Fri, 12 Jul 2002 18:01:05 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It looks like we need to deal with this, so in order for ESP to be used > we need to have the alt coa option in the spec. However, I dislike > format variants, especially when the choice depends on a user-configured > SPD entry in an another part of the system. This creates an unnecessary > restriction between IPv6 stack parts. Therefore, I'd like to suggest the > alt coa option to be made a fixed field in the BU messages instead, and > to be always used. I didnt quite follow the last paragraph. for Return Routability protected BUs, there is no need for the CoA to be present as a fixed field in the BU. for ESP protected BUs, it needs to be there. so we would end up with two formats for BUs. Vijay From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 00:52:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29164 for ; Sat, 13 Jul 2002 00:52:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28354; Fri, 12 Jul 2002 21:50:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11655; Fri, 12 Jul 2002 21:50:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D4ntoN013246 for ; Fri, 12 Jul 2002 21:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D4nt8v013245 for mobile-ip-dist; Fri, 12 Jul 2002 21:49:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D4nqoN013238 for ; Fri, 12 Jul 2002 21:49:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11535 for ; Fri, 12 Jul 2002 21:49:53 -0700 (PDT) Received: from tera.ics.keio.ac.jp (tera-relay.ics.keio.ac.jp [131.113.126.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA21179 for ; Fri, 12 Jul 2002 22:49:52 -0600 (MDT) Received: (qmail 70829 invoked from network); 13 Jul 2002 04:49:13 -0000 Received: from ns.tera.ics.keio.ac.jp (HELO hotaka.tera.ics.keio.ac.jp) (131.113.100.1) by ns.tera.ics.keio.ac.jp with SMTP; 13 Jul 2002 04:49:13 -0000 Message-Id: <5.0.2.7.2.20020713134817.06300ec8@pop.tera.ics.keio.ac.jp> X-Sender: tera@pop.tera.ics.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Sat, 13 Jul 2002 13:48:23 +0900 To: mobile-ip@sunroof.eng.sun.com From: Fumio Teraoka Subject: Re: [mobile-ip] LIN6 and MobileIPv6 In-Reply-To: <3D2E7CF9.1050202@student.bth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit LIN6 and MIPv6 can coexist. There are two patent applications about LIN6, but have not been approved. LIN6 is based on a different architecture than that of MIP, i.e., separation of node ID and node locator. LIN6 has several advantages against MIPv6. For example: 1) LIN6 has no header overhead while MIPv6 uses large extension headers for every packet. 2) LIN6 is more fault tolerant than MIPv6. In MIPv6, the HA is the single point of failure and the HA cannot be replicated to the subnet other than the home network. In LIN6, the Mapping Agent can be replicated to anywhere. No modifications are necessary to applications and TCP/UDP for LIN6. LIN6 is running on several UNIX operating systems and Win2k. Source code is available from http://www.lin6.net/ Fast handoff is already implemented to LIN6 although there is no i-d of smooth handoff in LIN6. Fumio Teraoka At 02/07/12 08:53 +0200, P$BgS(B Thor$BqO(B wrote: >Hi! > >What is the relationship between the LIN6 project (http://www.lin6.net/) >and Mobile IPv6. Do they complement each other or do they compete with >each other to produce a standard to support seamless host mobility >support in IPv6? > >Any general comments on the LIN6 project? > >regards P$BgS(B > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 02:54:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11862 for ; Sat, 13 Jul 2002 02:54:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22306; Fri, 12 Jul 2002 23:53:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA21114; Fri, 12 Jul 2002 23:53:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D6qYoN013457 for ; Fri, 12 Jul 2002 23:52:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D6qYY4013456 for mobile-ip-dist; Fri, 12 Jul 2002 23:52:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D6qVoN013449 for ; Fri, 12 Jul 2002 23:52:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28101 for ; Fri, 12 Jul 2002 23:52:31 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15244 for ; Sat, 13 Jul 2002 00:52:30 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id BABE16A904; Sat, 13 Jul 2002 09:52:29 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A6916A901; Sat, 13 Jul 2002 09:52:24 +0300 (EEST) Message-ID: <3D2FCE92.60806@kolumbus.fi> Date: Sat, 13 Jul 2002 09:54:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> <3D2F7BD1.BCC68477@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Jari Arkko wrote: > > >>It looks like we need to deal with this, so in order for ESP to be used >>we need to have the alt coa option in the spec. However, I dislike >>format variants, especially when the choice depends on a user-configured >>SPD entry in an another part of the system. This creates an unnecessary >>restriction between IPv6 stack parts. Therefore, I'd like to suggest the >>alt coa option to be made a fixed field in the BU messages instead, and >>to be always used. >> > > I didnt quite follow the last paragraph. for Return Routability > protected > BUs, there is no need for the CoA to be present as a fixed field in the > BU. for ESP protected BUs, it needs to be there. so we would end up with > two formats for BUs. I agree that the alt coa is only needed in the BUs protected by IPsec, i.e. those sent to the HA. What you say about two formats for BUs is of course a possibility. On the other hand, we could just have a single format, the alt coa field doesn't break anything in the CN BUs. Other than take up some bits, of course. But this discussion leads me to think about a possible solution: what if we required the alt coa option to be present in all BUs that are not protected by RR? In the current spec this would imply having them in all HA BUs. This would keep the current formats, avoid the security problem, and avoid the need for the MIPv6 module to know what kind of IPsec is being used to protect the BUs. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 08:39:37 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22367 for ; Sat, 13 Jul 2002 08:39:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24621; Sat, 13 Jul 2002 05:38:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08761; Sat, 13 Jul 2002 05:38:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCbAoN014171 for ; Sat, 13 Jul 2002 05:37:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DCbAM0014170 for mobile-ip-dist; Sat, 13 Jul 2002 05:37:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCb7oN014163 for ; Sat, 13 Jul 2002 05:37:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08670 for ; Sat, 13 Jul 2002 05:37:09 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17310 for ; Sat, 13 Jul 2002 06:37:08 -0600 (MDT) Message-ID: <007801c22a69$c1bd5a60$056015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , References: <697DAA22C5004B4596E033803A7CEF44A13149@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Sat, 13 Jul 2002 05:35:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree. I think that is what we all want. jak ----- Original Message ----- From: To: ; Cc: ; ; Sent: Friday, July 12, 2002 1:21 PM Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions > > The Fast HO draft is not intended to specify L2 triggers. > Its primary focus is on L3 signaling to enable MIPv6 nodes > to perform fast HOs. I guess everybody acknowledges that it > is dependent on L2 triggers but in terms of what is actually > specified in the base draft w.r.t L2 triggers can be quite > abstract. The draft can simply say that a certain type of > HO or signaling is initiated as a result of some trigger from > L2. Other drafts can specify what triggers and how fast HO is > done for specific link layers. > I do not believe that this draft is the one that should be > specifying what L2 triggers exist that are the basis for fast > HO. > > > > > Hello Vijay, > > Thanks for your email. BTW, can you please > > explain how can we implement fast handoff without > > any link layer support? I also do not understand > > why standardization of FMIPv6 will get delayed > > because of L2 triggers. Is it not enough to > > document various L2 triggers and the actions to be taken > > based upon the L2 triggers? Do we need anything more than this? > > regards, > > ajoy > > > > > > Ajoy, > > > > you got me wrong. I am not against using L2 triggers. I know you > > need them to get the most optimized handovers. but we also need > > a generic FMIPv6 solution (I dont know how manys times I have > > said this now) that does not depend on L2 triggers. we need an > > RFC soon (dont you?). > > > > Vijay > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 08:39:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22383 for ; Sat, 13 Jul 2002 08:39:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22116; Sat, 13 Jul 2002 06:40:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09346; Sat, 13 Jul 2002 05:40:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCdPoN014248 for ; Sat, 13 Jul 2002 05:39:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DCdP7e014247 for mobile-ip-dist; Sat, 13 Jul 2002 05:39:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCdMoN014240 for ; Sat, 13 Jul 2002 05:39:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16314 for ; Sat, 13 Jul 2002 05:39:24 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04184 for ; Sat, 13 Jul 2002 05:39:24 -0700 (PDT) Message-ID: <008001c22a6a$15a26760$056015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , "Singh Ajoy-ASINGH1" Cc: "Rajeev Koodli" , References: <3D2F4461.F1F8E22B@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Sat, 13 Jul 2002 05:37:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, > I am afraid Section 3.2.1 of draft 4 will hold back the draft > from advancing unless there is a standard way of doing L2-ST, > L2-TT, L2-LD, L2-LU. even if there is a standard way of doing > the triggers, there has to be some kind of reference that FMIPv6 > can quote. I am afraid that is not there (or wont there when > we need to advance FMIPv6) > Would your opinion change if these triggers were described in the abstract within the document? Similar to what Charlie and I discussed the other day? Thus, there would be no normative references outside the document. jak From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 08:49:25 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22608 for ; Sat, 13 Jul 2002 08:49:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05853; Sat, 13 Jul 2002 05:47:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09805; Sat, 13 Jul 2002 05:47:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCl6oN014441 for ; Sat, 13 Jul 2002 05:47:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DCl63c014440 for mobile-ip-dist; Sat, 13 Jul 2002 05:47:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DCl3oN014433 for ; Sat, 13 Jul 2002 05:47:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10243 for ; Sat, 13 Jul 2002 05:47:04 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23423 for ; Sat, 13 Jul 2002 06:46:58 -0600 (MDT) Message-ID: <00a201c22a6b$227b04f0$056015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , References: <697DAA22C5004B4596E033803A7CEF440969AF@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Sat, 13 Jul 2002 05:45:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Raj, I don't think it is quite as simple as just documenting the L3 behavior. For example, if there is no prehandover notification, it is impossible to do address preconfiguration. Similarly, if there is prehandover notification on the access router with the appropriate information, it is possible to do tunnel establishment without any over the air signaling. Both of these are considerably more optimized than what draft 05 seems to allow as a nonerror case. I think it should be possible to state what the layer 2 requirements are for particular optimized sequences of layer 3 signaling without going down the path of specifying triggers for specific layer 2s. That is what the layer 2 triggers draft was attempting to do, but perhaps it has become too specific. jak ----- Original Message ----- From: To: ; Cc: ; ; Sent: Friday, July 12, 2002 2:22 PM Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions > > Ajoy, > > > > > Basavraj, > > I am not asking to specify L2 trigger in fast handoff draft. > > We just have to state the appropriate L3 behaviors when > > specific link layer triggers are available. BTW, that is what > > I think we are agreeing on the general approach on how to deal > with triggers. All I am saying is that if link layer X provides > specific triggers to the upper layer, a separate I-D can > document how fast HO will work when these triggers (which would > be identified in that draft) are available. > So rather than going down the path of identifying all the possible > link layer triggers and the corresponding behavior at L3, the > base FMIPv6 draft should simply document the L3 behavior. > > > is done in version V4 of the FMIPv6 draft. > > And my belief is that the current L2 triggers specification in the > version 4 of the draft is of really no help and needs to be moved > to a more appropriate draft that deals with these triggers,. > > > regards, > > ajoy > > > > Cheers, > -Basavaraj > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 09:05:55 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22912 for ; Sat, 13 Jul 2002 09:05:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28956; Sat, 13 Jul 2002 06:04:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20088; Sat, 13 Jul 2002 06:04:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DD3NoN014591 for ; Sat, 13 Jul 2002 06:03:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DD3NMj014590 for mobile-ip-dist; Sat, 13 Jul 2002 06:03:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DD3KoN014583 for ; Sat, 13 Jul 2002 06:03:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19941 for ; Sat, 13 Jul 2002 06:03:22 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22535 for ; Sat, 13 Jul 2002 07:03:21 -0600 (MDT) Message-ID: <00ed01c22a6d$66a47150$056015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , "Jari Arkko" Cc: References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> <3D2F7BD1.BCC68477@iprg.nokia.com> Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt Date: Sat, 13 Jul 2002 06:01:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Why not have it be an option? There will likely be other algorithms that will be used for protecting BUs and they may need other stuff. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Jari Arkko" Cc: Sent: Friday, July 12, 2002 6:01 PM Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt > Jari Arkko wrote: > > > It looks like we need to deal with this, so in order for ESP to be used > > we need to have the alt coa option in the spec. However, I dislike > > format variants, especially when the choice depends on a user-configured > > SPD entry in an another part of the system. This creates an unnecessary > > restriction between IPv6 stack parts. Therefore, I'd like to suggest the > > alt coa option to be made a fixed field in the BU messages instead, and > > to be always used. > > I didnt quite follow the last paragraph. for Return Routability > protected > BUs, there is no need for the CoA to be present as a fixed field in the > BU. for ESP protected BUs, it needs to be there. so we would end up with > two formats for BUs. > > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 09:21:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23231 for ; Sat, 13 Jul 2002 09:21:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20166; Sat, 13 Jul 2002 07:21:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16539; Sat, 13 Jul 2002 06:21:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DDK9oN014740 for ; Sat, 13 Jul 2002 06:20:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DDK9Ow014739 for mobile-ip-dist; Sat, 13 Jul 2002 06:20:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DDK5oN014730 for ; Sat, 13 Jul 2002 06:20:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22051 for ; Sat, 13 Jul 2002 06:20:08 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01509 for ; Sat, 13 Jul 2002 06:20:07 -0700 (PDT) Message-ID: <013c01c22a6f$c4e67810$056015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: "Vijay Devarapalli" References: <3D2F7A8C.4090600@kolumbus.fi> Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection Date: Sat, 13 Jul 2002 06:10:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit One question: Are manual SAs required or was that just a convenience for specifying what the SPD and SAD entries look like? jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "Vijay Devarapalli" Sent: Friday, July 12, 2002 5:55 PM Subject: [mobile-ip] rules for using IPsec for MN-HA protection > > Due to several requests, we have created some text that describes > how IPsec is set up to protect MN-HA BUs and other messages, what > the order processing is, what headers will be included in the sent > packets, etc. > > Please send us feedback on these rules. Also, let us know if you > feel some of this information should go to the MIPv6 draft in some > form (I think James was suggesting something like this perhaps). > > Jari > -------------------------------------------------------------------------------- > > USING IPSEC TO PROTECT MOBILE IPV6 > > July 12th, 2002 > Jari Arkko and Vijay Devaparalli > > 1. INTRODUCTION > > Mobile IPv6 uses > > 2. SPD Entries > > In the following we describe the SPD and SAD entries necessary to > protect BUs and BAs exchanged between the mobile node and the home > agent. We assume ESP is used with manually configured SAs. > > MN SPD: - if src = HoA, dst = HA and proto = MH, use SA1 > - if src = HA, dst = HoA and proto = MH, use SA2 > MN SAD: - SA1 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 > - SA2 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 > > HA SPD: - if src = HA, dst = HoA and proto = MH, use SA3 > - if src = HoA, dst = HA and proto = MH, use SA4 > HA SAD: - SA3 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 > - SA4 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 > > In the following we describe the necessary SPD and SAD entries to > protect RR signaling between the mobile node and the home agent. > Note that the rules in the SPD are ordered, and the ones above > take precedence over these ones: > > MN SPD: - if src = HoA, dst = * and proto = MH, use SA5 > - if src = *, dst = HoA and proto = MH, use SA6 > MN SAD: - SA5 (ESP): src = HoA, dst = *, Mode = tunnel to HA, SPI = 5 > - SA6 (ESP): src = *, dst = HoA, Mode = tunnel, SPI = 6 > > HA SPD: - if src = *, dst = HoA and proto = MH, use SA7 > - if src = HoA, dst = * and proto = MH, use SA8 > HA SAD: - SA7 (ESP): src = *, dst = HoA, Mode = tunnel to HoA, SPI = 6 > - SA8 (ESP): src = HoA, dst = *, Mode = tunnel, SPI = 5 > > It is also possible to perform some additional, optional, protection > of tunneled payload packets. This protection would take place in a > similar manner to the RR protection above, but would require a > different value for the protocol field. For brevity, we do not repeat > the SPD entries here. > > In the following we describe some additional SPD and SAD entries to > protect prefix discovery. (Note that when actual new prefixes are > discovered, there may be a need to enter new manually configured SAs > to protect BUs.) > > MN SPD: - if src = HoA, dst = HA and proto = ICMPv6, use SA9 > - if src = HA, dst = HoA and proto = ICMPv6, use SA10 > MN SAD: - SA9 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 > - SA10 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 > > HA SPD: - if src = HA, dst = HoA and proto = ICMPv6, use SA11 > - if src = HoA, dst = HA and proto = ICMPv6, use SA12 > HA SAD: - SA11 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 > - SA12 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 > > 3. Packet Formats > > In this section we describe the order of headers within the protected > and tunneled packets over the wire. > > The BUs sent from the mobile node to the home agent look like this: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > The BAs sent back to the mobile node look like this: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > The HoTI messages tunneled to the HA look like this: > > IPv6 hdr (CoA, HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (HoA, CN) > Mobility Hdr > HoTI > > The HoT messages tunneled from the HA look like this: > > IPv6 hdr (HA, CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (CN, HoA) > Mobility Hdr > HoT > > 4. Procedures > > 4.1. Procedures for Sending a BU to the HA > > - At the MN, MIPv6 module first produces the following packet > > IPv6 hdr (src=HoA, dst=HA) > Mobility hdr > BU > > - This packet is detected by the IPsec filters on the MN and results in > > IPv6 hdr (src=HoA, dst=HA) > ESP hdr > Mobility hdr > BU > > - Before forwarding the packet, the HAO (home address option) is inserted > into the packet > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > 4.2. Procedures for Receiving a BU from the MN > > - The following packet is received at the HA > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > - The home address option is processed first, which results in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > - ESP hdr is processed next, resulting in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > HAO > Mobility hdr > BU > > - This packet matches the selectors (src = HoA, dst = HA, proto = MH). > > - The BU is delived to the MIPv6 module. > > 4.3. Procedures for Sending a BA to the MN > > - MIPv6 produces the following packet > > IPv6 hdr (src=HA, dst=HoA) > Mobility hdr > BA > > - This packet is picked up by the IPsec policy filters resulting in > the use of SA3: > > IPv6 hdr (src=HA, dst=HoA) > ESP hdr > Mobility hdr > BA > > - Before forwarding the packet, the packet is compared against the > binding cache and results in: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > 4.4. Procedures for Receiving a BA from the HA > > - The following packet is received at the MN > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > ESP hdr > Mobility hdr > BA > > - ESP hdr is processed next, resulting in: > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > Mobility hdr > BA > > - The BA is delived to the MIPv6 module. > > 4.5. Procedures for Tunneling a HoTI to the HA > > - The MN constructs a HoTI message: > > IPv6 hdr (src=HoA, dst=CN) > Mobility hdr > HoTI > > - This matches the SPD entry for IPsec processing, > resulting in: > > IPv6 hdr (src=HoA, dst=HA) > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility hdr > HoTI > > - The MIPv6 code adds a Home Address option: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > 4.6. Procedures for Receiving a Tunneled HoTI from the MN > > - The HA receives the following packet: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - The home address option is processed first, which results in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > CoA > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - ESP is processed next, resulting in > > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - The packet is then forwarded towards the CN > > 4.7. Procedures for Tunneling a HoT to the MN > > - The HA receives a HoT packet from the CN: > > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - This matches the IPsec SPD entries, resulting in the > application of SA7: > > IPv6 hdr (src=HA, dst=HoA) > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > 4.8. Procedures for Receiving a Tunneled HoT from the HA > > - The MN receives the following packet: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - ESP is processed next, resulting in: > > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - This matches the selectors (src = *, dst = HoA) and the packet is > given to MIPv6 processing. > > 5. Conclusions > > All addresses in the SPD entries, in the selectors, and in the tunnel > gateway settings shall use the home address of the mobile node, and > not the care-of address. > > For outbound packets, IPsec processing shall take place before > mobility processing (routing headers, HAO, tunnel headers). For > inbound packets, mobility processing shall take place before IPsec. > All this is normal behaviour in any case. > > Some packets -- such as HoTI and HoT -- are protected by IPsec when > tunneled via the home agent. At the HA, packet interception shall be > followed by IPsec processing, and mobility delivery processing shall > take place after IPsec processing. If IPsec processing does not add > anything (like for example a data packet from CN to MN), the BC lookup > will result in the addition of a tunnel (src = HA, dest = CoA, no > routing header) to the data packet. if IPsec processing adds > something (like a tunnel for HoT message), BC lookup will result in > the addition of a routing header. > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 13 09:21:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23244 for ; Sat, 13 Jul 2002 09:21:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01413; Sat, 13 Jul 2002 07:21:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15067; Sat, 13 Jul 2002 06:21:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DDK5oN014732 for ; Sat, 13 Jul 2002 06:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DDK5x7014729 for mobile-ip-dist; Sat, 13 Jul 2002 06:20:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DDK2oN014722 for ; Sat, 13 Jul 2002 06:20:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16302 for ; Sat, 13 Jul 2002 06:20:04 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01111 for ; Sat, 13 Jul 2002 07:20:02 -0600 (MDT) Message-ID: <013b01c22a6f$c1be3600$056015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: "Vijay Devarapalli" References: <3D2F7A8C.4090600@kolumbus.fi> Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection Date: Sat, 13 Jul 2002 06:08:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Excellent! That is what I was looking for. jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "Vijay Devarapalli" Sent: Friday, July 12, 2002 5:55 PM Subject: [mobile-ip] rules for using IPsec for MN-HA protection > > Due to several requests, we have created some text that describes > how IPsec is set up to protect MN-HA BUs and other messages, what > the order processing is, what headers will be included in the sent > packets, etc. > > Please send us feedback on these rules. Also, let us know if you > feel some of this information should go to the MIPv6 draft in some > form (I think James was suggesting something like this perhaps). > > Jari > -------------------------------------------------------------------------------- > > USING IPSEC TO PROTECT MOBILE IPV6 > > July 12th, 2002 > Jari Arkko and Vijay Devaparalli > > 1. INTRODUCTION > > Mobile IPv6 uses > > 2. SPD Entries > > In the following we describe the SPD and SAD entries necessary to > protect BUs and BAs exchanged between the mobile node and the home > agent. We assume ESP is used with manually configured SAs. > > MN SPD: - if src = HoA, dst = HA and proto = MH, use SA1 > - if src = HA, dst = HoA and proto = MH, use SA2 > MN SAD: - SA1 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 > - SA2 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 > > HA SPD: - if src = HA, dst = HoA and proto = MH, use SA3 > - if src = HoA, dst = HA and proto = MH, use SA4 > HA SAD: - SA3 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 2 > - SA4 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 1 > > In the following we describe the necessary SPD and SAD entries to > protect RR signaling between the mobile node and the home agent. > Note that the rules in the SPD are ordered, and the ones above > take precedence over these ones: > > MN SPD: - if src = HoA, dst = * and proto = MH, use SA5 > - if src = *, dst = HoA and proto = MH, use SA6 > MN SAD: - SA5 (ESP): src = HoA, dst = *, Mode = tunnel to HA, SPI = 5 > - SA6 (ESP): src = *, dst = HoA, Mode = tunnel, SPI = 6 > > HA SPD: - if src = *, dst = HoA and proto = MH, use SA7 > - if src = HoA, dst = * and proto = MH, use SA8 > HA SAD: - SA7 (ESP): src = *, dst = HoA, Mode = tunnel to HoA, SPI = 6 > - SA8 (ESP): src = HoA, dst = *, Mode = tunnel, SPI = 5 > > It is also possible to perform some additional, optional, protection > of tunneled payload packets. This protection would take place in a > similar manner to the RR protection above, but would require a > different value for the protocol field. For brevity, we do not repeat > the SPD entries here. > > In the following we describe some additional SPD and SAD entries to > protect prefix discovery. (Note that when actual new prefixes are > discovered, there may be a need to enter new manually configured SAs > to protect BUs.) > > MN SPD: - if src = HoA, dst = HA and proto = ICMPv6, use SA9 > - if src = HA, dst = HoA and proto = ICMPv6, use SA10 > MN SAD: - SA9 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 > - SA10 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 > > HA SPD: - if src = HA, dst = HoA and proto = ICMPv6, use SA11 > - if src = HoA, dst = HA and proto = ICMPv6, use SA12 > HA SAD: - SA11 (ESP): src = HA, dst = HoA, Mode = transport, SPI = 10 > - SA12 (ESP): src = HoA, dst = HA, Mode = transport, SPI = 9 > > 3. Packet Formats > > In this section we describe the order of headers within the protected > and tunneled packets over the wire. > > The BUs sent from the mobile node to the home agent look like this: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > The BAs sent back to the mobile node look like this: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > The HoTI messages tunneled to the HA look like this: > > IPv6 hdr (CoA, HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (HoA, CN) > Mobility Hdr > HoTI > > The HoT messages tunneled from the HA look like this: > > IPv6 hdr (HA, CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (CN, HoA) > Mobility Hdr > HoT > > 4. Procedures > > 4.1. Procedures for Sending a BU to the HA > > - At the MN, MIPv6 module first produces the following packet > > IPv6 hdr (src=HoA, dst=HA) > Mobility hdr > BU > > - This packet is detected by the IPsec filters on the MN and results in > > IPv6 hdr (src=HoA, dst=HA) > ESP hdr > Mobility hdr > BU > > - Before forwarding the packet, the HAO (home address option) is inserted > into the packet > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > 4.2. Procedures for Receiving a BU from the MN > > - The following packet is received at the HA > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > - The home address option is processed first, which results in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > HAO > ESP hdr > Mobility hdr > BU > > - ESP hdr is processed next, resulting in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > HAO > Mobility hdr > BU > > - This packet matches the selectors (src = HoA, dst = HA, proto = MH). > > - The BU is delived to the MIPv6 module. > > 4.3. Procedures for Sending a BA to the MN > > - MIPv6 produces the following packet > > IPv6 hdr (src=HA, dst=HoA) > Mobility hdr > BA > > - This packet is picked up by the IPsec policy filters resulting in > the use of SA3: > > IPv6 hdr (src=HA, dst=HoA) > ESP hdr > Mobility hdr > BA > > - Before forwarding the packet, the packet is compared against the > binding cache and results in: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > 4.4. Procedures for Receiving a BA from the HA > > - The following packet is received at the MN > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > Mobility hdr > BA > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > ESP hdr > Mobility hdr > BA > > - ESP hdr is processed next, resulting in: > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > Mobility hdr > BA > > - The BA is delived to the MIPv6 module. > > 4.5. Procedures for Tunneling a HoTI to the HA > > - The MN constructs a HoTI message: > > IPv6 hdr (src=HoA, dst=CN) > Mobility hdr > HoTI > > - This matches the SPD entry for IPsec processing, > resulting in: > > IPv6 hdr (src=HoA, dst=HA) > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility hdr > HoTI > > - The MIPv6 code adds a Home Address option: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > 4.6. Procedures for Receiving a Tunneled HoTI from the MN > > - The HA receives the following packet: > > IPv6 hdr (src=CoA, dst=HA) > Dst Opt > HAO > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - The home address option is processed first, which results in > > IPv6 hdr (src=HoA, dst=HA) > Dst Opt > CoA > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - ESP is processed next, resulting in > > IPv6 hdr (src=HoA, dst=CN) > Mobility Hdr > HoTI > > - The packet is then forwarded towards the CN > > 4.7. Procedures for Tunneling a HoT to the MN > > - The HA receives a HoT packet from the CN: > > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - This matches the IPsec SPD entries, resulting in the > application of SA7: > > IPv6 hdr (src=HA, dst=HoA) > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > 4.8. Procedures for Receiving a Tunneled HoT from the HA > > - The MN receives the following packet: > > IPv6 hdr (src=HA, dst=CoA) > Routing hdr > HoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - After the routing header is processed the packet becomes > > IPv6 hdr (src=HA, dst=HoA) > Routing hdr > CoA > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - ESP is processed next, resulting in: > > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > - This matches the selectors (src = *, dst = HoA) and the packet is > given to MIPv6 processing. > > 5. Conclusions > > All addresses in the SPD entries, in the selectors, and in the tunnel > gateway settings shall use the home address of the mobile node, and > not the care-of address. > > For outbound packets, IPsec processing shall take place before > mobility processing (routing headers, HAO, tunnel headers). For > inbound packets, mobility processing shall take place before IPsec. > All this is normal behaviour in any case. > > Some packets -- such as HoTI and HoT -- are protected by IPsec when > tunneled via the home agent. At the HA, packet interception shall be > followed by IPsec processing, and mobility delivery processing shall > take place after IPsec processing. If IPsec processing does not add > anything (like for example a data packet from CN to MN), the BC lookup > will result in the addition of a tunnel (src = HA, dest = CoA, no > routing header) to the data packet. if IPsec processing adds > something (like a tunnel for HoT message), BC lookup will result in > the addition of a routing header. > From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 11:24:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09140 for ; Sun, 14 Jul 2002 11:24:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23817; Sun, 14 Jul 2002 09:21:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06264; Sun, 14 Jul 2002 08:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EFKvoN016617 for ; Sun, 14 Jul 2002 08:20:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6EFKuKi016616 for mobile-ip-dist; Sun, 14 Jul 2002 08:20:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EFKroN016609 for ; Sun, 14 Jul 2002 08:20:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06165 for ; Sun, 14 Jul 2002 08:20:55 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00925 for ; Sun, 14 Jul 2002 09:20:53 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id AAA07796 for ; Mon, 15 Jul 2002 00:20:50 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id AAA24411 for ; Mon, 15 Jul 2002 00:20:49 +0900 (JST) Date: Mon, 15 Jul 2002 00:19:26 +0900 (JST) Message-Id: <20020715.001926.74753480.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] comments onf draft-18 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Let me confirm the meanings of the section 8.1. > 8.1. General Requirements for All IPv6 Nodes > > Any IPv6 node may at any time be a correspondent node of a mobile > node, either sending a packet to a mobile node or receiving a > packet from a mobile node. The following requirements are necessary > for every IPv6 node (whether host or router, whether mobile or > stationary), since otherwise communications may be impossible: > > - The node MUST be able to validate a Home Address option received > in any IPv6 packet as described in Section 9.2.2. > > - The node MUST be able to send a Binding Error message as > described in Section 9.4.6. The section 8.1 describes the requirements for all IPv6 nodes. What is 'all IPv6 nodes'? Does it mean 'all IPv6 nodes which supports mobile ipv6'? If so, it is OK for me. My question ends. If it means 'all IPv6 nodes even if they have nothing to do with mobile ipv6', why must all IPv6 nodes support HAO and BE processing? The node which doesn't support HAO will send ICMP paramprob back to the sender (mobile node). Mobile nodes can communicate using bi-directional tunneling with such nodes. If you are thinking of IPseced HAO, I think it better to be separated from the base document. I don't think it acceptable for the IPv6 WG to make HAO/BE be MUST. I' sorry for my very late replying... --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 11:38:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09565 for ; Sun, 14 Jul 2002 11:38:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14720; Sun, 14 Jul 2002 08:36:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08549; Sun, 14 Jul 2002 08:36:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EFZooN016768 for ; Sun, 14 Jul 2002 08:35:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6EFZo3n016767 for mobile-ip-dist; Sun, 14 Jul 2002 08:35:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EFZloN016760 for ; Sun, 14 Jul 2002 08:35:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08434 for ; Sun, 14 Jul 2002 08:35:48 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04646 for ; Sun, 14 Jul 2002 09:35:47 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id AAA07874 for ; Mon, 15 Jul 2002 00:35:46 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id AAA25419 for ; Mon, 15 Jul 2002 00:35:46 +0900 (JST) Date: Mon, 15 Jul 2002 00:34:26 +0900 (JST) Message-Id: <20020715.003426.95886678.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] comments: draft-18 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I have one more question about draft-18. There is no text which describes the relation between ND packets and HAO. If a mobile node sends NS with HAO to a correpondent node's global address, the response (NA) will be sent to the home agent of the mobile node (if the CN doesn't have a BCE for the MN) or be sent to the mobile node's HoA with RTHDR2 (if the CN has a BCE for the MN). In section 11.2.1, the spec says that the MN MAY ommit HAO for short term communication. But I think it is not enough. HAO MUST NOT be inserted to NS packets because NAs never reach to the MN. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 17:34:47 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17540 for ; Sun, 14 Jul 2002 17:34:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22303; Sun, 14 Jul 2002 14:32:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01613; Sun, 14 Jul 2002 14:32:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ELVRoN017179 for ; Sun, 14 Jul 2002 14:31:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ELVRgQ017178 for mobile-ip-dist; Sun, 14 Jul 2002 14:31:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ELVOoN017171 for ; Sun, 14 Jul 2002 14:31:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01340 for ; Sun, 14 Jul 2002 14:31:25 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21964 for ; Sun, 14 Jul 2002 14:31:25 -0700 (PDT) Message-ID: <004701c22b7d$948d9bd0$0e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Reminder:BAR BOF on BU AltSecurity Date: Sun, 14 Jul 2002 14:24:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There will be a BAR BOF for discussing alternate BU security algorithms tonight immediately after the MIP meeting. Let's meet in the MIP meeting room on the left side (facing the front) and proceed from there. jak From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 18:13:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18632 for ; Sun, 14 Jul 2002 18:13:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27821; Sun, 14 Jul 2002 16:13:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08076; Sun, 14 Jul 2002 15:13:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EMCtoN017390 for ; Sun, 14 Jul 2002 15:12:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6EMCtib017389 for mobile-ip-dist; Sun, 14 Jul 2002 15:12:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EMCqoN017382 for ; Sun, 14 Jul 2002 15:12:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08023 for ; Sun, 14 Jul 2002 15:12:54 -0700 (PDT) Received: from cichlid.adsl.duke.edu (ietf-wireless-dhcp-78-237.dyn.ietf54.wide.ad.jp [133.93.78.237]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22466 for ; Sun, 14 Jul 2002 16:12:53 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g6EMBoU18761; Sun, 14 Jul 2002 18:11:50 -0400 Message-Id: <200207142211.g6EMBoU18761@cichlid.adsl.duke.edu> To: "James Kempf" cc: "Jari Arkko" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt In-Reply-To: Message from "James Kempf" of "Tue, 09 Jul 2002 11:30:39 PDT." <014d01c22776$b9efcd40$4f6015ac@T23KEMPF> Date: Sun, 14 Jul 2002 18:11:50 -0400 From: Thomas Narten Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Hmm... why? Other standards track RFCs appear to have normative > > and non-normative references, see for instance the SIP, RFC 3261. > > > > > OK, I wasn't aware of the precedent. This must be new, the RFC > editor never allowed nonnormative references before. There is confusion here. the RFC editor has always allowed non-normative references. What it doesn't allow is normative references to IDs that are not ready for publishing yet. Thus, it is important to distinguish between references that are normative and those that are not. The publishing of an RFC is generally blocked until all references to normative documents can be satisified. References to non-normative documents are simply cited as "works in progress". Thomas From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 21:34:47 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23908 for ; Sun, 14 Jul 2002 21:34:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06395; Sun, 14 Jul 2002 19:34:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01788; Sun, 14 Jul 2002 18:34:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F1XboN017763 for ; Sun, 14 Jul 2002 18:33:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F1XaGL017762 for mobile-ip-dist; Sun, 14 Jul 2002 18:33:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F1XXoN017755 for ; Sun, 14 Jul 2002 18:33:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01576 for ; Sun, 14 Jul 2002 18:33:34 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17943 for ; Sun, 14 Jul 2002 19:33:33 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6F1XUC18620; Mon, 15 Jul 2002 03:33:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id DAA00348; Mon, 15 Jul 2002 03:33:30 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6F1XSGF060243; Mon, 15 Jul 2002 03:33:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207150133.g6F1XSGF060243@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-reply-to: Your message of Sat, 13 Jul 2002 03:55:40 +0300. <3D2F7A8C.4090600@kolumbus.fi> Date: Mon, 15 Jul 2002 03:33:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: 2. SPD Entries => you should add the direction (in/out) and (funny?) the interface. We assume ESP is used with manually configured SAs. => I have a real concern about this assumption: we should use something like IKE (and we know how to use it in fact, don't forget that near I-D 13 we had some interoperable implementations with full IPsec). BTW low SPIs are *reserved*. Last point, for these entries (i.e., not the RR pair, ...), AH is enough and should be allowed. 3. Packet Formats The HoTI messages tunneled to the HA look like this: IPv6 hdr (CoA, HA) Dst Opt HAO => why a HAO here? This is a *tunnel*! ESP hdr IPv6 hdr (HoA, CN) Mobility Hdr HoTI The HoT messages tunneled from the HA look like this: IPv6 hdr (HA, CoA) Routing hdr HoA => same concern. ESP hdr IPv6 hdr (CN, HoA) Mobility Hdr HoT 4.5. Procedures for Tunneling a HoTI to the HA - This matches the SPD entry for IPsec processing, resulting in: IPv6 hdr (src=HoA, dst=HA) ESP hdr IPv6 hdr (src=HoA, dst=CN) Mobility hdr HoTI => NO, the tunnel has CoA and HA outer addresses! 4.7. Procedures for Tunneling a HoT to the MN - This matches the IPsec SPD entries, resulting in the application of SA7: IPv6 hdr (src=HA, dst=HoA) ESP hdr IPv6 hdr (src=CN, dst=HoA) Mobility Hdr HoTI => same problem. 5. Conclusions All addresses in the SPD entries, in the selectors, and in the tunnel gateway settings shall use the home address of the mobile node, and not the care-of address. => please add "traffic" before the word "selectors". For outbound packets, IPsec processing shall take place before mobility processing (routing headers, HAO, tunnel headers). For inbound packets, mobility processing shall take place before IPsec. All this is normal behaviour in any case. Some packets -- such as HoTI and HoT -- are protected by IPsec when tunneled via the home agent. At the HA, packet interception shall be followed by IPsec processing, and mobility delivery processing shall take place after IPsec processing. If IPsec processing does not add anything (like for example a data packet from CN to MN), the BC lookup will result in the addition of a tunnel (src = HA, dest = CoA, no routing header) to the data packet. if IPsec processing adds something (like a tunnel for HoT message), BC lookup will result in the addition of a routing header. => no, it is deeply stupid to add a degenerated tunnel stuff to an already encapsulated packet: just use the correct addresses! Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 14 23:02:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27559 for ; Sun, 14 Jul 2002 23:02:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26747; Sun, 14 Jul 2002 21:02:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11233; Sun, 14 Jul 2002 20:02:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F321oN018108 for ; Sun, 14 Jul 2002 20:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F321tJ018107 for mobile-ip-dist; Sun, 14 Jul 2002 20:02:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F31woN018100 for ; Sun, 14 Jul 2002 20:01:58 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21445 for ; Sun, 14 Jul 2002 20:02:00 -0700 (PDT) Received: from illusionsoft.www.iwjx.com (illusionsoft.www.iwjx.com [217.29.195.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26482 for ; Sun, 14 Jul 2002 21:01:59 -0600 (MDT) Received: from justmailz.com (unverified [127.0.0.1]) by illusionsoft.www.iwjx.com (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Mon, 15 Jul 2002 04:04:03 +0100 Message-ID: <152130-220027115343828@justmailz.com> X-EM-Version: 6, 0, 0, 6 X-EM-Registration: #00E0620610781F002A20 X-Priority: 3 From: "shima" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] need advice Date: Mon, 15 Jul 2002 04:04:03 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi I'm Msc.srudent ...I decided to do my thesis in handover ,I have read drafts and papers for the achievement of fast handover but i felt that i got lost...so i need an advice to the right way. thanka in advance...... lalo ______________________________________________________________________ Get Free POP & IMAP Email Accounts on www.justmailz.com ! Quote : "I'm fed up to the ears with old men dreaming up wars for young men to die in." From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 00:03:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29312 for ; Mon, 15 Jul 2002 00:03:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26667; Sun, 14 Jul 2002 22:03:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18158; Sun, 14 Jul 2002 21:03:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F42EoN018314 for ; Sun, 14 Jul 2002 21:02:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F42EHK018313 for mobile-ip-dist; Sun, 14 Jul 2002 21:02:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F42AoN018304 for ; Sun, 14 Jul 2002 21:02:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02780 for ; Sun, 14 Jul 2002 21:02:13 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02882 for ; Sun, 14 Jul 2002 21:02:13 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id C2C366A906; Mon, 15 Jul 2002 07:02:06 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9B7736A905; Mon, 15 Jul 2002 07:01:48 +0300 (EEST) Message-ID: <3D324997.10103@kolumbus.fi> Date: Mon, 15 Jul 2002 07:03:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection References: <3D2F7A8C.4090600@kolumbus.fi> <013c01c22a6f$c4e67810$056015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > One question: > > Are manual SAs required or was that just a convenience for specifying what the SPD and SAD entries look like? Dynamically established SAs are also possible. A different security policy set up is needed. Or to be more exact, a different security policy set up is more useful with dynamic keying, as you may not need to deal with individual entries for all mobile nodes. It looks like it would be useful to have some text that describes the dynamic set up as well. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 00:32:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00207 for ; Mon, 15 Jul 2002 00:32:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16719; Sun, 14 Jul 2002 22:32:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27491; Sun, 14 Jul 2002 21:32:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F4VroN018492 for ; Sun, 14 Jul 2002 21:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F4VrDt018491 for mobile-ip-dist; Sun, 14 Jul 2002 21:31:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F4VooN018484 for ; Sun, 14 Jul 2002 21:31:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21828 for ; Sun, 14 Jul 2002 21:31:51 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04326 for ; Sun, 14 Jul 2002 22:31:50 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F08466A906; Mon, 15 Jul 2002 07:31:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AEF376A905; Mon, 15 Jul 2002 07:31:40 +0300 (EEST) Message-ID: <3D325097.5000406@kolumbus.fi> Date: Mon, 15 Jul 2002 07:33:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection References: <200207150133.g6F1XSGF060243@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Francis for taking a look at this. I was about to ask you to review the rules anyway ;-) Some discussion inline below: > 2. SPD Entries > > => you should add the direction (in/out) and (funny?) the interface. Yes. > We assume ESP is used with manually configured SAs. > > => I have a real concern about this assumption: we should use > something like IKE (and we know how to use it in fact, don't forget > that near I-D 13 we had some interoperable implementations with full > IPsec). I agree... the intention is to write another example that shows how to set up IKE-based security. > BTW low SPIs are *reserved*. Right ;-) > Last point, for these entries > (i.e., not the RR pair, ...), AH is enough and should be allowed. Agreed. Draft 18 should allow any type of IPsec to be used (except for RR encryption). The text above should have read "Our examples assume ESP is used..." > 3. Packet Formats > > The HoTI messages tunneled to the HA look like this: > > IPv6 hdr (CoA, HA) > Dst Opt > HAO > > => why a HAO here? This is a *tunnel*! > > ESP hdr > IPv6 hdr (HoA, CN) > Mobility Hdr > HoTI > > The HoT messages tunneled from the HA look like this: > > IPv6 hdr (HA, CoA) > Routing hdr > HoA > > => same concern. The question is: do we first encapsulate in an IPv6 tunnel due to normal MIPv6 tunneling principles and then apply IPsec, or do we first apply IPsec and only then check if MIPv6 tunneling is necessary? If we do the former, I'm not sure how we can make the SPD entries specific enough so that they would match only the MH messages, but leave rest of traffic in the clear. Can IPsec SPD entries see through the tunnel header? > ESP hdr > IPv6 hdr (CN, HoA) > Mobility Hdr > HoT > > 4.5. Procedures for Tunneling a HoTI to the HA > > - This matches the SPD entry for IPsec processing, > resulting in: > > IPv6 hdr (src=HoA, dst=HA) > ESP hdr > IPv6 hdr (src=HoA, dst=CN) > Mobility hdr > HoTI > > => NO, the tunnel has CoA and HA outer addresses! See above for a discussion of tunnel-first-then-ipsec vs. ipsec-first-then-tunnel. > 4.7. Procedures for Tunneling a HoT to the MN > > - This matches the IPsec SPD entries, resulting in the > application of SA7: > > IPv6 hdr (src=HA, dst=HoA) > ESP hdr > IPv6 hdr (src=CN, dst=HoA) > Mobility Hdr > HoTI > > => same problem. > > 5. Conclusions > > All addresses in the SPD entries, in the selectors, and in the tunnel > gateway settings shall use the home address of the mobile node, and > not the care-of address. > > => please add "traffic" before the word "selectors". Ok. > For outbound packets, IPsec processing shall take place before > mobility processing (routing headers, HAO, tunnel headers). For > inbound packets, mobility processing shall take place before IPsec. > All this is normal behaviour in any case. > > Some packets -- such as HoTI and HoT -- are protected by IPsec when > tunneled via the home agent. At the HA, packet interception shall be > followed by IPsec processing, and mobility delivery processing shall > take place after IPsec processing. If IPsec processing does not add > anything (like for example a data packet from CN to MN), the BC lookup > will result in the addition of a tunnel (src = HA, dest = CoA, no > routing header) to the data packet. if IPsec processing adds > something (like a tunnel for HoT message), BC lookup will result in > the addition of a routing header. > > => no, it is deeply stupid to add a degenerated tunnel stuff to > an already encapsulated packet: just use the correct addresses! Let me first check if you are objecting 1) The order, ipsec-first-then-tunnel? 2) The addition of a tunnel in the ipsec-does-not-add-anything case above? I suppose not, this is normal MIPv6 tunneling from the HA. 3) The addition of RH to the IPsec-tunneled packet? I'm assuming you must talk about #3. This is a design choice. We could either use HoA or CoA as the destination of the tunnel. If we use the HoA (as we have suggested), the IPsec SPD and SAD entries are static and do not have to be modified when the MN moves. This eliminates the need for coordination between the MIPv6 and IPsec code parts. The disadvantage is an additional RH in the packet (24 bytes?). I suppose it would also be possible to use the CoA as the destination of the tunnel, but then we need the API. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 01:14:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01582 for ; Mon, 15 Jul 2002 01:14:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27027; Sun, 14 Jul 2002 23:14:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16191; Sun, 14 Jul 2002 22:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F5DWoN018677 for ; Sun, 14 Jul 2002 22:13:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F5DWao018676 for mobile-ip-dist; Sun, 14 Jul 2002 22:13:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F5DToN018669 for ; Sun, 14 Jul 2002 22:13:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02882 for ; Sun, 14 Jul 2002 22:13:30 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25350 for ; Sun, 14 Jul 2002 22:13:29 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6F5DQC23149; Mon, 15 Jul 2002 07:13:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id HAA00282; Mon, 15 Jul 2002 07:13:26 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6F5DPGF060671; Mon, 15 Jul 2002 07:13:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207150513.g6F5DPGF060671@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-reply-to: Your message of Mon, 15 Jul 2002 07:33:27 +0300. <3D325097.5000406@kolumbus.fi> Date: Mon, 15 Jul 2002 07:13:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => a hard question to begin: is the MN <-> HA tunnel an interface? > 3. Packet Formats > > The HoTI messages tunneled to the HA look like this: > > IPv6 hdr (CoA, HA) > Dst Opt > HAO > > => why a HAO here? This is a *tunnel*! > > ESP hdr > IPv6 hdr (HoA, CN) > Mobility Hdr > HoTI > > The HoT messages tunneled from the HA look like this: > > IPv6 hdr (HA, CoA) > Routing hdr > HoA > > => same concern. The question is: do we first encapsulate in an IPv6 tunnel due to normal MIPv6 tunneling principles and then apply IPsec, or do we first apply IPsec and only then check if MIPv6 tunneling is necessary? => this question is not sound because you specified a tunnel mode, so the tunnel is both a MIPv6 and IPsec one (i.e., the worms are going out of the can :-). If we do the former, I'm not sure how we can make the SPD entries specific enough so that they would match only the MH messages, but leave rest of traffic in the clear. Can IPsec SPD entries see through the tunnel header? => yes because they use traffic selectors in a tunnel mode... Of course a transport mode over a tunnel should be different. > For outbound packets, IPsec processing shall take place before > mobility processing (routing headers, HAO, tunnel headers). For > inbound packets, mobility processing shall take place before IPsec. > All this is normal behaviour in any case. > > Some packets -- such as HoTI and HoT -- are protected by IPsec when > tunneled via the home agent. At the HA, packet interception shall be > followed by IPsec processing, and mobility delivery processing shall > take place after IPsec processing. If IPsec processing does not add > anything (like for example a data packet from CN to MN), the BC lookup > will result in the addition of a tunnel (src = HA, dest = CoA, no > routing header) to the data packet. if IPsec processing adds > something (like a tunnel for HoT message), BC lookup will result in > the addition of a routing header. > > => no, it is deeply stupid to add a degenerated tunnel stuff to > an already encapsulated packet: just use the correct addresses! Let me first check if you are objecting 1) The order, ipsec-first-then-tunnel? 2) The addition of a tunnel in the ipsec-does-not-add-anything case above? I suppose not, this is normal MIPv6 tunneling from the HA. 3) The addition of RH to the IPsec-tunneled packet? I'm assuming you must talk about #3. => #3 because if your IPsec tunnel is correctly set up you should not have to add something. I argue IPsec and Mobile IPv6 should cooperate, I am trying to convince people in the ipsec WG (look at my draft draft-dupont-ipsec-mipv6-01.txt) so I'd like to avoid the same issue from mobileip WG: one encapsulation is enough, or with other words why four addresses are not enough? This is a design choice. => without a discussion? We could either use HoA or CoA as the destination of the tunnel. If we use the HoA (as we have suggested), the IPsec SPD and SAD entries are static and do not have to be modified when the MN moves. => it seems you have not yet understood all the IPsec details: the SPD and SAD entries don't change because the traffic selectors are for the inner addresses... Of course the fact you can characterize a SA with zero to four addresses (I have a reference for the five cases) doesn't really help (:-). This eliminates the need for coordination between the MIPv6 and IPsec code parts. => this coordination is a good target. I strongly object to avoid it (i.e., don't put a MUST for the HOA/RH here). The disadvantage is an additional RH in the packet (24 bytes?). I suppose it would also be possible to use the CoA as the destination of the tunnel, but then we need the API. => you need something or you won't be able to establish the SA pair for the MN-HA BU/BA exchange (don't forget the MN side selector is the HoA and you can't use the HoA until the BU is processed). My suggession is to get the whole stuff: current IKE is being modified (in drafts for IKEv1, directly in IKEv2) for NAT traversal (an ipsec WG charter item) which is intrinsically insecure. With some good arguments we can get a good mobility/multi-homing support (without the security bug). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 03:05:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14146 for ; Mon, 15 Jul 2002 03:05:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27268; Mon, 15 Jul 2002 01:05:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10066; Mon, 15 Jul 2002 00:05:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F74woN019224 for ; Mon, 15 Jul 2002 00:04:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F74vKX019223 for mobile-ip-dist; Mon, 15 Jul 2002 00:04:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F74soN019216 for ; Mon, 15 Jul 2002 00:04:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09889 for ; Mon, 15 Jul 2002 00:04:55 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07452 for ; Mon, 15 Jul 2002 00:04:54 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6F74rrU008634; Mon, 15 Jul 2002 09:04:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS952F1>; Mon, 15 Jul 2002 09:04:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0852@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko '" Cc: "''mobile-ip@sunroof.eng.sun.com' '" Subject: [mobile-ip] The link-local address issue Date: Mon, 15 Jul 2002 09:04:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari asked me to send this to the list so we don't forget. The problem I'm thinking of is related to the link-local address in the MN. Currently IPv6 implementations have one link-local address. If there is a collision on a visited link (rare but possible) then the MN might do what 2462 says (wait for reconfiguration, which is too drastic) or generate a new iid. If it does the latter then it is likely to delete the link-local address. This could be a problem when the MN goes home and attempts to deregister with its link local address. So it might be best to recommend that the MN keeps track of its 'Home link-local address' (new!). Alternatively, the MN can deregister with its global home address? But I didn't think about this last alternative. We can talk about it in the meeting. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 03:54:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15597 for ; Mon, 15 Jul 2002 03:53:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29787; Mon, 15 Jul 2002 01:54:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22313; Mon, 15 Jul 2002 00:54:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F7r1oN019487 for ; Mon, 15 Jul 2002 00:53:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F7r0x7019486 for mobile-ip-dist; Mon, 15 Jul 2002 00:53:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F7qvoN019479 for ; Mon, 15 Jul 2002 00:52:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24954 for ; Mon, 15 Jul 2002 00:52:58 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09521 for ; Mon, 15 Jul 2002 01:52:58 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6F7qlC30787; Mon, 15 Jul 2002 09:52:47 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA01496; Mon, 15 Jul 2002 09:52:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6F7qkGF061058; Mon, 15 Jul 2002 09:52:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207150752.g6F7qkGF061058@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (EAB)" cc: "'Jari Arkko '" , "''mobile-ip@sunroof.eng.sun.com' '" Subject: Re: [mobile-ip] The link-local address issue In-reply-to: Your message of Mon, 15 Jul 2002 09:04:50 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0852@Esealnt861.al.sw.ericsson.se> Date: Mon, 15 Jul 2002 09:52:46 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The problem I'm thinking of is related to the link-local address in the MN. Currently IPv6 implementations have one link-local address. If there is a collision on a visited link (rare but possible) then the MN might do what 2462 says (wait for reconfiguration, which is too drastic) or generate a new iid. If it does the latter then it is likely to delete the link-local address. This could be a problem when the MN goes home and attempts to deregister with its link local address. => we have to wait for the DAD/DIIDD resolution but in some cases IMHO it can be a good idea to use a RFC 3041 address: - no interference with the HA "address protection" - the collision case is handled in a reasonable way - privacy is better (i.e., get a new RFC 3041 when the link changes) Of course, it works better if the layer 2 says the link can have changed... So it might be best to recommend that the MN keeps track of its 'Home link-local address' (new!). => urgh! Alternatively, the MN can deregister with its global home address? => it can if there is no strange game with the neighbor discovery. But I didn't think about this last alternative. We can talk about it in the meeting. => I believe we should wait for the IPv6 WG in order to do the work only once (to go back to my first statement). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 04:28:11 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17032 for ; Mon, 15 Jul 2002 04:28:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19474; Mon, 15 Jul 2002 01:26:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03037; Mon, 15 Jul 2002 01:26:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F8ProN019761 for ; Mon, 15 Jul 2002 01:25:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F8PqJa019760 for mobile-ip-dist; Mon, 15 Jul 2002 01:25:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F8PnoN019753 for ; Mon, 15 Jul 2002 01:25:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00049 for ; Mon, 15 Jul 2002 01:25:51 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13755 for ; Mon, 15 Jul 2002 02:25:50 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6F8PlRb004615; Mon, 15 Jul 2002 10:25:47 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS96DF9>; Mon, 15 Jul 2002 10:25:47 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0853@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Francis Dupont '" , "Hesham Soliman (EAB)" Cc: "''Jari Arkko ' '" , "'''mobile-ip@sunroof.eng.sun.com' ' '" Subject: RE: [mobile-ip] The link-local address issue Date: Mon, 15 Jul 2002 10:25:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis wrote: => I believe we should wait for the IPv6 WG in order to do the work only once (to go back to my first statement). Regards Francis.Dupont@enst-bretagne.fr => Well then let's get it on the IPv6 agenda ASAP. Personally I think the quick and dirty way would be to do it in MIP (and I don't mind that too much :) ) but a cleaner way might be to get a claer statement from IPv6. Having said that, I thought they already gave a unanymoous statement saying that it _is_ DAD not DIID, no ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 07:07:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24160 for ; Mon, 15 Jul 2002 07:07:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02105; Mon, 15 Jul 2002 04:06:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02465; Mon, 15 Jul 2002 04:06:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FB5boN020109 for ; Mon, 15 Jul 2002 04:05:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FB5b53020108 for mobile-ip-dist; Mon, 15 Jul 2002 04:05:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FB5YoN020101 for ; Mon, 15 Jul 2002 04:05:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27321 for ; Mon, 15 Jul 2002 04:05:34 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01715 for ; Mon, 15 Jul 2002 04:05:33 -0700 (PDT) Received: from kmilesw2k (ams-clip-vpn-dhcp84.cisco.com [10.50.0.83]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA19155; Mon, 15 Jul 2002 12:05:29 +0100 (BST) From: "Kevin Miles" To: "'Jari Arkko'" Cc: Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Mon, 15 Jul 2002 12:05:26 +0100 Message-ID: <013a01c22bef$86d920f0$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3D2F5481.20301@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Works for me too. Let's prohibit it. Also, we need to worry > about the case where the prefixes change between S=0 reg & dereg. > So, my proposal is to define an S=0 dereg as a deregistration of > those addresses that were registered in the original S=0 reg. If no > such original S=0 reg was done, the HA will return a new BA > error code. > > Finally, in a S=0 rereg we could implicitly dereg all address whose > prefixes have disappeared between the reg & dereg. This appears > unnecessary, though, as the HA would not allow the lifetime to exceed > the prefix lifetimes. But this should be noted in the draft to make it > clear. > While you're there, you might also want to note the intended DAD behaviour upon receipt of a S=0 rereg when new prefixes have appeared. Presumably, you DAD and defend the new addresses when the rereg BU arrives, and not before. That is, you do not do it immediately the applicable prefixes come into operation. Or do you? Kevin. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 07:59:29 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26944 for ; Mon, 15 Jul 2002 07:59:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19468; Mon, 15 Jul 2002 05:59:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06180; Mon, 15 Jul 2002 04:59:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FBwloN020348 for ; Mon, 15 Jul 2002 04:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FBwlOA020347 for mobile-ip-dist; Mon, 15 Jul 2002 04:58:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FBwioN020340 for ; Mon, 15 Jul 2002 04:58:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01491 for ; Mon, 15 Jul 2002 04:58:45 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09642 for ; Mon, 15 Jul 2002 05:58:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6FBwgC21133 for ; Mon, 15 Jul 2002 13:58:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA03958 for ; Mon, 15 Jul 2002 13:58:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6FBwfGF061645 for ; Mon, 15 Jul 2002 13:58:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207151158.g6FBwfGF061645@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] R (router) bit in BUs Date: Mon, 15 Jul 2002 13:58:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Please put again the R bit in BUs, R is set to one if the MN is a router, R is set to zero if it is a host *and* this bit is copied into Neighbor Advertisements (in the R bit :-) sent by the Home Agent on the behalf of the MN. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 08:34:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01079 for ; Mon, 15 Jul 2002 08:34:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28403; Mon, 15 Jul 2002 06:34:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20723; Mon, 15 Jul 2002 05:34:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCY1oN020552 for ; Mon, 15 Jul 2002 05:34:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FCY0O4020551 for mobile-ip-dist; Mon, 15 Jul 2002 05:34:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCXvoN020544 for ; Mon, 15 Jul 2002 05:33:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20545 for ; Mon, 15 Jul 2002 05:33:59 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28044 for ; Mon, 15 Jul 2002 06:33:58 -0600 (MDT) From: Masataka Ohta Message-Id: <200207151221.VAA28646@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA28646; Mon, 15 Jul 2002 21:21:27 +0900 Subject: [mobile-ip] 802.11b access in Tokyo and Kyoto with IP mobility (fwd) To: mobile-ip@sunroof.eng.sun.com Date: Mon, 15 Jul 2 21:21:26 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: As not so many people in mobile-IP WG are, seemingly, reading the IETF list, here is a copy of my posting to the list to offer 802.11b access in Tokyo and Kyoto with IP mobility Masataka Ohta -- Forwarded message: > From listadm@loki.ietf.org Fri Jul 12 18:03:02 2002 > X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f > From: Masataka Ohta > Message-Id: <200207120830.RAA09795@necom830.hpcl.titech.ac.jp> > Subject: 802.11b access in Tokyo and Kyoto with IP mobility > To: ietf@ietf.org > Date: Fri, 12 Jul 2002 17:30:08 +0859 () > X-Mailer: ELM [version 2.4ME+ PL68 (25)] > Sender: owner-ietf@ietf.org > Precedence: bulk > X-Loop: ietf@ietf.org > > Dear IETF participants; > > MIS (Mobile Internet Services, Inc., http://www.miserv.net (in English, > http://www.miserv.net/miserv-new/english_new/) and Miako Net Project > (http://www.miako.net) are pleased to announce to jointly offer IETF > participants free Mobile IPv4 access with 802.11b wireless LAN in > Tokyo with more than 200 base stations and Kyoto with more than 100 > base stations (sorry, none in Yokohama). > > A clickable map for the service areas in Tokyo is located at: > > http://www.miserv.net/miserv-new/renew/service/serv03area.html > > A map for the service areas in Kyoto is located at: > > http://www.sccj.com/miako/area.files/miako_map_v5.01.png > > With mobile IP, you can move from one access point to another without > losing the connection, of course. > > I will deliver those of you who are interested in our service account > information valid in July, 2002. > > However, MIS considers it essential social responsibility of wireless > ISPs to cryptographically secure communication between our access points > and terminals of identified users. > > So, MIS users are required to > > 1) download and install software for cryptographically secure > communication with packet-wise MD5/AES protection > > 2) identify yourself to MIS/Miako > > For the identification, contact me or some other person of MIS or Miako > Project personally with proper identification (e.g. IETF badge). On > Sunday, I'll be in a terminal room between 16:00 and 17:00 and reception > between 17:00~18:00. Or, I can mail the account information by e-mail > to authorized mail addresses, if you can fill the attached application > form. > > The authorized mail addresses are mail addresses identity of which is > reliably recognized. All the mail addresses appears in some RFC or > unexpired Internet Draft are considered authorized. You can suggest me > other ways to authorize mail addresses (no, I'm not using PGP). > > We are happy to issue multiple account for a single application, if > the applicant is responsible for the use of all the account. > > Driver software for UNIX (NetBSD 1.5.2 (not tested), NetBSD 1.5ZA20020115, > FreeBSD 4.4R (not tested a lot)) can be found at: > > ftp://chacha.hpcl.titech.ac.jp/misclient-20020705.tar.gz > > Driver software for Windows 2000/XP can be found at: > > http://www.miserv.net/miserv-new/english_new/driver/driver.html > > or > > ftp://chacha.hpcl.titech.ac.jp/Genuine208_2KXP_E.exe > > The driver should work with most PCMCIA WLAN cards (but not with WLAN > interface internal to PCs). A official list of cards, applicability > of which is verified, is available at: > > http://www.miserv.net/miserv-new/renew/service/setup/setup1.html > > Enjoy. > > Masataka Ohta > > -- > Application Form for MIS/Miako Account > (mailto:mohta@necom830.hpcl.titech.ac.jp) > > Name: > > Home (not IP but Postal) Address: > > Country: > > Email (optional): > > Number of Accounts You can be Responsible for (default: 1): > > Authorized Mail Address: > > Name and page # of an RFC or an Internet Draft where the Authorized Mail > Address can be found: > > Comments or Special Requirements: > > -- > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 08:39:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01529 for ; Mon, 15 Jul 2002 08:39:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29530; Mon, 15 Jul 2002 06:38:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21605; Mon, 15 Jul 2002 05:38:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCc6oN020659 for ; Mon, 15 Jul 2002 05:38:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FCc6li020658 for mobile-ip-dist; Mon, 15 Jul 2002 05:38:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCc3oN020649 for ; Mon, 15 Jul 2002 05:38:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08101 for ; Mon, 15 Jul 2002 05:38:04 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29226 for ; Mon, 15 Jul 2002 06:38:03 -0600 (MDT) From: Masataka Ohta Message-Id: <200207151227.VAA28722@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA28722; Mon, 15 Jul 2002 21:26:56 +0859 Subject: [mobile-ip] A post in the IETF list on 3G and the Internet To: mobile-ip@sunroof.eng.sun.com Date: Mon, 15 Jul 2 21:26:55 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is from the IETF list on reality of 3G: > Subject: Re: 802.11b access in Tokyo and Kyoto with IP mobility > For the record, I'm sitting at this instant in Tokyo Station, and am on my > way from Narita to Yokohama. I am sitting in the green car, and I accessed > the appropriate web page. > > I have wonderful 802.11 connectivity, and I have an IP address. Whether > that means I can use the Internet is another question. On the parts of the > track where the connectivity is there, we see ping round trip delays > varying from 380 ms to over four seconds. There are fairly large parts of > the track where the NTT DoCoMo 3G data connectivity appears to simply not > be there - especially when in concrete tubes and ditches, but also on > places with open track. > > So I think here the term "seamless", when applied to connectivity, doesn't > really apply. If you are interested, you can check list archive: http://www.ietf.org/mail-archive/ietf/Current/index.html for further posting. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 09:41:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04101 for ; Mon, 15 Jul 2002 09:41:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05543; Mon, 15 Jul 2002 07:41:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23830; Mon, 15 Jul 2002 06:41:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FDeloN020920 for ; Mon, 15 Jul 2002 06:40:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FDel4c020919 for mobile-ip-dist; Mon, 15 Jul 2002 06:40:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FDehoN020912 for ; Mon, 15 Jul 2002 06:40:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17210 for ; Mon, 15 Jul 2002 06:40:43 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26573 for ; Mon, 15 Jul 2002 07:40:42 -0600 (MDT) Received: from kmilesw2k (ams-clip-vpn-dhcp84.cisco.com [10.50.0.83]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA22992 for ; Mon, 15 Jul 2002 14:40:35 +0100 (BST) From: "Kevin Miles" To: Subject: RE: [mobile-ip] R (router) bit in BUs Date: Mon, 15 Jul 2002 14:40:32 +0100 Message-ID: <013f01c22c05$315a1100$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200207151158.g6FBwfGF061645@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > Please put again the R bit in BUs, R is set to one if the MN > is a router, > R is set to zero if it is a host *and* this bit is copied > into Neighbor > Advertisements (in the R bit :-) sent by the Home Agent on the behalf > of the MN. > Seconded. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 10:12:03 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05089 for ; Mon, 15 Jul 2002 10:12:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20394; Mon, 15 Jul 2002 07:10:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13907; Mon, 15 Jul 2002 07:10:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FE9RoN021079 for ; Mon, 15 Jul 2002 07:09:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FE9RQ1021078 for mobile-ip-dist; Mon, 15 Jul 2002 07:09:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FE9OoN021071 for ; Mon, 15 Jul 2002 07:09:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13654 for ; Mon, 15 Jul 2002 07:09:24 -0700 (PDT) Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11921 for ; Mon, 15 Jul 2002 08:09:23 -0600 (MDT) Received: from kniveton.com (210228129236.cidr.odn.ne.jp [210.228.129.236]) by multihop.net (8.12.4/8.11.1) with ESMTP id g6FE9LAi003319; Mon, 15 Jul 2002 07:09:21 -0700 (PDT) Message-ID: <3D32D78C.ED7AF2CC@kniveton.com> Date: Mon, 15 Jul 2002 07:09:16 -0700 From: "T.J. Kniveton" Organization: Nokia Research Center X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207151158.g6FBwfGF061645@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI, we have specified this in draft-kniveton-mobrtr-02.txt -- we did it there because I don't know what the prospects for putting it back in the base spec would be. -TJ Francis Dupont wrote: > Please put again the R bit in BUs, R is set to one if the MN is a router, > R is set to zero if it is a host *and* this bit is copied into Neighbor > Advertisements (in the R bit :-) sent by the Home Agent on the behalf > of the MN. > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 12:05:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09807 for ; Mon, 15 Jul 2002 12:05:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14483; Mon, 15 Jul 2002 09:58:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18078; Mon, 15 Jul 2002 08:58:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FFv7oN021373 for ; Mon, 15 Jul 2002 08:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FFv7VQ021372 for mobile-ip-dist; Mon, 15 Jul 2002 08:57:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FFv3oN021365 for ; Mon, 15 Jul 2002 08:57:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21523 for ; Mon, 15 Jul 2002 08:57:05 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19509 for ; Mon, 15 Jul 2002 08:57:05 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6FFuphI022815; Mon, 15 Jul 2002 08:56:52 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACD14182; Mon, 15 Jul 2002 08:52:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA24772; Mon, 15 Jul 2002 08:56:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15666.61635.91186.184127@thomasm-u1.cisco.com> Date: Mon, 15 Jul 2002 08:56:51 -0700 (PDT) To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] R (router) bit in BUs In-Reply-To: <200207151158.g6FBwfGF061645@givry.rennes.enst-bretagne.fr> References: <200207151158.g6FBwfGF061645@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > Please put again the R bit in BUs, R is set to one if the MN is a router, > R is set to zero if it is a host *and* this bit is copied into Neighbor > Advertisements (in the R bit :-) sent by the Home Agent on the behalf > of the MN. I'll bite: what does something do with this information? Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 12:44:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11048 for ; Mon, 15 Jul 2002 12:44:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22903; Mon, 15 Jul 2002 10:44:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06239; Mon, 15 Jul 2002 09:44:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FGhAoN021563 for ; Mon, 15 Jul 2002 09:43:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FGh9r9021562 for mobile-ip-dist; Mon, 15 Jul 2002 09:43:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FGh6oN021555; Mon, 15 Jul 2002 09:43:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05838; Mon, 15 Jul 2002 09:43:08 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17039; Mon, 15 Jul 2002 09:43:07 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id BAA18031; Tue, 16 Jul 2002 01:43:06 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id BAA22471; Tue, 16 Jul 2002 01:43:06 +0900 (JST) Date: Tue, 16 Jul 2002 01:41:44 +0900 (JST) Message-Id: <20020716.014144.119249637.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I'm sorry to raise this topic so many times, I still don't understand the reason. The current mip6 (draft-18) says that all IPv6 nodes: - MUST be able to validate a HAO - MUST be able to send a Binding Error message I think I understand the benefit of the above requirements. If an IPv6 node supports the above requirements, a mobile node can communicate with the IPv6 node using a triangular routing if HAO is protected by the IPsec. But, even if there is no such requirement, a mobile node can communicate with all IPv6 nodes in the world using bi-directional tunneling. This requires nothing to all existing and future IPv6 nodes. I may misread/misunderstand something. If so, please correct me. I'm not sure it is important or not to mandate HAO/BE to make a triangular routing possible. But it seems to me that such requirements make it harder to make mip6 become an rfc. I still don't think such new requirements are accepted by the IPv6 WG. Again, I'm sorry I should have sent this comment earlier. I really want to make the mip6 spec RFC as soon as possible. I think fewer requirements is better for fast deploying. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 13:25:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11966 for ; Mon, 15 Jul 2002 13:25:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12588; Mon, 15 Jul 2002 11:15:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19304; Mon, 15 Jul 2002 10:15:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHEIoN021811 for ; Mon, 15 Jul 2002 10:14:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHEINM021810 for mobile-ip-dist; Mon, 15 Jul 2002 10:14:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHEFoN021803 for ; Mon, 15 Jul 2002 10:14:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27671 for ; Mon, 15 Jul 2002 10:14:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11912 for ; Mon, 15 Jul 2002 11:14:14 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA13398; Mon, 15 Jul 2002 10:14:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FHEBA02515; Mon, 15 Jul 2002 10:14:11 -0700 X-mProtect: <200207151714> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4C2iht; Mon, 15 Jul 2002 10:14:09 PDT Message-ID: <3D3302E2.D1AEBE34@iprg.nokia.com> Date: Mon, 15 Jul 2002 10:14:10 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Jari Arkko , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> <3D2F7BD1.BCC68477@iprg.nokia.com> <00ed01c22a6d$66a47150$ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > Why not have it be an option? There will likely be other algorithms that will be used for protecting BUs and they may need > other stuff. It is an option currently. Jari, lets leave it like that instead of making it a fixed field. Jari Arkko wrote: > > But this discussion leads me to think about a possible solution: what if we > required the alt coa option to be present in all BUs that are not protected > by RR? In the current spec this would imply having them in all HA BUs. This > would keep the current formats, avoid the security problem, and avoid the > need for the MIPv6 module to know what kind of IPsec is being used to protect > the BUs. if the HA BUs were protected by IPsec AH or some other mechanism, then there is no need for this fixed field. it is *only* needed for ESP protected BUs. infact it would also be needed if a BU to a CN were protected by ESP. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 13:25:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12000 for ; Mon, 15 Jul 2002 13:25:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20151; Mon, 15 Jul 2002 11:25:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01557; Mon, 15 Jul 2002 10:25:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHODoN022059 for ; Mon, 15 Jul 2002 10:24:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHOCdV022056 for mobile-ip-dist; Mon, 15 Jul 2002 10:24:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHO8oN022043 for ; Mon, 15 Jul 2002 10:24:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01017 for ; Mon, 15 Jul 2002 10:24:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09283 for ; Mon, 15 Jul 2002 11:24:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14311; Mon, 15 Jul 2002 10:24:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FHO5X26355; Mon, 15 Jul 2002 10:24:05 -0700 X-mProtect: <200207151724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6VDcNb; Mon, 15 Jul 2002 10:24:03 PDT Message-ID: <3D330533.112985F2@iprg.nokia.com> Date: Mon, 15 Jul 2002 10:24:03 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Singh Ajoy-ASINGH1 , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <3D2F4461.F1F8E22B@iprg.nokia.com> <008001c22a6a$15a26760$056015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > Would your opinion change if these triggers were described in the abstract within the document? Similar to what Charlie and I > discussed the other day? Thus, there would be no normative references outside the document. yes, ofcourse! in any way that doesnt tie FMIPv6 draft to L2 triggers draft. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 14:18:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13143 for ; Mon, 15 Jul 2002 14:18:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05594; Mon, 15 Jul 2002 12:13:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19919; Mon, 15 Jul 2002 11:12:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FIBuoN022554 for ; Mon, 15 Jul 2002 11:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FIBuCs022553 for mobile-ip-dist; Mon, 15 Jul 2002 11:11:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FIBroN022546 for ; Mon, 15 Jul 2002 11:11:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07931 for ; Mon, 15 Jul 2002 11:11:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11750 for ; Mon, 15 Jul 2002 11:11:54 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA17807; Mon, 15 Jul 2002 11:11:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FIBn605922; Mon, 15 Jul 2002 11:11:49 -0700 X-mProtect: <200207151811> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCYBsW5; Mon, 15 Jul 2002 11:11:47 PDT Message-ID: <3D331064.7BF8B9B5@iprg.nokia.com> Date: Mon, 15 Jul 2002 11:11:48 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile Cookies Length Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jari, I was trying to figure out why the length of the Mobile Cookies (HoT and CoT cookie) have been increased from 32 bits to 64 bits. the only justication I have found till now is that "it is good to have the same length of all cookies". I disagree. HoT and CoT are just for preventing spoofed HoT and CoT messages. 32 bits are more than enough. OTOH, I do agree that Home Cookie and Care-of Cookie have to be 64 bits aleast (they are used for BU authentication). I think we should reduce the mobile cookies to 32 bits (as was in draft 17). it saves 32 bits each for four messages (HoTi, CoTi, HoT and CoT). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 14:47:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13977 for ; Mon, 15 Jul 2002 14:47:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08920; Mon, 15 Jul 2002 12:45:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21551; Mon, 15 Jul 2002 11:45:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FIhgoN022750 for ; Mon, 15 Jul 2002 11:43:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FIhgPs022749 for mobile-ip-dist; Mon, 15 Jul 2002 11:43:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FIhdoN022742 for ; Mon, 15 Jul 2002 11:43:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02426 for ; Mon, 15 Jul 2002 11:43:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22864 for ; Mon, 15 Jul 2002 12:43:39 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA19773 for ; Mon, 15 Jul 2002 11:43:39 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FIhbK18918 for ; Mon, 15 Jul 2002 11:43:37 -0700 X-mProtect: <200207151843> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1Y708i; Mon, 15 Jul 2002 11:43:34 PDT Message-ID: <3D3317D6.58ADBEE0@iprg.nokia.com> Date: Mon, 15 Jul 2002 11:43:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] minor comments on draft 18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1) Section 6.1.2 > When a mobile node receives a > packet containing a Binding Refresh Request message and there > already exists a Binding Update List entry for the source of the > Binding Refresh Request, it MAY start a return routability procedure > (see Section 5.2) if it believes the amount of traffic with the > correspondent justifies the use of route optimization. remove 'if it believes the amount of traffic with the correspondent justifies the use of route optimization'. it is already a MAY. it is very often difficult to figure out (from the kernel) the amount of traffic than an application might generated. anyway, the previous line says 'it MAY start a return routability procedue'. I dont think we have to supply the reason not to do it. 2) Section 6.1.6 > > Reserved > > The two 16-bit fields are reserved for future use. These > values MUST be initialized to zero by the sender, and MUST be > ignored by the receiver. remove this. there is no reserved field in the CoT message. 3) Section 6.1.8 > 135 Sequence number out of window invalid sequence number(?) > 136 Route optimization unnecessary due to low traffic I didnt find this used anywhere. do we need this? 4) Section 10.2 > - The Refresh field MUST be set to a value less than or equal to > the Lifetime value being returned in the Binding Update. If the > home agent stores the Binding Cache entry in nonvolatile storage > (that survives the crash or other failure of the home agent), > then the Refresh field SHOULD be set to the same value as the > Lifetime field; otherwise, the home agent MAY set the Refresh > field to a value less than the Lifetime field, to indicate that > the mobile node SHOULD attempt to refresh its home registration > at the indicated shorter interval (although the home agent will > still retain the registration for the Lifetime period, even if > the mobile node does not refresh its registration within the > Refresh period). The refresh field is no longer there in the BU/BA. you should probably describe the Binding Refresh Advice option here. 5) Section 10.9.1 > To avoid possible security attacks from forged Mobile Prefix > Advertisements all such Advertisements MUST be authenticated to the > mobile node by its home agent using IPsec [4, 5, 6]. is 'MUST' the right keyword? because in another place > If a Security Association for the IP Authentication Header > exists between the sender and the destination address, then the > sender SHOULD include this header. [subject to change] Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 16:12:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15803 for ; Mon, 15 Jul 2002 16:12:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28982; Mon, 15 Jul 2002 14:12:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23326; Mon, 15 Jul 2002 13:12:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FKB9oN023023 for ; Mon, 15 Jul 2002 13:11:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FKB9r8023022 for mobile-ip-dist; Mon, 15 Jul 2002 13:11:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FKB6oN023015 for ; Mon, 15 Jul 2002 13:11:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22815 for ; Mon, 15 Jul 2002 13:11:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09405 for ; Mon, 15 Jul 2002 14:11:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26286; Mon, 15 Jul 2002 13:11:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FKB3s24518; Mon, 15 Jul 2002 13:11:03 -0700 X-mProtect: <200207152011> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSZAKtd; Mon, 15 Jul 2002 13:10:59 PDT Message-ID: <3D332C54.C39DE161@iprg.nokia.com> Date: Mon, 15 Jul 2002 13:11:00 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Francis Dupont '" , "''Jari Arkko ' '" , "'''mobile-ip@sunroof.eng.sun.com' ' '" Subject: Re: [mobile-ip] The link-local address issue References: <4DA6EA82906FD511BE2F00508BCF0538044F0853@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (EAB)" wrote: > > Francis wrote: > > => I believe we should wait for the IPv6 WG in order to do the work > only once (to go back to my first statement). > > Regards > > Francis.Dupont@enst-bretagne.fr > > => Well then let's get it on the IPv6 agenda > ASAP. Personally I think the quick and dirty way > would be to do it in MIP (and I don't mind that > too much :) ) but a cleaner way might be to get > a claer statement from IPv6. Having said that, > I thought they already gave a unanymoous statement > saying that it _is_ DAD not DIID, no ? DAD vs DIID discussin is on the IPv6 agenda. hopefully we get a clear statement from that discussion. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 16:58:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16513 for ; Mon, 15 Jul 2002 16:58:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25548; Mon, 15 Jul 2002 14:58:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10182; Mon, 15 Jul 2002 13:58:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FKv1oN023227 for ; Mon, 15 Jul 2002 13:57:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FKv1H7023225 for mobile-ip-dist; Mon, 15 Jul 2002 13:57:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FKuvoN023218 for ; Mon, 15 Jul 2002 13:56:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23144 for ; Mon, 15 Jul 2002 13:56:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19863 for ; Mon, 15 Jul 2002 14:56:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA29176; Mon, 15 Jul 2002 13:56:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FKuuQ00610; Mon, 15 Jul 2002 13:56:56 -0700 X-mProtect: <200207152056> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWhkppO; Mon, 15 Jul 2002 13:56:21 PDT Message-ID: <3D3336F5.B7DA85B6@iprg.nokia.com> Date: Mon, 15 Jul 2002 13:56:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Issue 51: cookie lengths References: <3D1CB576.400@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Taking > in account alignment / padding requirements, if we have more than 16 > bits we might as well make them 64 bits without wasting any more > bandwidth. alignment requirements are best solved by padding. tomorrow, if somebody defines a new option for HoTi/CoTi/HoT/CoT messages, those options would fill up this space. you shouldnt make this cookies longer (saying you have to pad anyway today). Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 18:07:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17770 for ; Mon, 15 Jul 2002 18:07:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04898; Mon, 15 Jul 2002 16:07:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29863; Mon, 15 Jul 2002 15:07:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FM6FoN023531 for ; Mon, 15 Jul 2002 15:06:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FM6FNE023530 for mobile-ip-dist; Mon, 15 Jul 2002 15:06:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FM67oN023523 for ; Mon, 15 Jul 2002 15:06:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04974 for ; Mon, 15 Jul 2002 15:06:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04428 for ; Mon, 15 Jul 2002 16:06:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04015; Mon, 15 Jul 2002 15:06:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6FM66010324; Mon, 15 Jul 2002 15:06:06 -0700 X-mProtect: <200207152206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFHZmQA; Mon, 15 Jul 2002 15:06:04 PDT Message-ID: <3D33474C.490D4D06@iprg.nokia.com> Date: Mon, 15 Jul 2002 15:06:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection References: <200207150513.g6F5DPGF060671@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Francis, Francis Dupont wrote: > => a hard question to begin: is the MN <-> HA tunnel an interface? the tunnel end point changes every time the MN moves. > => yes because they use traffic selectors in a tunnel mode... > Of course a transport mode over a tunnel should be different. lets assume the MN receives the following packet. it is a tunneled HoT message. IPv6 hdr (HA, CoA) ESP hdr IPv6 hdr (CN, HoA) Mobility hdr HoT to pick the right SA, the MN needs destination address, SPI and IPsec protocol. it is missing the destination address. the only way out seemed to be to add the routing header. > => #3 because if your IPsec tunnel is correctly set up you should not > have to add something. I argue IPsec and Mobile IPv6 should cooperate, > I am trying to convince people in the ipsec WG (look at my draft > draft-dupont-ipsec-mipv6-01.txt) so I'd like to avoid the same issue > from mobileip WG: one encapsulation is enough, or with other words > why four addresses are not enough? this draft is good. I am not on the IPsec mailing list. has this been discussed there? is it being adopted? is there anything Mobile IP WG can do to help? > => this coordination is a good target. I strongly object to avoid > it (i.e., don't put a MUST for the HOA/RH here). the MUST can definitely be avoided. but for IPsec and MIPv6 to work together as they are currently defined, I think we need HAO and RH. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 18:12:11 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17868 for ; Mon, 15 Jul 2002 18:12:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24033; Mon, 15 Jul 2002 15:10:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06715; Mon, 15 Jul 2002 15:10:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FM9loN023668 for ; Mon, 15 Jul 2002 15:09:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FM9lUY023667 for mobile-ip-dist; Mon, 15 Jul 2002 15:09:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FM9hoN023660 for ; Mon, 15 Jul 2002 15:09:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00952 for ; Mon, 15 Jul 2002 15:09:44 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06031 for ; Mon, 15 Jul 2002 16:09:43 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id DD79D3D8B for ; Mon, 15 Jul 2002 17:09:41 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 347925EE for ; Mon, 15 Jul 2002 15:09:41 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id SAA0001268961; Mon, 15 Jul 2002 18:09:40 -0400 (EDT) Message-ID: <3D334824.906BE97C@hp.com> Date: Mon, 15 Jul 2002 18:09:40 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: [mobile-ip] draft 18 comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I have a few comments on the sections of draft 18 I've read so far, as well as some typos. -Brian 4.5. Conceptual Data Structures "... The contents of all of a node's Binding Cache entries are cleared when it reboots. ..." This isn't necessarily the case if we use nonvolatile storage as Section 10.2 suggests. 6.1.1. Format The Mobility Header is identified by a Next Header value of TBD in the immediately preceding header, and has the following format: Can we assign an interim "Next Header" value so we'll be able to test interoperability at ETSI, even if we don't put it in the draft right now? IANA has 55 for "IP Mobility", but I didn't think Mipv4 used a protocol number? 6.1.8. Binding Acknowledgement (BA) Message The Binding Acknowledgement is sent to the source address of the Binding Update message, regardless of whether the Binding Update succeeded or failed. No Routing Headers are added to the message. Section 9.4.4 describes when and how to send a BAck to a MN, this paragraph should probably be removed. 6.1.9. Binding Error (BE) Message What should the Home Address field be set to if the error status is 2, the unspecified address? Maybe section 9.4.6 should clarify this, instead of putting it in both 9.2.1 and 9.2.2. Section 9.2.1 applies to all Mipv6 nodes, not just CNs, so it should probably be moved elsewhere. It also doesn't say what to do if the checksum is invalid, I'm assuming you drop the packet. There was also a typo (Next Header -> Payload Proto) and some duplicated text (Subsequent checks...). Here's a possible rewrite: 9.2.1. Processing Mobility Header (MH) Messages All IPv6 nodes MUST observe the following rules when processing Mobility Header messages: 1. The "MH type" field MUST be a known type (Section 6.1), else the node SHOULD issue a Binding Error message to the packet's Source Address with Status field set to 2, subject to rate limiting in the same manner as is done for ICMPv6 messages [14]. 2. The "Payload Proto" field MUST be NO_NXTHDR (59 decimal). 3. The checksum MUST be verified as per Section 6.1.1. Any Mobility Header packet which fails to satisfy all of these rules MUST be silently discarded. Subsequent checks depend on the particular Mobility Header message, as specified in Sections 9.3 and 9.4. (I also shortened this last paragraph since it seemed redundant) And maybe the rate limiting piece I added should be in the Binding Error section since there is more than one place that talks about sending BEs. And what do we do if the length isn't even enough to cover the type or checksum fields? 4. The "Header Len" field MUST meet the minimum length requirements of a Mobility Header (which unfortunately doesn't end on an 8-octet boundary), which is one (1)? I.E. if "Header Len" is zero what do we do, ICMP message? 9.3.1. Receiving Home Test Init Messages - The Header Extension Length field MUST be greater than or equal to the length specified in Section 6.1.3. should be: - The MH "Header Len" field MUST be greater than or equal to the length specified in Section 6.1.3. Section 9.3.2 needs a similar change. 9.4.1. Receiving Binding Updates - The Header Len field in the Binding Update option is greater than or equal to the length specified in Section 6.1.7. There is no "Header Len" field in the BU any more, it's in the MH: - The MH "Header Len" field MUST be greater than or equal to the length specified in Section 6.1.7. Typos: 6.1.2, "Binding Requests sent" -> "Binding Refresh Requests sent" 7.1, H-bit section - "Mobile IP home agent" -> "Mobile IPv6 home agent" 9.2.2, 3rd para, 1st sentence - "nodes" -> "node" 11.2.1 - "Mobile IP" -> "Mobile IPv6", 4 times 11.2.2 - "Mobile IP" -> "Mobile IPv6", 2 times From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 21:12:37 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22460 for ; Mon, 15 Jul 2002 21:12:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11317; Mon, 15 Jul 2002 18:11:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05229; Mon, 15 Jul 2002 18:11:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1A8oN024215 for ; Mon, 15 Jul 2002 18:10:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G1A8Jr024214 for mobile-ip-dist; Mon, 15 Jul 2002 18:10:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1A5oN024207 for ; Mon, 15 Jul 2002 18:10:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02318 for ; Mon, 15 Jul 2002 18:10:06 -0700 (PDT) Received: from pan.ch.intel.com (chfdns01.ch.intel.com [143.182.246.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26134 for ; Mon, 15 Jul 2002 19:10:05 -0600 (MDT) Received: from azsmsxvs043.ch.intel.com (azsmsxvs043.ch.intel.com [10.2.248.13]) by pan.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6G1A5j05904 for ; Tue, 16 Jul 2002 01:10:05 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by azsmsxvs043.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071518100526434 for ; Mon, 15 Jul 2002 18:10:05 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Jul 2002 18:10:05 -0700 Message-ID: <0DCC27458EB5D51181840002A507069E04C31ECC@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Minutes from Bar BoF on mobile IPv4 VPN traveral Date: Mon, 15 Jul 2002 18:10:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Meeting Logistics: The group met on 7/15/02 at the IETF-54 meeting location in Yokohama. Attendees: Hiroyuki Ohnishi Joe Lau Alan O'neill Atsushi Inouye Henrik Levkowetz Sami Varaala Antti Nueppoen Gopal Dommety Kent Leung Milind Kulkarni Gaetan Feige Uri Blumenthal Farid Adrangi Prakash Iyer We started off with Farid reviewing current status: - Requirements draft updated and posted as a working group draft with feedback received to date incorporated Per Phil Roberts' suggestion, the problem statement and solution requirements draft will be combined and an updated draft will be posted soon Discussion: The group agreed that the meta problem being solved is the need to support mobile IP for an MN that roams inside and outside an Enterprise network (protected by a firewall). In the course of discussions, the group identified some scenarios (combinations of HA and VPN gateway deployments) that the problem statement should mention with issues concerning each. The group also suggested that the problem statement identify scenarios that solution(s) will attempt to address. Solution draft(s) will clearly identify the scenarios and problems outlined in the problem statement draft that they are specifically addressing. The scenarios identified are described below: 1. HA outside the DMZ and VPN inside the DMZ * Big problem is - How do you move inside and maintain connectivity * Issue - Untrusted traffic from CN to MN inside the Enterprise is a problem * A possible workaround inside the Enterprise would be to disable reverse tunneling however that could break with ingress filtering. If we use reverse tunneling, all packets (even between nodes in the Enterprise) have to be routed via the external HA 2. HA and VPN gateway connected in parallel in the DMZ * Only difference from previous case is that HA and VPN gateway now belong to the same administrative domain * All traffic (including internal traffic) will hit the DMZ, which may not be acceptable to large Enterprises * CN outside cannot talk to MN inside * Needs a virtual home network 3. HA and VPN gateway combined in 1 box in the DMZ * This results in signaling optimization makes it somewhat simpler but previous problems exist * There may be no need to standardize the signaling between the 2 boxes * Needs a virtual home network A variant of the previous scenario is where HA+VPN is combined in a distributed manner inside the Enterprise - in other words not centralized as described in scenario 3. This may not be acceptable especially for large Enterprises as it requires IPsec traffic termination on these distribution HA+VPN boxes 4. VPN gateway in the DMZ and HA in the Intranet * Main issue here is that the HAs are not visible from the Internet * The issue of maintaining VPN tunnels across IP subnets needs to be addressed. One possible approach is to deploy another layer of mobile IP in the external network that essentially results in a more persistent care-of address. 5. Reverse Tunneling with IPsec The approach addresses the problem of MIP and VPN encapsulation overhead by optimizing the combination of these protocols. This could result in protocol changes to MIP and/or IPsec. Other issues are for further study. Next Steps: -Include the above-mentioned scenarios in an updated problem statement / requirements draft. -Chairs will issue a last call on the problem statement / requirements draft -Form a design team to evaluate solution(s) addressing the draft mentioned above From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 21:17:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22600 for ; Mon, 15 Jul 2002 21:17:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26820; Mon, 15 Jul 2002 19:17:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04001; Mon, 15 Jul 2002 18:17:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1GKoN024357 for ; Mon, 15 Jul 2002 18:16:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G1GKMJ024356 for mobile-ip-dist; Mon, 15 Jul 2002 18:16:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1GFoN024349 for ; Mon, 15 Jul 2002 18:16:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06589 for ; Mon, 15 Jul 2002 18:16:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26294 for ; Mon, 15 Jul 2002 19:16:07 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6G1Fwv18158; Tue, 16 Jul 2002 03:15:58 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id DAA10563; Tue, 16 Jul 2002 03:15:57 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6G1FvGF063795; Tue, 16 Jul 2002 03:15:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207160115.g6G1FvGF063795@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-reply-to: Your message of Mon, 15 Jul 2002 08:56:51 PDT. <15666.61635.91186.184127@thomasm-u1.cisco.com> Date: Tue, 16 Jul 2002 03:15:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Please put again the R bit in BUs, R is set to one if the MN is a router, > R is set to zero if it is a host *and* this bit is copied into Neighbor > Advertisements (in the R bit :-) sent by the Home Agent on behalf > of the MN. I'll bite: what does something do with this information? => we have the choice between either changing MN to MH in the specs or putting the correct value in the R bit of NAs (:-). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 21:42:17 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23264 for ; Mon, 15 Jul 2002 21:42:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07800; Mon, 15 Jul 2002 19:42:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21736; Mon, 15 Jul 2002 18:42:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1f1oN024515 for ; Mon, 15 Jul 2002 18:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G1f1Do024514 for mobile-ip-dist; Mon, 15 Jul 2002 18:41:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1ewoN024506 for ; Mon, 15 Jul 2002 18:40:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10102 for ; Mon, 15 Jul 2002 18:40:58 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14149 for ; Mon, 15 Jul 2002 19:40:53 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6G1efv18879; Tue, 16 Jul 2002 03:40:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id DAA10772; Tue, 16 Jul 2002 03:40:40 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6G1eeGF063857; Tue, 16 Jul 2002 03:40:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207160140.g6G1eeGF063857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-reply-to: Your message of Mon, 15 Jul 2002 15:06:04 PDT. <3D33474C.490D4D06@iprg.nokia.com> Date: Tue, 16 Jul 2002 03:40:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => a hard question to begin: is the MN <-> HA tunnel an interface? the tunnel end point changes every time the MN moves. => is it a tentative answer to the question (:-)? > => yes because they use traffic selectors in a tunnel mode... > Of course a transport mode over a tunnel should be different. lets assume the MN receives the following packet. it is a tunneled HoT message. IPv6 hdr (HA, CoA) ESP hdr IPv6 hdr (CN, HoA) Mobility hdr HoT to pick the right SA, the MN needs destination address, SPI and IPsec protocol. it is missing the destination address. the only way out seemed to be to add the routing header. => no, if the RH is before the ESP hdr this argument doesn't apply. > => #3 because if your IPsec tunnel is correctly set up you should not > have to add something. I argue IPsec and Mobile IPv6 should cooperate, > I am trying to convince people in the ipsec WG (look at my draft > draft-dupont-ipsec-mipv6-01.txt) so I'd like to avoid the same issue > from mobileip WG: one encapsulation is enough, or with other words > why four addresses are not enough? this draft is good. => thanks! I am not on the IPsec mailing list. has this been discussed there? => not yet but I am trying to get a slot in the ipsec WG session Wednesday. is it being adopted? is there anything Mobile IP WG can do to help? => IMHO mobile-ip WG people should ask for a better support for mobility and multi-homing in IPsec, including the Son-Of-Ike. Today there is only a buggy NAT-traversal (because it is in the charter) and a half-baked multi-homing support (from SCTP). > => this coordination is a good target. I strongly object to avoid > it (i.e., don't put a MUST for the HOA/RH here). the MUST can definitely be avoided. but for IPsec and MIPv6 to work together as they are currently defined, I think we need HAO and RH. => I disagree. And as the SAD description in the original message doesn't give the outer addresses I can't see your reasoning. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 21:46:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23506 for ; Mon, 15 Jul 2002 21:46:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06196; Mon, 15 Jul 2002 19:46:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15923; Mon, 15 Jul 2002 18:46:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1jMoN024640 for ; Mon, 15 Jul 2002 18:45:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G1jL1g024639 for mobile-ip-dist; Mon, 15 Jul 2002 18:45:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G1jIoN024632 for ; Mon, 15 Jul 2002 18:45:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15667 for ; Mon, 15 Jul 2002 18:45:19 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08939 for ; Mon, 15 Jul 2002 19:45:19 -0600 (MDT) Message-ID: <00a801c22c6a$36a56640$256015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] BU AltSec BAR BOF Report Date: Mon, 15 Jul 2002 18:39:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit These are some notes on the BAR BOF held last night on alternate BU security mechanisms. There were 18 people in attendance. Currently, there are three alternative mechanisms that are under consideration. The list below is ordered by need for infrastructure (least infrastructure first): - Cryptographically Generated Addresses - Address Based Keys - AAA We also discussed a couple simple optimizations of Return Routability, like substituting for the Home Address Cookie, that would improve the performance but still maintain the basic algorithm. The group agreed that the primary requirement for any new algorithm is that it should improve on the Return Routability performance by cutting down on the number of messages involved in doing Route Optimization. Secondarily, improvement in the very few security areas where Return Routability still has vulnerabilities would also be of interest. An important consideration for any algorithm is that it prevent selective bombing attacks, where a node can launch a DoS attack through a third party. The CoTI/CoT exchange is designed to prevent this. Any algorithm which doesn't prevent selective bombing attacks should be excluded. Bombing attacks on networks were also discussed, since CGA won't prevent them, but they were thought to be of a lesser concern. We talked briefly about how to proceed with standardization work in this area, and all agreed that it should proceed through the MIP group, since the expertiese and interest is there. Starting a mailing list was suggested, but by IETF procedure, any discussion would have to proceed through the MIP list. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 22:02:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24308 for ; Mon, 15 Jul 2002 22:02:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08425; Mon, 15 Jul 2002 20:02:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14965; Mon, 15 Jul 2002 19:02:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G20CoN024835 for ; Mon, 15 Jul 2002 19:00:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G20CDr024834 for mobile-ip-dist; Mon, 15 Jul 2002 19:00:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G208oN024827 for ; Mon, 15 Jul 2002 19:00:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14554 for ; Mon, 15 Jul 2002 19:00:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18047 for ; Mon, 15 Jul 2002 19:00:10 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA18423; Mon, 15 Jul 2002 19:00:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6G208Z20239; Mon, 15 Jul 2002 19:00:08 -0700 X-mProtect: <200207160200> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddInI25; Mon, 15 Jul 2002 19:00:06 PDT Message-ID: <3D337E26.844AB602@iprg.nokia.com> Date: Mon, 15 Jul 2002 19:00:06 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection References: <200207160140.g6G1eeGF063857@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > lets assume the MN receives the following packet. it is a tunneled > HoT message. > > IPv6 hdr (HA, CoA) > ESP hdr > IPv6 hdr (CN, HoA) > Mobility hdr > HoT > > to pick the right SA, the MN needs destination address, SPI and IPsec > protocol. it is missing the destination address. the only way out > seemed to be to add the routing header. > > => no, if the RH is before the ESP hdr this argument doesn't apply. hold it. I am not sure we are talking about the same thing. you mean something like this? IPv6 hdr (HA, CoA) Routing hdr (HoA) ESP hdr IPv6 hdr (CN, HoA) Mobility hdr HoT if yes, this is what is there in the writeup. if no, I dont follow. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 22:15:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24720 for ; Mon, 15 Jul 2002 22:15:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22982; Mon, 15 Jul 2002 19:14:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17248; Mon, 15 Jul 2002 19:14:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G2DAoN024976 for ; Mon, 15 Jul 2002 19:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G2D91g024975 for mobile-ip-dist; Mon, 15 Jul 2002 19:13:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G2D6oN024968 for ; Mon, 15 Jul 2002 19:13:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28541 for ; Mon, 15 Jul 2002 19:13:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22654 for ; Mon, 15 Jul 2002 19:13:07 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6G2D2v19900; Tue, 16 Jul 2002 04:13:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA11016; Tue, 16 Jul 2002 04:13:02 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6G2D1GF063965; Tue, 16 Jul 2002 04:13:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207160213.g6G2D1GF063965@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-reply-to: Your message of Mon, 15 Jul 2002 19:00:06 PDT. <3D337E26.844AB602@iprg.nokia.com> Date: Tue, 16 Jul 2002 04:13:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > lets assume the MN receives the following packet. it is a tunneled > HoT message. > > IPv6 hdr (HA, CoA) > ESP hdr > IPv6 hdr (CN, HoA) > Mobility hdr > HoT > > to pick the right SA, the MN needs destination address, SPI and IPsec > protocol. it is missing the destination address. the only way out > seemed to be to add the routing header. > > => no, if the RH is before the ESP hdr this argument doesn't apply. hold it. I am not sure we are talking about the same thing. you mean something like this? IPv6 hdr (HA, CoA) Routing hdr (HoA) ESP hdr IPv6 hdr (CN, HoA) Mobility hdr HoT => yes, this is in the original message. And as the inbound processing puts the HoA in the source IPsec doesn't see the CoA and is happy. My concern is that if it works there is a more efficient solution. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 15 22:34:45 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25637 for ; Mon, 15 Jul 2002 22:34:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10297; Mon, 15 Jul 2002 19:33:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28138; Mon, 15 Jul 2002 19:33:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G2WNoN025139 for ; Mon, 15 Jul 2002 19:32:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G2WNu8025138 for mobile-ip-dist; Mon, 15 Jul 2002 19:32:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G2WKoN025131 for ; Mon, 15 Jul 2002 19:32:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20614 for ; Mon, 15 Jul 2002 19:32:22 -0700 (PDT) Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18824 for ; Mon, 15 Jul 2002 20:32:21 -0600 (MDT) Received: from kniveton.com ([133.93.73.134]) by multihop.net (8.12.4/8.11.1) with ESMTP id g6G2WOAi004396 for ; Mon, 15 Jul 2002 19:32:24 -0700 (PDT) Message-ID: <3D3385B2.3040300@kniveton.com> Date: Mon, 15 Jul 2002 19:32:18 -0700 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comment on Issue 56 (Optimizations in DHAD) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, Yesterday in the Mobile IP meeting, I made a comment on Issue 56, which I want to re-iterate on the list. The Issue is regarding optimizations of DHAD responses from HAs. There are two optimizations that seem to be in conflict: 1. When the HA is higest priority on the list, it omits its own entry from the list. Hence, if there is no entry with the sending HA's address, there is an implied entry with highest priority. 2. When the reply message exceeds the MTU of the sending interface, the packet is truncated to fit within one packet. The apparent conflict is the following: if #2 happens (the packet is truncated), it is possible that an entry for the sending HA would have been very low priority (or even not in the list, if possible), but is now truncated and doesn't show up in the list, so the MN assumes there's an entry with highest priority. Optimization #1 is a good one, since it is likely that the sending HA will always want itself as the highest priority. So to lose this optimization just to prevent the conflict case (which is unlikely -- it doesn't seem HA lists will be excessively long very often) is a shame. So the compromise I suggested is the following, which will preserve both optimizations: 1. When the sending HA is highest priority in the list, omit it from the list. This is the same as the current proposal. 2. Define the following variables: i = number of entries in home agent list which will fit within MTU of sending interface j = posistion of sending HA in list k = total length of HA list Now, when the whole list will not fit into a single packet (i < k), we can truncate the packet as follows: if the sending HA appears within the MTU (j < i), or the sending HA is highest priority (j=0), simply truncate the list by sending HAs {1..i}. If the sending HA would be truncated off the end of the list (i < j < k), simply send the truncated list, but replace the last entry with the sending HA {1..i-1, j}. In this way, there is no ambiguity: the sending HA will either always appear in the packet (if it's past the truncation point, it is sent as the last entry), or it does not appear and we know that it is highest priority. -TJ From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 02:42:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11394 for ; Tue, 16 Jul 2002 02:42:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03120; Tue, 16 Jul 2002 00:42:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA17375; Mon, 15 Jul 2002 23:42:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G6fJoN025623 for ; Mon, 15 Jul 2002 23:41:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G6fJQc025622 for mobile-ip-dist; Mon, 15 Jul 2002 23:41:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G6fGoN025615 for ; Mon, 15 Jul 2002 23:41:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01652 for ; Mon, 15 Jul 2002 23:41:16 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07774 for ; Tue, 16 Jul 2002 00:41:14 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098HXJY>; Tue, 16 Jul 2002 02:41:12 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4601202EB2@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue 63: Multicast Date: Tue, 16 Jul 2002 02:41:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Firstly..apologies for the long mail... I discussed this briefly with Jari after the wg last night to raise concerns about the stated resolution for this issue in the meeting. Jari suggested I post a little more text to the wg on this issue so that the problem with the stated direction is clearer. The suggested resolution was that the use of the home multicast system via a bi-directional tunnel be included in the spec (fine) but that a MN can optionally use, for the foreign multicast system, its CCoA as a source address (not fine) to originate traffic to a multicast group, and that the detailed mechanisms for this would be detailed in draft-oneill-multicast etc.. The problem with the latter (CCoA based origination into the foreign multicast system) is that a MN multicast originator never knows about the location or number of the receivers on a multicast group, and multicast groups can use different types of tree building mechanisms (multicast protocols) in different operator domains. For global multicast groups there is also an inter-domain tree building protocol which interconnects the trees in different domains. Now some of these tree building protocols, including the current inter-domain protocol (MSDP), build source specific multicast trees where the source address is installed into the multicast routing entry in each router on the source specific branch of the multicast tree. These source trees can specifically be end to end between the MN sender and all group receivers. Note that the other extreme is that the tree can also have no sender specific branches with minimal source specific entries limited to the edge routers only (multicast Designated Routers). The MN nevers knows where its tree is between these two extremes except possibly for groups scoped to the foreign domains only (via policy / profile).. Clearly then, if the MN uses its CCoA as a multicast source address, and that CCoA is evolving rapidly as the MN moves, then all the source specific multicast router entries on all source specific branches for all receivers, need to be updated from the old to the new CCoA at hand-over speed. The clear danger here is huge thrashing of the multicast routing system with big groups and/or large numbers of MNs. Therefore, I don't think it is reasonable to have the base spec enable a MN to use its CCoA as a source address. It is as dangerous and unscalable (possibly more so) as supporting MN movement in the unicast routing system by using host routes rather than MIP edge tunnel redirection. I hope that is clear but am aware there are differences of opinion so lets thrash that out. Assuming the above is a fair statement, then it is next clear that the only stable parts of a MNs address as it moves, which could be safely installed into the foreign multicast routing state, is either its HoA or the InterfaceID part of a universal CCoA. There are potential slowly moving changes to multicast routing protocols (that need significant investigation) that might enable the MN to scalably originate packets into the foreign multicast system. Therefore, draft 18 should refer to this future possibility. However, this work can only progress with significant buy-in, support and work from the multicast community and I have therefore started some effort in stimulating awareness of the issue with the relevant ADs and chairs. In parallel with this, there are some potential shorter term work arounds which might be possible which involve modifying the MIP/multicast interface rather than the multicast protocols themselves. These protocol specific solutions are not appropriate for standardisation but might be useful within specific domains here the operator knows what they are doing.. The protocol specific fixes might however be useful to put in an Informational RFC. One of these interim workarounds however seems to be reasonably general (and yes hacky and maybe long-lived) which we could put into the base spec as the sole option for foreign multicast origination, but this does come with some future costs. The interim solution is hybrid multicast whereby the MN joins group G as a receiver into the foreign multicast system via MLD and normal multicast mechanisms will build the tree for that group G receiver branch towards the sender(s) on that group. In addition, the MN originates multicast to the group using its HoA by reverse tunnelling it to the home network, where it is injected into the home multicast system as a non-member sender on group G. No MLD signalling is therefore sent to the HA so the HA must be prepared to forward such multicast onto the home subnet where multicast mechansims will need to inject it into the group G tree. The packets must be sent to the Home subnet so that they will pass the multicast RPF check on the HoA multicast source address. These HoA originated packets will come down the multicast tree and arrive back at the MNs access router where there is MLD state for group G. The HoA sourced packets needs to be delivered to other members of group G on that multicast router, but should ideally not be delivered to the MN that owns the HoA in the source address of the multicast packet. This can only be achieved through the MN sending an MLD join to the access router for which it specifically excludes itself from receiving packets with HoA as a source address (source pruning..via exclude). This should work although it needs to be closely reviewed. The cost though is that the MN needs to know to do this which means an assumption is being made about the nature of multicast protocol support in the foreign domain. If that support changes, then we need a way to upgrade MNs with a replacement mechanism so that they can completely exploit the foreign multicast system. In addition, given that all domains will not upgrade their intra-domain multicast protocols at the same time, we need to ensure that incremental deployment is possible so that once a MN originates into the foreign multicast system, subsequent instabilities are not introduced into downstream domains... So I would suggest that in base MIPv6 we bar the use of the CCoA as a MN multicast source address for now (and possibly for ever to be repalced by the HoA). We can allow home multicast and potentially allow hybrid multicast with the latter requiring some discussion. What is not in base spec should go into future revisions of draft-oneill -mip-multicast.. and evolved into a wg draft. We can get a few interested parties to explore the issues and work with the multicast community on this. This will no doubt be a long term effort but we should be able to state the immediate problem and the ideal requirements, and then pass to the multicast folks. We then need to stick around and help them build some appropriate longer term solutions... Finally, also note that the multicast text and mechanisms in RFC3220 needs to be updated to restrict MN origination into the foreign multicast system using a CCoA, with similar reasons and options. The hybrid model is again applicable but this case has the advantage though that the FA can redirect the non-member sender multicast to the HA and hence hide the type of multcast support from the MN.. I hope that clarifies the problem to all and lays done a useful way forward for the base spec and for MIP/multicast. I'll also put up some basic slides to illustrate this a bit better on the Flarion site and repost feedback from the multicast community on their view of these issues. Alan. **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 05:37:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15168 for ; Tue, 16 Jul 2002 05:37:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11820; Tue, 16 Jul 2002 03:37:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02087; Tue, 16 Jul 2002 02:37:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G9WeoN025954 for ; Tue, 16 Jul 2002 02:32:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G9We6E025953 for mobile-ip-dist; Tue, 16 Jul 2002 02:32:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G9WboN025946 for ; Tue, 16 Jul 2002 02:32:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07098 for ; Tue, 16 Jul 2002 02:32:39 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24985 for ; Tue, 16 Jul 2002 02:32:39 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098HXNL>; Tue, 16 Jul 2002 05:32:38 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4601202EB5@ftmail.lab.flarion.com> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Beyond draft 18 Date: Tue, 16 Jul 2002 05:32:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I have a few concerns about some features in draft 18 when applied in specific future deployment scenarios (ie not protocol problems for now but I guess applicability issues). Specifically they relate to the applicability of the existing RO mechanisms during rapid movement that may be possible in future cellular networks with small cells (eg a Manhatten deployment). In contrast the existing mechanisms seem ok for 3GPPx and 802.11 clusters where movement is less rapid due to the existance of radio specific hand-off protocols such as RNC relocation and IAPP etc. I have discussed these issues with the chairs and they have recommended I write up a detailed draft because of the complexities and subtleties involved. I agree with the chairs that these may have to be post base spec given the significant investment to date. However, I hope the draft will motivate future additional RO design work in this space and may even attempt to indicate specific requirements and solution options so we can avoid any major barriers to this in the base spec. I guess any near term design work might fit in with some of the stuff coming from last nights BAR BOF.. If people have similar concerns then by all means contact me privately..although it might be worth waiting for the draft for obvious reasons.. Alan. **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 07:07:15 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17296 for ; Tue, 16 Jul 2002 07:07:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16085; Tue, 16 Jul 2002 05:06:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29710; Tue, 16 Jul 2002 04:06:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GB5QoN026220 for ; Tue, 16 Jul 2002 04:05:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GB5QpO026219 for mobile-ip-dist; Tue, 16 Jul 2002 04:05:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GB5NoN026212 for ; Tue, 16 Jul 2002 04:05:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14591 for ; Tue, 16 Jul 2002 04:05:24 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13973 for ; Tue, 16 Jul 2002 05:05:23 -0600 (MDT) Message-ID: <007201c22cb8$7397ad80$516015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , References: <8C92E23A3E87FB479988285F9E22BE4601202EB5@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] Beyond draft 18 Date: Tue, 16 Jul 2002 04:03:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan, Performance of RO was a key issue in last night's BAR BOF. A draft with your views would be helpful. jak ----- Original Message ----- From: "Alan O'Neill" To: Sent: Tuesday, July 16, 2002 2:32 AM Subject: [mobile-ip] Beyond draft 18 > I have a few concerns about some features in draft 18 when applied in > specific future deployment scenarios (ie not protocol problems for now but I > guess applicability issues). > > Specifically they relate to the applicability of the existing RO mechanisms > during rapid movement that may be possible in future cellular networks with > small cells (eg a Manhatten deployment). In contrast the existing mechanisms > seem ok for 3GPPx and 802.11 clusters where movement is less rapid due to > the existance of radio specific hand-off protocols such as RNC relocation > and IAPP etc. > > I have discussed these issues with the chairs and they have recommended I > write up a detailed draft because of the complexities and subtleties > involved. I agree with the chairs that these may have to be post base spec > given the significant investment to date. However, I hope the draft will > motivate future additional RO design work in this space and may even attempt > to indicate specific requirements and solution options so we can avoid any > major barriers to this in the base spec. I guess any near term design work > might fit in with some of the stuff coming from last nights BAR BOF.. > > If people have similar concerns then by all means contact me > privately..although it might be worth waiting for the draft for obvious > reasons.. > > Alan. > > > > > **************************************************************************** > ************************************ > This email may contain confidential and privileged material for the sole use > of the > intended recipient. Any review or distribution by others is strictly > prohibited. > If you are not the intended recipient please contact the sender and delete > all copies. > **************************************************************************** > ************************************* > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 08:41:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18532 for ; Tue, 16 Jul 2002 08:41:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22065; Tue, 16 Jul 2002 06:41:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01782; Tue, 16 Jul 2002 05:41:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GCeeoN026443 for ; Tue, 16 Jul 2002 05:40:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GCedsS026442 for mobile-ip-dist; Tue, 16 Jul 2002 05:40:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GCeaoN026435 for ; Tue, 16 Jul 2002 05:40:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01602 for ; Tue, 16 Jul 2002 05:40:38 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11084 for ; Tue, 16 Jul 2002 06:40:37 -0600 (MDT) Received: from kmilesw2k (lon-sto4-lan-vlan133-dhcp22.cisco.com [144.254.108.89]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA24683; Tue, 16 Jul 2002 13:40:34 +0100 (BST) From: "Kevin Miles" To: "'T.J. Kniveton'" , Subject: RE: [mobile-ip] Comment on Issue 56 (Optimizations in DHAD) Date: Tue, 16 Jul 2002 13:40:32 +0100 Message-ID: <018001c22cc5$fa738790$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3D3385B2.3040300@kniveton.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > Optimization #1 is a good one, since it is likely that the sending HA > will always want itself as the highest priority. Why? It will depend on Preference values. I don't really care which solution is chosen, but IMHO this seems like a disproportionate amount of effort to *possibly* save 16 bytes in a packet that already carries an overhead of 56 bytes even before the HA address list is inserted. If bandwidth is that scarce, perhaps we should consider reducing the size of the Reserved field which currently occupies 10 bytes. (Only (half) kidding:-) Regards, Kevin. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 11:15:54 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21506 for ; Tue, 16 Jul 2002 11:15:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28028; Tue, 16 Jul 2002 08:14:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15701; Tue, 16 Jul 2002 08:14:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFCwoN026892 for ; Tue, 16 Jul 2002 08:12:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GFCwdA026891 for mobile-ip-dist; Tue, 16 Jul 2002 08:12:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFCroN026882 for ; Tue, 16 Jul 2002 08:12:54 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6GFCpg24983; Tue, 16 Jul 2002 17:12:52 +0200 (MEST) Date: Tue, 16 Jul 2002 16:10:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] BU AltSec BAR BOF Report To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <00a801c22c6a$36a56640$256015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > We also discussed a couple simple optimizations of Return Routability, like > substituting for the Home Address Cookie, that would improve the performance > but still maintain the basic algorithm. I think a word is missing above. Substituting what for the HA cookie? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 11:15:59 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21518 for ; Tue, 16 Jul 2002 11:15:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28035; Tue, 16 Jul 2002 08:14:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28612; Tue, 16 Jul 2002 08:14:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFD7oN026902 for ; Tue, 16 Jul 2002 08:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GFD7Fv026901 for mobile-ip-dist; Tue, 16 Jul 2002 08:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFD1oN026894 for ; Tue, 16 Jul 2002 08:13:02 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6GFCxg24992; Tue, 16 Jul 2002 17:12:59 +0200 (MEST) Date: Tue, 16 Jul 2002 16:14:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] minor comments on draft 18 To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D3317D6.58ADBEE0@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > remove 'if it believes the amount of traffic with the correspondent > justifies the use of route optimization'. it is already a MAY. it > is very often difficult to figure out (from the kernel) the amount > of traffic than an application might generated. > > anyway, the previous line says 'it MAY start a return routability > procedue'. I dont think we have to supply the reason not to do it. I personally see great benefits in providing these suggestions to implementors. I'm concerns that without them implementors of MNs might think that it is best to always immediately initiate the BU procedure with any CN. Such an approach would lead to a performance loss (e.g. if done before every DNS query is sent to a DNS server, or for other short transactions). If MIPv6 RO causes a performance loss for short transactions yet is "advertised" to be a performance improved (and delivers performance improvements for long transactions) it would be unfortunate. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 11:16:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21530 for ; Tue, 16 Jul 2002 11:16:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28148; Tue, 16 Jul 2002 08:14:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15820; Tue, 16 Jul 2002 08:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFCroN026883 for ; Tue, 16 Jul 2002 08:12:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GFCrhI026881 for mobile-ip-dist; Tue, 16 Jul 2002 08:12:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GFCnoN026874 for ; Tue, 16 Jul 2002 08:12:50 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6GFCkg24966; Tue, 16 Jul 2002 17:12:47 +0200 (MEST) Date: Tue, 16 Jul 2002 16:09:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Issue 63: Multicast To: "Alan O'Neill" Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <8C92E23A3E87FB479988285F9E22BE4601202EB2@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The suggested resolution was that the use of the home multicast system via a > bi-directional tunnel be included in the spec (fine) but that a MN can > optionally use, for the foreign multicast system, its CCoA as a source > address (not fine) to originate traffic to a multicast group, and that the > detailed mechanisms for this would be detailed in draft-oneill-multicast > etc.. The way I see this both approaches have performance issues of different flavors. Reverse tunneling packets through the HA adds delay for packets (and is subject to additional potentially congested devices in the network). Using the CoA as the source causes multicast routing related overhead as you point out. Thus I don't think we can say that one is strictly better than the other; the performance issues aren't comparable. Hence I don't see a need to prohibit sending packets with the CoA as the source. > It is as dangerous and unscalable (possibly more so) as supporting > MN movement in the unicast routing system by using host routes rather than > MIP edge tunnel redirection. I suspect there are cases when reverse tunneling is equally "dangerous and unscalable" - it all depends on the assumptions. So either we allow both ways (and provide future documentation with guidance on the issues and tradeoffs between them) or we forbit both. There are similar issues for the joining of multicast groups. If it is done using the local interface (the "CoA") then the multicast tree will change as the MN moves, which is bad. If it is done over the reverse tunnel (the "HoA") then the multicast packets will be tunneled from the HA even though copies of the same multicast packets might already be present on the visited link. Also in that case I think both approaches make sense under different cicumstances. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 14:30:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26412 for ; Tue, 16 Jul 2002 14:30:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27810; Tue, 16 Jul 2002 12:30:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12240; Tue, 16 Jul 2002 11:30:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GITGoN027436 for ; Tue, 16 Jul 2002 11:29:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GITGZW027435 for mobile-ip-dist; Tue, 16 Jul 2002 11:29:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GITCoN027428 for ; Tue, 16 Jul 2002 11:29:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27775 for ; Tue, 16 Jul 2002 11:29:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17093 for ; Tue, 16 Jul 2002 12:29:13 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24859; Tue, 16 Jul 2002 11:29:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6GITCq22488; Tue, 16 Jul 2002 11:29:12 -0700 X-mProtect: <200207161829> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzb0Xif; Tue, 16 Jul 2002 11:29:10 PDT Message-ID: <3D3465F7.5E7F2C20@iprg.nokia.com> Date: Tue, 16 Jul 2002 11:29:11 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Beyond draft 18 References: <8C92E23A3E87FB479988285F9E22BE4601202EB5@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Alan, Alan O'Neill wrote: > > I have a few concerns about some features in draft 18 when applied in > specific future deployment scenarios (ie not protocol problems for now but I > guess applicability issues). > > Specifically they relate to the applicability of the existing RO mechanisms > during rapid movement that may be possible in future cellular networks with > small cells (eg a Manhatten deployment). Fast Handoffs (specifically FMIPv6). it moves the RO part out of the critical stage, by tunneling to the oldCoA of the MN from the oldAR. the MN has enough time to do Return Routability based RO. > **************************************************************************** > ************************************ > This email may contain confidential and privileged material for the sole use > of the > intended recipient. Any review or distribution by others is strictly > prohibited. > If you are not the intended recipient please contact the sender and delete > all copies. > **************************************************************************** > ************************************* this statement is not conformant to the IETF policy. this prevents me from forwarding this mail to anyone I wish. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 15:09:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27378 for ; Tue, 16 Jul 2002 15:09:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16125; Tue, 16 Jul 2002 13:09:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13652; Tue, 16 Jul 2002 12:09:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GJ8coN027603 for ; Tue, 16 Jul 2002 12:08:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GJ8cOv027602 for mobile-ip-dist; Tue, 16 Jul 2002 12:08:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GJ8YoN027595 for ; Tue, 16 Jul 2002 12:08:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13342 for ; Tue, 16 Jul 2002 12:08:33 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18326 for ; Tue, 16 Jul 2002 13:08:32 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6GJ8OqI025131; Tue, 16 Jul 2002 12:08:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACD42684; Tue, 16 Jul 2002 12:03:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00662; Tue, 16 Jul 2002 12:08:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15668.28451.838538.614608@thomasm-u1.cisco.com> Date: Tue, 16 Jul 2002 12:08:19 -0700 (PDT) To: Francis Dupont Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-Reply-To: <200207160115.g6G1FvGF063795@givry.rennes.enst-bretagne.fr> References: <15666.61635.91186.184127@thomasm-u1.cisco.com> <200207160115.g6G1FvGF063795@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > In your previous mail you wrote: > > > Please put again the R bit in BUs, R is set to one if the MN is a router, > > R is set to zero if it is a host *and* this bit is copied into Neighbor > > Advertisements (in the R bit :-) sent by the Home Agent on behalf > > of the MN. > > I'll bite: what does something do with this information? > > => we have the choice between either changing MN to MH in the specs or > putting the correct value in the R bit of NAs (:-). Francis, I'm afraid this is little too oblique for poor moi. I'm sorry if I'm being dense here as I'm unfortunately not asking rhetorical questions. What would a neighbor do if it saw the R bit set in the NA for my mobile node? Set up a default route? Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 18:10:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01156 for ; Tue, 16 Jul 2002 18:10:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24073; Tue, 16 Jul 2002 16:10:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05503; Tue, 16 Jul 2002 15:10:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GM9ToN028074 for ; Tue, 16 Jul 2002 15:09:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GM9SMV028073 for mobile-ip-dist; Tue, 16 Jul 2002 15:09:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GM9PoN028066 for ; Tue, 16 Jul 2002 15:09:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05133 for ; Tue, 16 Jul 2002 15:09:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23537 for ; Tue, 16 Jul 2002 16:09:26 -0600 (MDT) Message-ID: <002201c22d15$387378d0$516015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] BU AltSec BAR BOF Report Date: Tue, 16 Jul 2002 15:07:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > We also discussed a couple simple optimizations of Return Routability, like > > substituting for the Home Address Cookie, that would improve the performance > > but still maintain the basic algorithm. > > I think a word is missing above. Substituting what for the HA cookie? > Tuomas made this suggestion. He did not elaborate on it at the time. Perhaps he could elaborate now? jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 19:59:24 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03425 for ; Tue, 16 Jul 2002 19:59:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02806; Tue, 16 Jul 2002 16:57:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10386; Tue, 16 Jul 2002 16:57:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GNufoN028329 for ; Tue, 16 Jul 2002 16:56:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GNufY0028328 for mobile-ip-dist; Tue, 16 Jul 2002 16:56:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GNuboN028321 for ; Tue, 16 Jul 2002 16:56:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10019 for ; Tue, 16 Jul 2002 16:56:40 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02304 for ; Tue, 16 Jul 2002 16:56:40 -0700 (PDT) Message-ID: <000501c22d23$bc195fc0$ba4c5d85@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "'James Kempf'" , "Rajeev Koodli" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Tue, 16 Jul 2002 07:28:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ajoy, > Ajoy-> Target trigger will be suitable for cellular > networks. BTW, even in case of WLAN, you can receive > L2-TT trigger at nAP. L2TT (Re-association Request) can > provide nAP the L2 address of the oldAP as well as L2 > address of the mobile node. If we implement FA function Does re-association also apply to BSS mode, or when the station moves between two different ESS? If it is only used when the station moves from one AP to another in the same ESS, this is not as interesting, because the mobility is already handled at link-layer in 802.11b. > at AP, then this becomes an implementation issue. > If not, then you need to define some protocol between > AP and AR which can be addressed in separate document. http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt ... > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does > not work for network initiated trigger. BTW, based upon our > implementation, we found anticipated handover does not provide > good performance on cellular link. Hence, anticipated handover > is not going to address fast handoff need for various cellular networks. Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation? alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 20:41:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05228 for ; Tue, 16 Jul 2002 20:41:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01541; Tue, 16 Jul 2002 18:42:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29553; Tue, 16 Jul 2002 17:42:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H0f7oN028952 for ; Tue, 16 Jul 2002 17:41:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H0f6ql028951 for mobile-ip-dist; Tue, 16 Jul 2002 17:41:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H0f3oN028944 for ; Tue, 16 Jul 2002 17:41:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22921 for ; Tue, 16 Jul 2002 17:41:05 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19908 for ; Tue, 16 Jul 2002 17:41:04 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6H0eov06578; Wed, 17 Jul 2002 02:40:50 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA20051; Wed, 17 Jul 2002 02:40:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6H0eoGF066719; Wed, 17 Jul 2002 02:40:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-reply-to: Your message of Tue, 16 Jul 2002 12:08:19 PDT. <15668.28451.838538.614608@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 02:40:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => we have the choice between either changing MN to MH in the specs or > putting the correct value in the R bit of NAs (:-). What would a neighbor do if it saw the R bit set in the NA for my mobile node? Set up a default route? => the answer is in the RFC 2461 (grep for IsRouter). The R bit is copied into the neighbor cache entry (in the IsRouter bit) and the important case is the transition from 1 to 0 (i.e., a router which becomes a host) when the node is used as a default router or in a redirect... Today all MNs are MHs but we should *not* close the door to MRs just for one bit, and without any argument. See you this afternoon? Francis.Dupont@enst-bretagne.fr PS: the R bit was added in I-D 08 (at my request) and lost in I-D 15 for an unknown reason (typo?). From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 21:17:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06133 for ; Tue, 16 Jul 2002 21:17:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20490; Tue, 16 Jul 2002 19:17:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02992; Tue, 16 Jul 2002 18:17:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1GUoN029112 for ; Tue, 16 Jul 2002 18:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1GUIS029111 for mobile-ip-dist; Tue, 16 Jul 2002 18:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1GRoN029104 for ; Tue, 16 Jul 2002 18:16:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02933 for ; Tue, 16 Jul 2002 18:16:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21000 for ; Tue, 16 Jul 2002 19:16:27 -0600 (MDT) Message-ID: <006e01c22d2f$53d7a730$506015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "Rajeev Koodli" , References: <000501c22d23$bc195fc0$ba4c5d85@AlperVAIO> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Tue, 16 Jul 2002 18:11:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Reassociation.request() is sent whenever the mobile station is in infrastructure mode. jak ----- Original Message ----- From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" Cc: "'James Kempf'" ; "Rajeev Koodli" ; Sent: Tuesday, July 16, 2002 7:28 AM Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > Hi Ajoy, > > > Ajoy-> Target trigger will be suitable for cellular > > networks. BTW, even in case of WLAN, you can receive > > L2-TT trigger at nAP. L2TT (Re-association Request) can > > provide nAP the L2 address of the oldAP as well as L2 > > address of the mobile node. If we implement FA function > > Does re-association also apply to BSS mode, or when > the station moves between two different ESS? > > If it is only used when the station moves from one AP > to another in the same ESS, this is not as interesting, > because the mobility is already handled at link-layer > in 802.11b. > > > at AP, then this becomes an implementation issue. > > If not, then you need to define some protocol between > > AP and AR which can be addressed in separate document. > > http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt > > ... > > > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does > > not work for network initiated trigger. BTW, based upon our > > implementation, we found anticipated handover does not provide > > good performance on cellular link. Hence, anticipated handover > > is not going to address fast handoff need for various cellular networks. > > Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation? > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 21:22:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06218 for ; Tue, 16 Jul 2002 21:22:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05165; Tue, 16 Jul 2002 18:21:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03970; Tue, 16 Jul 2002 18:20:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1KEoN029234 for ; Tue, 16 Jul 2002 18:20:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1KENO029233 for mobile-ip-dist; Tue, 16 Jul 2002 18:20:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1KBoN029226 for ; Tue, 16 Jul 2002 18:20:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03749 for ; Tue, 16 Jul 2002 18:20:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22501 for ; Tue, 16 Jul 2002 19:20:08 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA17438; Tue, 16 Jul 2002 18:20:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6H1K6D18686; Tue, 16 Jul 2002 18:20:06 -0700 X-mProtect: <200207170120> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdb3cok9; Tue, 16 Jul 2002 18:20:02 PDT Message-ID: <3D34C643.6741CBC6@iprg.nokia.com> Date: Tue, 16 Jul 2002 18:20:03 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => the answer is in the RFC 2461 (grep for IsRouter). > The R bit is copied into the neighbor cache entry (in the IsRouter bit) > and the important case is the transition from 1 to 0 (i.e., a router > which becomes a host) when the node is used as a default router or > in a redirect... > Today all MNs are MHs but we should *not* close the door to MRs > just for one bit, and without any argument. > > See you this afternoon? > > Francis.Dupont@enst-bretagne.fr > > PS: the R bit was added in I-D 08 (at my request) > and lost in I-D 15 for an unknown reason (typo?). I think it was removed when Mobile Routers were considered out of scope of the current spec. the prefix length field was also removed from the BU at the same time for the same reason. I thought it was the WG decision to remove all references to mobile routers in the base MIPv6 spec. I dont remember. anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt (and a separate prefix option) Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 21:36:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06428 for ; Tue, 16 Jul 2002 21:36:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15592; Tue, 16 Jul 2002 19:36:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08624; Tue, 16 Jul 2002 18:36:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1ZToN029420 for ; Tue, 16 Jul 2002 18:35:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1ZTXl029419 for mobile-ip-dist; Tue, 16 Jul 2002 18:35:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1ZQoN029412 for ; Tue, 16 Jul 2002 18:35:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08238 for ; Tue, 16 Jul 2002 18:35:28 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22441 for ; Tue, 16 Jul 2002 19:35:27 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA23787 for ; Wed, 17 Jul 2002 10:35:26 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA18363 for ; Wed, 17 Jul 2002 10:35:25 +0900 (JST) Date: Wed, 17 Jul 2002 10:34:02 +0900 (JST) Message-Id: <20020717.103402.51765637.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] a summary of problems for the requirements to the IPv6 base spec From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I know many of you are tired to read my mail. But, before IPv6 WG session, please give me a chance to explain why I think it hard. There are two parts in the requirements. One is already accepted by the IPv6 WG. The other is not preseneted to them yet. If we want to put HAO and BE processing into the IPv6 base spac, we must update the following things. (1) [already accepted by the IPv6 WG] HAO format definition. (2) [already accepted by the IPv6 WG] Modification of the recommended order of the extension headers defined in the section 4.1 of RFC2460, because HAO is not placed in the DO1 nor DO2. (3) [not presented yet] IPsec consideration. HAO must not be processed if the packet which contains HAO is not protected by the IPsec. (4-a) [not presented yet] Introducing a new extension header, the mobility header. To be able to send a binding error message from IPv6 node, we must define a mobility header in the IPv6 base spec. (4-b) [not presented yet] A new recomended extension header order which describes that the position of the mobility header. The last 3 items are not presented to IPv6 WG. I'm not sure it is OK for them without any discussion. If the IPv6 WG does not accept them, the mobile ipv6 draft will not be accepted to become a rfc. I really want to make mip6 become standard, not complaining without any reason. So, please consider to talk with IPv6 people about the new requirements for them. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 21:49:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07134 for ; Tue, 16 Jul 2002 21:49:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19925; Tue, 16 Jul 2002 19:49:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10418; Tue, 16 Jul 2002 18:49:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1mgoN029645 for ; Tue, 16 Jul 2002 18:48:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1mg3V029644 for mobile-ip-dist; Tue, 16 Jul 2002 18:48:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1mboN029637 for ; Tue, 16 Jul 2002 18:48:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14783 for ; Tue, 16 Jul 2002 18:48:38 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19421 for ; Tue, 16 Jul 2002 19:48:36 -0600 (MDT) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 61C1B5D09D; Wed, 17 Jul 2002 10:48:34 +0900 (JST) Date: Wed, 17 Jul 2002 10:47:38 +0900 (JST) Message-Id: <20020717.104738.104531873.ernst@sfc.wide.ad.jp> To: vijayd@iprg.nokia.com Cc: Francis.Dupont@enst-bretagne.fr, mat@cisco.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs From: Thierry Ernst In-Reply-To: <3D34C643.6741CBC6@iprg.nokia.com> References: <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> <3D34C643.6741CBC6@iprg.nokia.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Vijay Devarapalli Subject: Re: [mobile-ip] R (router) bit in BUs Date: Tue, 16 Jul 2002 18:20:03 -0700 Content-Transfer-Encoding: 7bit > Francis Dupont wrote: > > > => the answer is in the RFC 2461 (grep for IsRouter). > > The R bit is copied into the neighbor cache entry (in the IsRouter bit) > > and the important case is the transition from 1 to 0 (i.e., a router > > which becomes a host) when the node is used as a default router or > > in a redirect... > > Today all MNs are MHs but we should *not* close the door to MRs > > just for one bit, and without any argument. > > > > See you this afternoon? > > > > Francis.Dupont@enst-bretagne.fr > > > > PS: the R bit was added in I-D 08 (at my request) > > and lost in I-D 15 for an unknown reason (typo?). > > I think it was removed when Mobile Routers were considered out of > scope of the current spec. the prefix length field was also removed > from the BU at the same time for the same reason. I thought it was > the WG decision to remove all references to mobile routers in the > base MIPv6 spec. I dont remember. As far as I remember, the prefix length field was there to form other's MN addresses like the link-local etc. Nothing to do with MRs. This has always been missunderstood. Concerning the 'R' bit, I think it should be good to keep it in the draft, ND may later need to distinguish between the two. Keeping it doesn't means MIPv6 is dealing with the specific actions to be taken with MRs. Thierry. INRIA - WIDE - Keio University > anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt > (and a separate prefix option) From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 22:06:24 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08018 for ; Tue, 16 Jul 2002 22:06:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20074; Tue, 16 Jul 2002 19:05:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12900; Tue, 16 Jul 2002 19:04:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H22joN029936 for ; Tue, 16 Jul 2002 19:02:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H22jbw029935 for mobile-ip-dist; Tue, 16 Jul 2002 19:02:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H22foN029928 for ; Tue, 16 Jul 2002 19:02:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15531 for ; Tue, 16 Jul 2002 19:02:44 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02220 for ; Tue, 16 Jul 2002 20:02:43 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jul 2002 21:57:19 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIPv6 WG Last call closed Date: Tue, 16 Jul 2002 21:57:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The WG last call for MIPv6 has completed. For each issue received, Jari will post a proposed resolution to the mailing list, including text changes (new text, corrections, deletions). This will provide an opportunity for the WG to respond. These changes will be incorporated into a new version of the draft sent to the IESG for IETF last call. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 22:30:46 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08921 for ; Tue, 16 Jul 2002 22:30:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15172; Tue, 16 Jul 2002 20:31:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17664; Tue, 16 Jul 2002 19:31:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H2UCoN000185 for ; Tue, 16 Jul 2002 19:30:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H2UBYR000183 for mobile-ip-dist; Tue, 16 Jul 2002 19:30:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H2U8oN000176 for ; Tue, 16 Jul 2002 19:30:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22286 for ; Tue, 16 Jul 2002 19:30:11 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14501 for ; Tue, 16 Jul 2002 20:30:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6H2Thv09762; Wed, 17 Jul 2002 04:29:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA20820; Wed, 17 Jul 2002 04:29:43 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6H2ThGF067319; Wed, 17 Jul 2002 04:29:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-reply-to: Your message of Tue, 16 Jul 2002 18:20:03 PDT. <3D34C643.6741CBC6@iprg.nokia.com> Date: Wed, 17 Jul 2002 04:29:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > PS: the R bit was added in I-D 08 (at my request) > and lost in I-D 15 for an unknown reason (typo?). I think it was removed when Mobile Routers were considered out of scope of the current spec. the prefix length field was also removed from the BU at the same time for the same reason. I thought it was the WG decision to remove all references to mobile routers in the base MIPv6 spec. I dont remember. => if this is the reason it is a bad one because a MR is two different things: - a node which is a router too but in this context acts as a host (cf. the so called "host function" of routers in IPv4) - a mobile router in the NEMO termonology. The R bit belongs to the first part so should *not* be removed as the prefix length of second part. anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt (and a separate prefix option) => in order to make the mobile router draft sound the R bit should be reserved in the MN document, so there is no real argument against to put it back into the MN document. Of course, this does *not* applies to the prefix option. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 22:41:59 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09611 for ; Tue, 16 Jul 2002 22:41:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05515; Tue, 16 Jul 2002 20:42:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24062; Tue, 16 Jul 2002 19:42:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H2fPoN000433 for ; Tue, 16 Jul 2002 19:41:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H2fPp4000432 for mobile-ip-dist; Tue, 16 Jul 2002 19:41:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H2fMoN000425 for ; Tue, 16 Jul 2002 19:41:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24796 for ; Tue, 16 Jul 2002 19:41:25 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02888 for ; Tue, 16 Jul 2002 19:41:21 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6H2f74l018650; Tue, 16 Jul 2002 19:41:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE03598; Tue, 16 Jul 2002 19:36:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA00680; Tue, 16 Jul 2002 19:41:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15668.55622.582828.579716@thomasm-u1.cisco.com> Date: Tue, 16 Jul 2002 19:41:10 -0700 (PDT) To: Francis Dupont Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-Reply-To: <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> References: <15668.28451.838538.614608@thomasm-u1.cisco.com> <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > In your previous mail you wrote: > > > => we have the choice between either changing MN to MH in the specs or > > putting the correct value in the R bit of NAs (:-). > > What would a neighbor do if it saw the R bit set > in the NA for my mobile node? Set up a default > route? > > => the answer is in the RFC 2461 (grep for IsRouter). > The R bit is copied into the neighbor cache entry (in the IsRouter bit) > and the important case is the transition from 1 to 0 (i.e., a router > which becomes a host) when the node is used as a default router or > in a redirect... I'm still at a loss here because in order to be a real mobile router, you are going to either need to have a prefix delegated to you by your home agent, or you are going to want to advertize routes to the HA's subnet, neither of which MIP has any provision for. Right? I'm sorry if I'm being dense. > Today all MNs are MHs but we should *not* close the door to MRs > just for one bit, and without any argument. Ah, I don't see reserving the bit as closing the door on MR's. I see it as deferring it so that we get it right. Note that I don't have an issue with a "simple" MIP based MR solution so long as we understand the tradeoffs, and we are sensible with interactions; in particular, I remain concerned about RO's interaction. > See you this afternoon? It would be a very long swim... Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 16 23:41:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10568 for ; Tue, 16 Jul 2002 23:41:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20672; Tue, 16 Jul 2002 21:41:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08751; Tue, 16 Jul 2002 20:41:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H3eAoN000740 for ; Tue, 16 Jul 2002 20:40:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H3eATF000739 for mobile-ip-dist; Tue, 16 Jul 2002 20:40:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H3e5oN000732 for ; Tue, 16 Jul 2002 20:40:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04387 for ; Tue, 16 Jul 2002 20:40:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01493 for ; Tue, 16 Jul 2002 21:40:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA22309; Tue, 16 Jul 2002 20:40:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6H3e6826299; Tue, 16 Jul 2002 20:40:06 -0700 X-mProtect: <200207170340> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdU3L4Lg; Tue, 16 Jul 2002 20:40:04 PDT Message-ID: <3D34E6B0.BCE33E16@iprg.nokia.com> Date: Tue, 16 Jul 2002 20:38:24 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170040.g6H0eoGF066719@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, As document editor, I was given the very clear message to remove specification related to protocol for mobile routers. I did this, even though my personal preference was to leave it in because I always thought it was useful functionality. Francis Dupont wrote: > Francis.Dupont@enst-bretagne.fr > > PS: the R bit was added in I-D 08 (at my request) > and lost in I-D 15 for an unknown reason (typo?). It was not a typo. It was according to very clear indication after the Mobile Routers BOF, and I think according to explicit instruction from the chairs but I didn't go checking for e-mails on that. I hope it does not get to be the case that working as document editor does not entail keeping paper trails for every word of every revision. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 00:06:14 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10991 for ; Wed, 17 Jul 2002 00:06:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23756; Tue, 16 Jul 2002 21:04:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03785; Tue, 16 Jul 2002 21:04:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H43NoN000930 for ; Tue, 16 Jul 2002 21:03:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H43NUl000929 for mobile-ip-dist; Tue, 16 Jul 2002 21:03:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H43JoN000922 for ; Tue, 16 Jul 2002 21:03:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03504 for ; Tue, 16 Jul 2002 21:03:23 -0700 (PDT) Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26011 for ; Tue, 16 Jul 2002 21:03:20 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KK7CPSX4MS9EE518@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 17 Jul 2002 14:01:28 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 9031612C002; Wed, 17 Jul 2002 04:01:26 +0000 (/etc/localtime) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 2164512C002; Wed, 17 Jul 2002 14:01:21 +1000 (EST) Date: Wed, 17 Jul 2002 14:01:20 +1000 From: Greg Daley Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt To: James Kempf Cc: Vijay Devarapalli , Jari Arkko , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D34EC10.6050006@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> <3D2F7BD1.BCC68477@iprg.nokia.com> <00ed01c22a6d$66a47150$056015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi All, HMIPv6 uses Alt-coa extensively. IMHO, sending should be optional, but processing should be mandated as part of MIPv6. The decision then becomes choice by the MN to advertise a different CoA (which is what it really is for). Greg Daley James Kempf wrote: > Why not have it be an option? There will likely be other algorithms that will be used for protecting BUs and they may need > other stuff. > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Jari Arkko" > Cc: > Sent: Friday, July 12, 2002 6:01 PM > Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt > > > >>Jari Arkko wrote: >> >> >>>It looks like we need to deal with this, so in order for ESP to be used >>>we need to have the alt coa option in the spec. However, I dislike >>>format variants, especially when the choice depends on a user-configured >>>SPD entry in an another part of the system. This creates an unnecessary >>>restriction between IPv6 stack parts. Therefore, I'd like to suggest the >>>alt coa option to be made a fixed field in the BU messages instead, and >>>to be always used. >> >>I didnt quite follow the last paragraph. for Return Routability >>protected >>BUs, there is no need for the CoA to be present as a fixed field in the >>BU. for ESP protected BUs, it needs to be there. so we would end up with >>two formats for BUs. >> >>Vijay >> > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 00:09:10 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11063 for ; Wed, 17 Jul 2002 00:09:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24707; Tue, 16 Jul 2002 21:07:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04480; Tue, 16 Jul 2002 21:07:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H46voN001067 for ; Tue, 16 Jul 2002 21:06:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H46uBI001066 for mobile-ip-dist; Tue, 16 Jul 2002 21:06:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H46roN001059 for ; Tue, 16 Jul 2002 21:06:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09153 for ; Tue, 16 Jul 2002 21:06:57 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24501 for ; Tue, 16 Jul 2002 21:06:57 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098HZLB>; Wed, 17 Jul 2002 00:06:55 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C37459@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue 63: Multicast Date: Wed, 17 Jul 2002 00:06:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Eric, The reason that I wish to restrict the use of the CoA as the source for foreign network multicast is not due to any comparison with reverse-tunnelled multicast. Home and foreign multicast systems are needed for many different technical and commercial reasons clearly. However, it is not clear at the moment whether foreign network multicast should ultimately use the the CoA or the HoA as the source address, so we should do that work before giving the MN the option of origination into the foreign system because of forwards compatibility.. The former has the problem that the multicast system will be thrashed whilst the latter has the RPF problem. Either might be fixable and a range of protocol (domain) specific solutions exist in the interim which we can document, including hybrid. I don't understand how a potential thrashing problem can be allowed to progress through the base spec. Maybe you don't believe this exists, or is that you believe we can trust vendors and operators to do the right thing ? Clarifying this would help...Maybe this could alternatively be addressed with some applicability words that specifically does not rule out hybrid or otheruses of the HoA as a foreign multicast source address ? -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: 16 July 2002 23:40 To: Alan O'Neill Cc: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Issue 63: Multicast > The suggested resolution was that the use of the home multicast system via a > bi-directional tunnel be included in the spec (fine) but that a MN can > optionally use, for the foreign multicast system, its CCoA as a source > address (not fine) to originate traffic to a multicast group, and that the > detailed mechanisms for this would be detailed in draft-oneill-multicast > etc.. The way I see this both approaches have performance issues of different flavors. Reverse tunneling packets through the HA adds delay for packets (and is subject to additional potentially congested devices in the network). Using the CoA as the source causes multicast routing related overhead as you point out. Thus I don't think we can say that one is strictly better than the other; the performance issues aren't comparable. Hence I don't see a need to prohibit sending packets with the CoA as the source. > It is as dangerous and unscalable (possibly more so) as supporting > MN movement in the unicast routing system by using host routes rather than > MIP edge tunnel redirection. I suspect there are cases when reverse tunneling is equally "dangerous and unscalable" - it all depends on the assumptions. So either we allow both ways (and provide future documentation with guidance on the issues and tradeoffs between them) or we forbit both. There are similar issues for the joining of multicast groups. If it is done using the local interface (the "CoA") then the multicast tree will change as the MN moves, which is bad. If it is done over the reverse tunnel (the "HoA") then the multicast packets will be tunneled from the HA even though copies of the same multicast packets might already be present on the visited link. Also in that case I think both approaches make sense under different cicumstances. Erik **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 01:54:55 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13242 for ; Wed, 17 Jul 2002 01:54:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26716; Tue, 16 Jul 2002 22:53:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21233; Tue, 16 Jul 2002 22:53:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5qMoN001569 for ; Tue, 16 Jul 2002 22:52:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H5qM2j001568 for mobile-ip-dist; Tue, 16 Jul 2002 22:52:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5qJoN001561 for ; Tue, 16 Jul 2002 22:52:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25456 for ; Tue, 16 Jul 2002 22:52:21 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09714 for ; Tue, 16 Jul 2002 23:52:20 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 68A196A907; Wed, 17 Jul 2002 08:52:14 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 169B26A905; Wed, 17 Jul 2002 08:52:01 +0300 (EEST) Message-ID: <3D35066C.4060900@piuha.net> Date: Wed, 17 Jul 2002 08:53:48 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipsec@lists.tislabs.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Re: IPsec and Mobile IPv6 References: <200207082320.g68NKZGF039788@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=GAPPY_TEXT version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Francis, > The second version of my draft about IPsec and Mobile IPv6 is > available (name : draft-dupont-ipsec-mipv6-01.txt). (Sorry for the crosspost -- perhaps replies can go to the mobile ip list only.) Your draft looks like a very useful analysis of various cases regarding mobility and IPsec. But I still lack some practical background information so that this work could be taken in account in the relevant protocol descriptions. In particular, could you classify your recommendations as 1) Those that restate something which already is in the current protocol specifications (but perhaps not stated clearly enough). 2) Those which fix something that would break MIPv6 security. Draft draft-ietf-mobileip-ipv6-18.txt uses IPsec for a part of its security, namely for the HA - MN signaling. A more detailed description including SPD entries can be found from http://www.piuha.net/~jarkko/publications/mipv6/ipsec_usage.txt 3) Those which fix something that would break IPsec when used for protecting regular payload traffic in the presense of MIPv6. 4) Those that make IPsec work smoother, more efficiently, or with less configuration when used together with mobility or for the protection of mobility signaling. 5) Architectural long-term recommendations. 6) Something completely different. In particular class 2 is interesting for completing the MIPv6 work, as is class 3. From my initial understanding, your recommendations can be classified as follows: 1) A, C1, C2, E1, E2, E3, G, H, I, K, M, O, Q 2) P [makes use of IKE for HA-MN security hard -- this is very interesting, thanks!] 3) nothing? 4) B, F [and I think we were disagreeing on the mip list whether these two are good goals], L1, L2, R 5) nothing? 6) D [of course!], J unclear: N Is this correct? How do we go about fixing P, is your recommendation the only way to handle that? Is there anything in the MIPv6 documents that you'd like to clarify in class 1? Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 05:07:29 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10587 for ; Wed, 17 Jul 2002 05:07:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06249; Wed, 17 Jul 2002 02:05:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26459; Wed, 17 Jul 2002 02:05:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H94roN002195 for ; Wed, 17 Jul 2002 02:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H94raG002194 for mobile-ip-dist; Wed, 17 Jul 2002 02:04:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H94noN002187 for ; Wed, 17 Jul 2002 02:04:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21781 for ; Wed, 17 Jul 2002 02:04:51 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24552 for ; Wed, 17 Jul 2002 03:04:50 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6H94irU008024; Wed, 17 Jul 2002 11:04:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0PDX5>; Wed, 17 Jul 2002 11:04:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0861@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Alan O'Neill" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Beyond draft 18 Date: Wed, 17 Jul 2002 11:04:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I suppose LMM will help with that issue. Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, July 16, 2002 1:04 PM > To: Alan O'Neill; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Beyond draft 18 > > > Alan, > > Performance of RO was a key issue in last night's BAR BOF. > A draft with your > views would be helpful. > > jak > > ----- Original Message ----- > From: "Alan O'Neill" > To: > Sent: Tuesday, July 16, 2002 2:32 AM > Subject: [mobile-ip] Beyond draft 18 > > > > I have a few concerns about some features in draft 18 > when applied in > > specific future deployment scenarios (ie not protocol > problems for now but I > > guess applicability issues). > > > > Specifically they relate to the applicability of the > existing RO mechanisms > > during rapid movement that may be possible in future > cellular networks with > > small cells (eg a Manhatten deployment). In contrast the > existing mechanisms > > seem ok for 3GPPx and 802.11 clusters where movement is > less rapid due to > > the existance of radio specific hand-off protocols such > as RNC relocation > > and IAPP etc. > > > > I have discussed these issues with the chairs and they > have recommended I > > write up a detailed draft because of the complexities and > subtleties > > involved. I agree with the chairs that these may have to > be post base spec > > given the significant investment to date. However, I hope > the draft will > > motivate future additional RO design work in this space > and may even attempt > > to indicate specific requirements and solution options so > we can avoid any > > major barriers to this in the base spec. I guess any near > term design work > > might fit in with some of the stuff coming from last > nights BAR BOF.. > > > > If people have similar concerns then by all means contact me > > privately..although it might be worth waiting for the > draft for obvious > > reasons.. > > > > Alan. > > > > > > > > > > > ************************************************************ > **************** > > ************************************ > > This email may contain confidential and privileged > material for the sole use > > of the > > intended recipient. Any review or distribution by others > is strictly > > prohibited. > > If you are not the intended recipient please contact the > sender and delete > > all copies. > > > ************************************************************ > **************** > > ************************************* > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 06:41:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11946 for ; Wed, 17 Jul 2002 06:41:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12387; Wed, 17 Jul 2002 04:41:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14878; Wed, 17 Jul 2002 03:41:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HAecoN002514 for ; Wed, 17 Jul 2002 03:40:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HAecEF002513 for mobile-ip-dist; Wed, 17 Jul 2002 03:40:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HAeYoN002506 for ; Wed, 17 Jul 2002 03:40:34 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6HAeSg22260; Wed, 17 Jul 2002 12:40:28 +0200 (MEST) Date: Wed, 17 Jul 2002 12:38:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Issue 63: Multicast To: "Alan O'Neill" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <8C92E23A3E87FB479988285F9E22BE46C37459@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > However, it is not clear at the moment whether foreign network multicast > should ultimately use the the CoA or the HoA as the source address, so we > should do that work before giving the MN the option of origination into the > foreign system because of forwards compatibility. The current archiecture requires that the CoA is used as a source when sending multicast packets on the foreign link and the HoA when reverse tunneling them through the HA. An example of this architecture is this statement in draft-ietf-ipv6-default-addr-select: For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. (And, as an aside, the precense of ingress filtering routers apply the same restriction to unicast packets from mobile nodes that are away from home). Perhaps there are possible future architectures that do not have these constraints, and perhaps it makes sense exploring them to provide different performance for multicast for MNs. But I suspect this would result in added total complexity to the system. The point is that the draft is about the current architecture. > I don't understand how a potential thrashing problem can be allowed to > progress through the base spec. Maybe you don't believe this exists, or is > that you believe we can trust vendors and operators to do the right thing ? I don't understand why mobility creates a unique problem here. IP traffic is known to be bursty, thus the multicast routing system needs to be able to deal with bursty sources on widely varying time scales. A mobile node moving around and using the CoA as the source just looks like multiple (bursty) sources that are not moving. > Clarifying this would help...Maybe this could alternatively be addressed > with some applicability words that specifically does not rule out hybrid or > otheruses of the HoA as a foreign multicast source address ? Using the HoA as source on the visited link doesn't work due to RPF checks in the current archiecture as you already pointed out. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 07:45:24 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13295 for ; Wed, 17 Jul 2002 07:45:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07312; Wed, 17 Jul 2002 04:40:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22746; Wed, 17 Jul 2002 04:40:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBdboN002784 for ; Wed, 17 Jul 2002 04:39:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HBdbbs002783 for mobile-ip-dist; Wed, 17 Jul 2002 04:39:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBdYoN002776 for ; Wed, 17 Jul 2002 04:39:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27590 for ; Wed, 17 Jul 2002 04:39:35 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10605 for ; Wed, 17 Jul 2002 04:39:35 -0700 (PDT) Message-ID: <002501c22d86$631344f0$256015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Alan O'Neill" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0861@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Beyond draft 18 Date: Wed, 17 Jul 2002 04:37:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I suppose LMM will help with that issue. > LMM will definitely help. It will also help with address privacy, on which I believe the EU has recently passed a resolution. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 10:02:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16913 for ; Wed, 17 Jul 2002 10:02:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02608; Wed, 17 Jul 2002 08:02:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16067; Wed, 17 Jul 2002 07:02:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE1EoN003246 for ; Wed, 17 Jul 2002 07:01:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HE1EeP003245 for mobile-ip-dist; Wed, 17 Jul 2002 07:01:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE15oN003230; Wed, 17 Jul 2002 07:01:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00402; Wed, 17 Jul 2002 07:01:06 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12798; Wed, 17 Jul 2002 07:01:05 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C4A734B22; Wed, 17 Jul 2002 23:01:00 +0900 (JST) To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: keiichi's message of Tue, 16 Jul 2002 01:41:44 +0900. <20020716.014144.119249637.keiichi@iij.ad.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Wed, 17 Jul 2002 23:01:00 +0900 Message-Id: <20020717140100.C4A734B22@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >I'm sorry to raise this topic so many times, I still don't understand >the reason. > >The current mip6 (draft-18) says that all IPv6 nodes: > >- MUST be able to validate a HAO >- MUST be able to send a Binding Error message > >I think I understand the benefit of the above requirements. If an >IPv6 node supports the above requirements, a mobile node can >communicate with the IPv6 node using a triangular routing if HAO is >protected by the IPsec. > >But, even if there is no such requirement, a mobile node can >communicate with all IPv6 nodes in the world using bi-directional >tunneling. This requires nothing to all existing and future IPv6 >nodes. as you may have heard during IETF54 IESG plenary panel session, i would like to see the above "MUST" removed. there are large amount of IPv6 install base, which supports no HAO, or old definition of HAO. for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. suspect they have no HAO support. we have no way to force upgrade for all users of the existing IPv6 stacks. therefore, i believe it very important for mobile-ip6 to be defined so that: - mobile-ip6 MN is interoperable with CN without HAO support, nor binding error message support - do not require any changes to existing implementations - do not make them "non-conformant" i would really like to see the change included in draft 19. thanks. itojun From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 10:08:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17139 for ; Wed, 17 Jul 2002 10:08:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08452; Wed, 17 Jul 2002 08:08:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17482; Wed, 17 Jul 2002 07:08:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE85oN003406 for ; Wed, 17 Jul 2002 07:08:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HE8596003405 for mobile-ip-dist; Wed, 17 Jul 2002 07:08:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE81oN003398 for ; Wed, 17 Jul 2002 07:08:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17263 for ; Wed, 17 Jul 2002 07:08:02 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16342 for ; Wed, 17 Jul 2002 07:08:02 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id B49F61042 for ; Wed, 17 Jul 2002 09:08:01 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id ACE24DA7 for ; Wed, 17 Jul 2002 10:07:59 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0001903243; Wed, 17 Jul 2002 10:07:59 -0400 (EDT) Message-ID: <3D357A3F.62604344@hp.com> Date: Wed, 17 Jul 2002 10:07:59 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: Re: [mobile-ip] draft 18 comments References: <3D334824.906BE97C@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > And what do we do if the length isn't even enough to cover the type > or checksum fields? > > 4. The "Header Len" field MUST meet the minimum length requirements > of a Mobility Header (which unfortunately doesn't end on an 8-octet > boundary), which is one (1)? I.E. if "Header Len" is zero what > do we do, ICMP message? I was a little in error here, each section (9.3.1, 9.3.2, etc.) has a length check rule, but the HoTI/CoTI sections (9.3.1/9.3.2) don't say what to do with the packet if the length is incorrect. Text like this should be place in those sections: Any HoTI/CoTI which fails to satisfy all of these tests MUST be silently ignored, and the packet carrying the HoTI/CoTI MUST be discarded. -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 10:10:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17181 for ; Wed, 17 Jul 2002 10:10:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10080; Wed, 17 Jul 2002 08:10:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18633; Wed, 17 Jul 2002 07:10:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE9HoN003437 for ; Wed, 17 Jul 2002 07:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HE9HLM003436 for mobile-ip-dist; Wed, 17 Jul 2002 07:09:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE97oN003421; Wed, 17 Jul 2002 07:09:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17524; Wed, 17 Jul 2002 07:09:08 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09527; Wed, 17 Jul 2002 08:09:07 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HE92rV024298; Wed, 17 Jul 2002 16:09:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0S3AG>; Wed, 17 Jul 2002 16:09:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" , Keiichi SHIMA / ??? Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 16:08:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > we have no way to force upgrade for all users of the > existing IPv6 > stacks. therefore, i believe it very important for > mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO > support, nor > binding error message support => Technically, removing the must on the HAO is not a problem. In fact, regardless of deployed base, keeping a must for the HAO makes no sense IMHO. As for the BE message, I guess we need to make sure that somehow the CN tells the MN that no binding exists. Not sure what can be done about this. > - do not make them "non-conformant" => Well, the IETF doesn't make anyone non-conformant as far as I know. Hesham > > i would really like to see the change included in draft > 19. thanks. > > itojun > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 11:29:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19179 for ; Wed, 17 Jul 2002 11:29:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24133; Wed, 17 Jul 2002 09:29:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06837; Wed, 17 Jul 2002 08:29:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFSFoN003817 for ; Wed, 17 Jul 2002 08:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HFSFIX003816 for mobile-ip-dist; Wed, 17 Jul 2002 08:28:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFSBoN003809 for ; Wed, 17 Jul 2002 08:28:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25710 for ; Wed, 17 Jul 2002 08:28:12 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29677 for ; Wed, 17 Jul 2002 09:28:12 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 6C37B2695 for ; Wed, 17 Jul 2002 10:28:11 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 9F3C3F6A for ; Wed, 17 Jul 2002 08:28:10 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0001106084; Wed, 17 Jul 2002 11:28:10 -0400 (EDT) Message-ID: <3D358D09.B79D4114@hp.com> Date: Wed, 17 Jul 2002 11:28:09 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: Re: [mobile-ip] draft 18 comments References: <3D334824.906BE97C@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > 9.2.1. Processing Mobility Header (MH) Messages > > 2. The "Payload Proto" field MUST be NO_NXTHDR (59 decimal). And to follow myself up once again, this protocol constant is usually referred to as IPPROTO_NONE. This should be changed in Section 6.1.1 as well. -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 11:36:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19431 for ; Wed, 17 Jul 2002 11:36:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29268; Wed, 17 Jul 2002 08:35:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28573; Wed, 17 Jul 2002 08:35:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFYRoN003994 for ; Wed, 17 Jul 2002 08:34:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HFYRGw003993 for mobile-ip-dist; Wed, 17 Jul 2002 08:34:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFYIoN003978; Wed, 17 Jul 2002 08:34:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28104; Wed, 17 Jul 2002 08:34:20 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27679; Wed, 17 Jul 2002 09:34:19 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g6HFVft12848; Wed, 17 Jul 2002 11:31:42 -0400 (EDT) Message-Id: <200207171531.g6HFVft12848@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: (Your message of "Wed, 17 Jul 2002 23:01:00 +0900.") <20020717140100.C4A734B22@coconut.itojun.org> Date: Wed, 17 Jul 2002 11:31:41 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > as you may have heard during IETF54 IESG plenary panel session, > i would like to see the above "MUST" removed. there are large amount > of IPv6 install base, which supports no HAO, or old definition of HAO. > for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. > MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. > suspect they have no HAO support. the purpose of a standard is to describe what is necessary for interoperability and proper functioning of the protocol, not to legitimize existing implementations. so the installed base shouldn't dictate whether a feature is a MUST in a new version of a standard unless interoperability with the installed base is important (it generally is) and imposing the MUST condition on implementations that conform with the new version of the standard affects interoperability with the installed base. Keith From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 12:09:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20247 for ; Wed, 17 Jul 2002 12:09:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21763; Wed, 17 Jul 2002 10:09:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11596; Wed, 17 Jul 2002 09:09:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HG8DoN004276 for ; Wed, 17 Jul 2002 09:08:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HG8Cs2004275 for mobile-ip-dist; Wed, 17 Jul 2002 09:08:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HG84oN004260; Wed, 17 Jul 2002 09:08:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10996; Wed, 17 Jul 2002 09:08:06 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20589; Wed, 17 Jul 2002 10:08:05 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HG7trU019219; Wed, 17 Jul 2002 18:07:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0TPXM>; Wed, 17 Jul 2002 18:07:55 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0876@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" , itojun@iijlab.net Cc: Keiichi SHIMA / ??? , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 18:07:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > as you may have heard during IETF54 IESG plenary panel session, > > i would like to see the above "MUST" removed. there > are large amount > > of IPv6 install base, which supports no HAO, or old > definition of HAO. > > for instance, FreeBSD beyond 4.0 has IPv6 but no > support for HAO. > > MacOS 10.2, JunOS and ExtremeWare do not have HAO > support either. > > suspect they have no HAO support. > > the purpose of a standard is to describe what is necessary > for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate > whether a feature > is a MUST in a new version of a standard unless > interoperability with the > installed base is important (it generally is) and imposing > the MUST condition > on implementations that conform with the new version of the > standard affects > interoperability with the installed base. => I agree, but as I said earlier, technically removing the must on the HAO makes sense, according to the meaning of the keywords. The BE message is a bit difficult to remove though. I hope than when we discuss this tomorrow we make some distinction between the 2 functions. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 12:52:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23154 for ; Wed, 17 Jul 2002 12:52:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15930; Wed, 17 Jul 2002 10:52:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28299; Wed, 17 Jul 2002 09:52:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HGppoN004488 for ; Wed, 17 Jul 2002 09:51:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HGpo5X004487 for mobile-ip-dist; Wed, 17 Jul 2002 09:51:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HGploN004480 for ; Wed, 17 Jul 2002 09:51:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03430 for ; Wed, 17 Jul 2002 09:51:50 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22340 for ; Wed, 17 Jul 2002 09:51:49 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HGpmrU024890 for ; Wed, 17 Jul 2002 18:51:48 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0TYDD>; Wed, 17 Jul 2002 18:51:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0879@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fast handovers - proposal for moving forward Date: Wed, 17 Jul 2002 18:51:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I didn't have enough time in the meeting to explain clearly what I meant when we discussed Phil's proposal. Since I suddenly have excellent WLAN coverage in the room, I'll try to do it now! First of all, I'm not sure that the WG is actually split. In fact, after reading all emails, I think we agree on many issues. Let me try to list them and see if I'm right. I think we agree on the following: - L2 triggers will make Fast handovers perform better. - L2 triggers are needed. - We need an access independent solution. But we disagree on the level of detail at which L2 triggers should be included in the draft, and the value of tunnel-based handover (I think). So, to make my comment clear, I wasn't not against Phil's proposal to have a separate draft for Fast Handovers in 802.11. I was only against the implicit content of such document. I think that the current draft (v5) provides an access independent framework for Fast handovers, assuming some hints from lower layers, like L2 (in the MN or the AR depending on the type of link) knows that handover is about to happen and will inform the IP layer. I believe that's about as far as the doc needs to say. However, to get this stuff deployed and make it useful, more detail is needed. But I don't think that this draft can possibly include all the details relevant to all link layers. This is where Fast Handovers over foo documents would be needed. These documents can show exactly what triggers are needed, and how to integrate FMIPv6 signalling at the right time. Frankly, even if the current draft shows some names for L2 triggers, I don't think it would be useful. We need more detail for each link layer. So, to this extent, I think that an FMIPv6 over 802.11 doc is needed. But I definitely don't think we should do a different IP layer protocol standardised for each link layer. I believe it is unnecessary, let alone defeats the purpose of doing any fast handover scheme on the IP layer. Does this make sense to anyone ? I wish we had a show of hands during the meeting but there was no time to discuss it, because I don't think the WG is very divided on this actually. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 13:11:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23675 for ; Wed, 17 Jul 2002 13:11:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27690; Wed, 17 Jul 2002 11:10:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05971; Wed, 17 Jul 2002 10:10:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HH9aoN004645 for ; Wed, 17 Jul 2002 10:09:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HH9a5h004644 for mobile-ip-dist; Wed, 17 Jul 2002 10:09:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HH9XoN004637 for ; Wed, 17 Jul 2002 10:09:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09498 for ; Wed, 17 Jul 2002 10:09:35 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26421 for ; Wed, 17 Jul 2002 10:09:35 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id NAA24442 for ; Wed, 17 Jul 2002 13:09:33 -0400 (EDT) From: "Subrata Goswami" To: Subject: [mobile-ip] Fast handovers with 802.11 IAPP Date: Wed, 17 Jul 2002 10:11:17 -0700 Message-ID: <004f01c22db4$f8014070$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <4DA6EA82906FD511BE2F00508BCF0538044F0879@Esealnt861.al.sw.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Experiences with 802.11 IAPP (any version) would be relevant for fast-handover issue. If someone can post a brief on the following issues it would be educative for the whole list. 1. When is the IAPP standard expected to be completed ? 2. What is being included in the standard ? 3. Is IAPP adequate for IP handovers, any limitations ? Thanks Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (EAB) Sent: Wednesday, July 17, 2002 9:52 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fast handovers - proposal for moving forward Hi, I didn't have enough time in the meeting to explain clearly what I meant when we discussed Phil's proposal. Since I suddenly have excellent WLAN coverage in the room, I'll try to do it now! First of all, I'm not sure that the WG is actually split. In fact, after reading all emails, I think we agree on many issues. Let me try to list them and see if I'm right. I think we agree on the following: - L2 triggers will make Fast handovers perform better. - L2 triggers are needed. - We need an access independent solution. But we disagree on the level of detail at which L2 triggers should be included in the draft, and the value of tunnel-based handover (I think). So, to make my comment clear, I wasn't not against Phil's proposal to have a separate draft for Fast Handovers in 802.11. I was only against the implicit content of such document. I think that the current draft (v5) provides an access independent framework for Fast handovers, assuming some hints from lower layers, like L2 (in the MN or the AR depending on the type of link) knows that handover is about to happen and will inform the IP layer. I believe that's about as far as the doc needs to say. However, to get this stuff deployed and make it useful, more detail is needed. But I don't think that this draft can possibly include all the details relevant to all link layers. This is where Fast Handovers over foo documents would be needed. These documents can show exactly what triggers are needed, and how to integrate FMIPv6 signalling at the right time. Frankly, even if the current draft shows some names for L2 triggers, I don't think it would be useful. We need more detail for each link layer. So, to this extent, I think that an FMIPv6 over 802.11 doc is needed. But I definitely don't think we should do a different IP layer protocol standardised for each link layer. I believe it is unnecessary, let alone defeats the purpose of doing any fast handover scheme on the IP layer. Does this make sense to anyone ? I wish we had a show of hands during the meeting but there was no time to discuss it, because I don't think the WG is very divided on this actually. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 13:17:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23755 for ; Wed, 17 Jul 2002 13:17:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01255; Wed, 17 Jul 2002 11:17:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13507; Wed, 17 Jul 2002 10:17:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHFpoN004784 for ; Wed, 17 Jul 2002 10:15:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHFpI7004783 for mobile-ip-dist; Wed, 17 Jul 2002 10:15:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHFkoN004774; Wed, 17 Jul 2002 10:15:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12841; Wed, 17 Jul 2002 10:15:32 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02390; Wed, 17 Jul 2002 11:15:31 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id CAA15110; Thu, 18 Jul 2002 02:15:29 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id CAA23970; Thu, 18 Jul 2002 02:15:29 +0900 (JST) Date: Thu, 18 Jul 2002 02:14:04 +0900 (JST) Message-Id: <20020718.021404.03534966.keiichi@iij.ad.jp> To: hesham.soliman@era.ericsson.se Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: "Hesham Soliman (EAB)" Content-Transfer-Encoding: 7bit > > => Technically, removing the must on the HAO is not a problem. > In fact, regardless of deployed base, keeping a must for > the HAO makes no sense IMHO. > As for the BE message, I guess we need to make sure that > somehow the CN tells the MN that no binding exists. > Not sure what can be done about this. If the CN supports mip6, the CN will send a BE message when it receives a packet which has HAO and it doesn't have a BCE. If the CN doesn't support mip6, the CN will send an ICMP PRAMPROB with code 2 based on the ICMPv6 specification. When the MN receives a BE message, the MN will re-start RR procedure. When the MN receives ICMP PARAMPROB with code 2 and the pointer indicates HAO, the MN will switch to use bi-directional tunneling. Is there any other scenarios? Please correct me if the above rules are not enough to support non-mip6-aware IPv6 nodes. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 13:37:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24264 for ; Wed, 17 Jul 2002 13:37:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12376; Wed, 17 Jul 2002 11:37:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20723; Wed, 17 Jul 2002 10:37:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHaUoN005019 for ; Wed, 17 Jul 2002 10:36:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHaUHV005018 for mobile-ip-dist; Wed, 17 Jul 2002 10:36:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHaQoN005011 for ; Wed, 17 Jul 2002 10:36:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17971 for ; Wed, 17 Jul 2002 10:36:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13055 for ; Wed, 17 Jul 2002 11:36:26 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24143; Wed, 17 Jul 2002 10:36:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HHaOp29393; Wed, 17 Jul 2002 10:36:24 -0700 X-mProtect: <200207171736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiUfIs5; Wed, 17 Jul 2002 10:36:21 PDT Message-ID: <3D35AB16.5E81EFBE@iprg.nokia.com> Date: Wed, 17 Jul 2002 10:36:22 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit it is perfectly fine with me if the 'R' bit is put back in the MIPv6 spec. Vijay Francis Dupont wrote: > > In your previous mail you wrote: > > > PS: the R bit was added in I-D 08 (at my request) > > and lost in I-D 15 for an unknown reason (typo?). > > I think it was removed when Mobile Routers were considered out of > scope of the current spec. the prefix length field was also removed > from the BU at the same time for the same reason. I thought it was > the WG decision to remove all references to mobile routers in the > base MIPv6 spec. I dont remember. > > => if this is the reason it is a bad one because a MR is two different > things: > - a node which is a router too but in this context acts as a host > (cf. the so called "host function" of routers in IPv4) > - a mobile router in the NEMO termonology. > The R bit belongs to the first part so should *not* be removed as the > prefix length of second part. > > anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt > (and a separate prefix option) > > => in order to make the mobile router draft sound the R bit should be > reserved in the MN document, so there is no real argument against > to put it back into the MN document. Of course, this does *not* > applies to the prefix option. > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 13:42:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24384 for ; Wed, 17 Jul 2002 13:42:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19037; Wed, 17 Jul 2002 10:36:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17835; Wed, 17 Jul 2002 10:36:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHYmoN004981 for ; Wed, 17 Jul 2002 10:34:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHYmCv004980 for mobile-ip-dist; Wed, 17 Jul 2002 10:34:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHYioN004973; Wed, 17 Jul 2002 10:34:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20915; Wed, 17 Jul 2002 10:34:45 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14546; Wed, 17 Jul 2002 11:34:44 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id CAA15209; Thu, 18 Jul 2002 02:34:43 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id CAA25177; Thu, 18 Jul 2002 02:34:42 +0900 (JST) Date: Thu, 18 Jul 2002 02:33:18 +0900 (JST) Message-Id: <20020718.023318.42767258.keiichi@iij.ad.jp> To: hesham.soliman@era.ericsson.se Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020718.021404.03534966.keiichi@iij.ad.jp> References: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> <20020718.021404.03534966.keiichi@iij.ad.jp> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm sorry, I must describe more to complete the scenario. From: Keiichi SHIMA / $BEg7D0l(B > > => Technically, removing the must on the HAO is not a problem. > > In fact, regardless of deployed base, keeping a must for > > the HAO makes no sense IMHO. > > As for the BE message, I guess we need to make sure that > > somehow the CN tells the MN that no binding exists. > > Not sure what can be done about this. > > If the CN supports mip6, the CN will send a BE message when it > receives a packet which has HAO and it doesn't have a BCE. If the CN > doesn't support mip6, the CN will send an ICMP PRAMPROB with code 2 > based on the ICMPv6 specification. Also, if the CN doesn't support mip6 and receives MH (ex. HoTI/CoTI), the CN will send ICMP PARAMPROB with code 1 based on the ICMPv6 specification. > When the MN receives a BE message, the MN will re-start RR procedure. > When the MN receives ICMP PARAMPROB with code 2 and the pointer > indicates HAO, the MN will switch to use bi-directional tunneling. When the MN receives ICMP PARAMPROB with code 1 and the pointer indicates MH, the MN will switch to use bi-directional tunneling. > Is there any other scenarios? Please correct me if the above rules > are not enough to support non-mip6-aware IPv6 nodes. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 13:49:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24663 for ; Wed, 17 Jul 2002 13:49:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24584; Wed, 17 Jul 2002 11:49:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25032; Wed, 17 Jul 2002 10:49:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHlroN005319 for ; Wed, 17 Jul 2002 10:47:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHlrKC005318 for mobile-ip-dist; Wed, 17 Jul 2002 10:47:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHljoN005303; Wed, 17 Jul 2002 10:47:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26427; Wed, 17 Jul 2002 10:47:46 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23482; Wed, 17 Jul 2002 11:47:45 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HHlErU029698; Wed, 17 Jul 2002 19:47:14 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS04BS9>; Wed, 17 Jul 2002 19:47:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keiichi SHIMA / ???'" , "Hesham Soliman (EAB)" Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 19:47:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm sorry, I must describe more to complete the scenario. > > From: Keiichi SHIMA / $BEg7D0l(J > > > > => Technically, removing the must on the HAO is not a problem. > > > In fact, regardless of deployed base, keeping a must for > > > the HAO makes no sense IMHO. > > > As for the BE message, I guess we need to make sure that > > > somehow the CN tells the MN that no binding exists. > > > Not sure what can be done about this. > > > > If the CN supports mip6, the CN will send a BE message when it > > receives a packet which has HAO and it doesn't have a > BCE. If the CN > > doesn't support mip6, the CN will send an ICMP PRAMPROB > with code 2 > > based on the ICMPv6 specification. > Also, if the CN doesn't support mip6 and receives MH (ex. > HoTI/CoTI), > the CN will send ICMP PARAMPROB with code 1 based on the ICMPv6 > specification. > > > When the MN receives a BE message, the MN will re-start > RR procedure. > > When the MN receives ICMP PARAMPROB with code 2 and the pointer > > indicates HAO, the MN will switch to use bi-directional tunneling. > When the MN receives ICMP PARAMPROB with code 1 and the pointer > indicates MH, the MN will switch to use bi-directional tunneling. > > > Is there any other scenarios? Please correct me if the > above rules > > are not enough to support non-mip6-aware IPv6 nodes. => You're right, provided that we got the right option type value for the HAO (can't remember but it should be ok) so that the CN drops the packet if there is a HAO. For others who are not up to date on the MIPv6 spec, the HAO is only accpeted by the CN if RO is used or the packet is protected with IPsec. Otherwise reverse tunelling is used. So the norm is reverse tunnelling. That's why I don't think the HAO needs to be mandated. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 14:16:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25526 for ; Wed, 17 Jul 2002 14:16:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08464; Wed, 17 Jul 2002 12:16:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08063; Wed, 17 Jul 2002 11:16:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIF3oN005755 for ; Wed, 17 Jul 2002 11:15:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIF3pD005754 for mobile-ip-dist; Wed, 17 Jul 2002 11:15:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIF0oN005747 for ; Wed, 17 Jul 2002 11:15:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05958 for ; Wed, 17 Jul 2002 11:15:01 -0700 (PDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23536 for ; Wed, 17 Jul 2002 12:15:00 -0600 (MDT) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id CFBFE12; Wed, 17 Jul 2002 21:18:41 +0300 (EEST) Message-ID: <3D35B422.2050107@nomadiclab.com> Date: Wed, 17 Jul 2002 21:14:58 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020712 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> <3D35AB16.5E81EFBE@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit One of the reasons why the R bit was taken away was (and IMHO still is) security. As far as I understand, the RR method does not work for mobile routers, but I may be wrong. Furthermore, I haven't been following closely enough, so I don't know if the base spec IPsec method (for MN-HA security) is now clear enough so that the R bit could be put back form MN-HA BUs. But AFAIK we still cannot use it for MN-CN BUs, due to these security consideratiosn. Maybe someone who has followed more closely the recent security clarifications could add something here? --Pekka Vijay Devarapalli wrote: > it is perfectly fine with me if the 'R' bit is put back in the > MIPv6 spec. > > Vijay > > Francis Dupont wrote: > >> In your previous mail you wrote: >> >> > PS: the R bit was added in I-D 08 (at my request) >> > and lost in I-D 15 for an unknown reason (typo?). >> >> I think it was removed when Mobile Routers were considered out of >> scope of the current spec. the prefix length field was also removed >> from the BU at the same time for the same reason. I thought it was >> the WG decision to remove all references to mobile routers in the >> base MIPv6 spec. I dont remember. >> >>=> if this is the reason it is a bad one because a MR is two different >>things: >> - a node which is a router too but in this context acts as a host >> (cf. the so called "host function" of routers in IPv4) >> - a mobile router in the NEMO termonology. >>The R bit belongs to the first part so should *not* be removed as the >>prefix length of second part. >> >> anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt >> (and a separate prefix option) >> >>=> in order to make the mobile router draft sound the R bit should be >>reserved in the MN document, so there is no real argument against >>to put it back into the MN document. Of course, this does *not* >>applies to the prefix option. >> >>Regards >> >>Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 14:18:26 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25605 for ; Wed, 17 Jul 2002 14:18:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12694; Wed, 17 Jul 2002 11:12:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04734; Wed, 17 Jul 2002 11:12:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIBBoN005591 for ; Wed, 17 Jul 2002 11:11:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIBBFY005590 for mobile-ip-dist; Wed, 17 Jul 2002 11:11:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIB8oN005583 for ; Wed, 17 Jul 2002 11:11:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04063 for ; Wed, 17 Jul 2002 11:11:09 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04168 for ; Wed, 17 Jul 2002 11:11:08 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HIB5Rb015833; Wed, 17 Jul 2002 20:11:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0416Y>; Wed, 17 Jul 2002 20:11:05 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Subrata Goswami'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast handovers with 802.11 IAPP Date: Wed, 17 Jul 2002 20:11:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Ok, it's good that you started a separate thread though because this is not related to my email. Hesham > -----Original Message----- > From: Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Wednesday, July 17, 2002 7:11 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fast handovers with 802.11 IAPP > > > Experiences with 802.11 IAPP (any version) would be relevant for > fast-handover issue. If someone can post a brief on the > following issues > it would be educative for the whole list. > > 1. When is the IAPP standard expected to be completed ? > 2. What is being included in the standard ? > 3. Is IAPP adequate for IP handovers, any limitations ? > > Thanks > > Subrata > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of > Hesham Soliman > (EAB) > Sent: Wednesday, July 17, 2002 9:52 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fast handovers - proposal for moving forward > > Hi, > > I didn't have enough time in the meeting to explain > clearly what I meant when we discussed Phil's proposal. > Since I suddenly have excellent WLAN coverage in the > room, I'll try to do it now! > > First of all, I'm not sure that the WG is actually > split. In fact, after reading all emails, I think we > agree on many issues. Let me try to list them and > see if I'm right. I think we agree on the following: > > - L2 triggers will make Fast handovers perform better. > - L2 triggers are needed. > - We need an access independent solution. > > But we disagree on the level of detail at which L2 triggers > should be included in the draft, and the value of tunnel-based > handover (I think). > > So, to make my comment clear, I wasn't not against > Phil's proposal to have a separate draft for Fast > Handovers in 802.11. I was only against the implicit > content of such document. > > I think that the current draft (v5) provides an > access independent framework for Fast handovers, > assuming some hints from lower layers, like > L2 (in the MN or the AR depending on the type > of link) knows that handover is about to happen > and will inform the IP layer. I believe that's > about as far as the doc needs to say. However, > to get this stuff deployed and make it useful, > more detail is needed. But I don't think that > this draft can possibly include all the details > relevant to all link layers. This is where Fast > Handovers over foo documents would be needed. > > These documents can show exactly what triggers > are needed, and how to integrate FMIPv6 signalling > at the right time. Frankly, even if the current > draft shows some names for L2 triggers, I don't > think it would be useful. We need more detail > for each link layer. > > So, to this extent, I think that an FMIPv6 over > 802.11 doc is needed. But I definitely don't think we should > do a different IP layer protocol standardised for each link > layer. I believe it is unnecessary, let alone > defeats the purpose of doing any fast handover scheme > on the IP layer. > > Does this make sense to anyone ? > I wish we had a show of hands during the meeting but > there was no time to discuss it, because I don't think > the WG is very divided on this actually. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 14:34:00 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26149 for ; Wed, 17 Jul 2002 14:34:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16865; Wed, 17 Jul 2002 11:32:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13381; Wed, 17 Jul 2002 11:32:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIVXoN006040 for ; Wed, 17 Jul 2002 11:31:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIVXtL006039 for mobile-ip-dist; Wed, 17 Jul 2002 11:31:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIVToN006032 for ; Wed, 17 Jul 2002 11:31:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11984 for ; Wed, 17 Jul 2002 11:31:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01601 for ; Wed, 17 Jul 2002 12:31:29 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28081; Wed, 17 Jul 2002 11:31:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HIVSb02279; Wed, 17 Jul 2002 11:31:28 -0700 X-mProtect: <200207171831> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5gKfhp; Wed, 17 Jul 2002 11:31:26 PDT Message-ID: <3D35B7FE.62C3F601@iprg.nokia.com> Date: Wed, 17 Jul 2002 11:31:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: Francis Dupont , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> <3D35AB16.5E81EFBE@iprg.nokia.com> <3D35B422.2050107@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Pekka, RR came much later. the 'R' bit was not there in draft 15. Vijay Pekka Nikander wrote: > > One of the reasons why the R bit was taken away was > (and IMHO still is) security. As far as I understand, the > RR method does not work for mobile routers, but I may > be wrong. Furthermore, I haven't been following closely > enough, so I don't know if the base spec IPsec method > (for MN-HA security) is now clear enough so that the > R bit could be put back form MN-HA BUs. But AFAIK we still > cannot use it for MN-CN BUs, due to these security > consideratiosn. > > Maybe someone who has followed more closely the recent > security clarifications could add something here? > > --Pekka > > Vijay Devarapalli wrote: > > it is perfectly fine with me if the 'R' bit is put back in the > > MIPv6 spec. > > > > Vijay > > > > Francis Dupont wrote: > > > >> In your previous mail you wrote: > >> > >> > PS: the R bit was added in I-D 08 (at my request) > >> > and lost in I-D 15 for an unknown reason (typo?). > >> > >> I think it was removed when Mobile Routers were considered out of > >> scope of the current spec. the prefix length field was also removed > >> from the BU at the same time for the same reason. I thought it was > >> the WG decision to remove all references to mobile routers in the > >> base MIPv6 spec. I dont remember. > >> > >>=> if this is the reason it is a bad one because a MR is two different > >>things: > >> - a node which is a router too but in this context acts as a host > >> (cf. the so called "host function" of routers in IPv4) > >> - a mobile router in the NEMO termonology. > >>The R bit belongs to the first part so should *not* be removed as the > >>prefix length of second part. > >> > >> anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt > >> (and a separate prefix option) > >> > >>=> in order to make the mobile router draft sound the R bit should be > >>reserved in the MN document, so there is no real argument against > >>to put it back into the MN document. Of course, this does *not* > >>applies to the prefix option. > >> > >>Regards > >> > >>Francis.Dupont@enst-bretagne.fr > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 14:54:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26953 for ; Wed, 17 Jul 2002 14:54:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27412; Wed, 17 Jul 2002 12:54:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23174; Wed, 17 Jul 2002 11:54:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIrQoN006365 for ; Wed, 17 Jul 2002 11:53:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIrQFc006364 for mobile-ip-dist; Wed, 17 Jul 2002 11:53:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIrNoN006357 for ; Wed, 17 Jul 2002 11:53:23 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20019 for ; Wed, 17 Jul 2002 11:53:24 -0700 (PDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28462 for ; Wed, 17 Jul 2002 11:53:24 -0700 (PDT) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id B9C8212; Wed, 17 Jul 2002 21:57:00 +0300 (EEST) Message-ID: <3D35BD1C.7070603@nomadiclab.com> Date: Wed, 17 Jul 2002 21:53:16 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020712 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> <3D35AB16.5E81EFBE@iprg.nokia.com> <3D35B422.2050107@nomadiclab.com> <3D35B7FE.62C3F601@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, I stand corrected. However, that fact doesn't change the issue that RR does not work for mobile routers. And that AFAIK nobody has suggested how it could be extended, even. Maybe I was confusing the issue with removing the routing prefix, there I think the security issues were a part of the story. Or maybe not. --Pekka Vijay Devarapalli wrote: > hi Pekka, > > RR came much later. the 'R' bit was not there in draft 15. > > Vijay > > Pekka Nikander wrote: > >>One of the reasons why the R bit was taken away was >>(and IMHO still is) security. As far as I understand, the >>RR method does not work for mobile routers, but I may >>be wrong. Furthermore, I haven't been following closely >>enough, so I don't know if the base spec IPsec method >>(for MN-HA security) is now clear enough so that the >>R bit could be put back form MN-HA BUs. But AFAIK we still >>cannot use it for MN-CN BUs, due to these security >>consideratiosn. >> >>Maybe someone who has followed more closely the recent >>security clarifications could add something here? >> >>--Pekka >> >>Vijay Devarapalli wrote: >> >>>it is perfectly fine with me if the 'R' bit is put back in the >>>MIPv6 spec. >>> >>>Vijay >>> >>>Francis Dupont wrote: >>> >>> >>>>In your previous mail you wrote: >>>> >>>> > PS: the R bit was added in I-D 08 (at my request) >>>> > and lost in I-D 15 for an unknown reason (typo?). >>>> >>>> I think it was removed when Mobile Routers were considered out of >>>> scope of the current spec. the prefix length field was also removed >>>> from the BU at the same time for the same reason. I thought it was >>>> the WG decision to remove all references to mobile routers in the >>>> base MIPv6 spec. I dont remember. >>>> >>>>=> if this is the reason it is a bad one because a MR is two different >>>>things: >>>>- a node which is a router too but in this context acts as a host >>>> (cf. the so called "host function" of routers in IPv4) >>>>- a mobile router in the NEMO termonology. >>>>The R bit belongs to the first part so should *not* be removed as the >>>>prefix length of second part. >>>> >>>> anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt >>>> (and a separate prefix option) >>>> >>>>=> in order to make the mobile router draft sound the R bit should be >>>>reserved in the MN document, so there is no real argument against >>>>to put it back into the MN document. Of course, this does *not* >>>>applies to the prefix option. >>>> >>>>Regards >>>> >>>>Francis.Dupont@enst-bretagne.fr >>> From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 15:01:32 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27306 for ; Wed, 17 Jul 2002 15:01:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08834; Wed, 17 Jul 2002 11:55:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20873; Wed, 17 Jul 2002 11:55:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIruoN006378 for ; Wed, 17 Jul 2002 11:53:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIrugv006377 for mobile-ip-dist; Wed, 17 Jul 2002 11:53:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIrqoN006370; Wed, 17 Jul 2002 11:53:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22972; Wed, 17 Jul 2002 11:53:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04794; Wed, 17 Jul 2002 12:53:53 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29658; Wed, 17 Jul 2002 11:53:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HIrpC09380; Wed, 17 Jul 2002 11:53:51 -0700 X-mProtect: <200207171853> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk6Ad8c; Wed, 17 Jul 2002 11:53:48 PDT Message-ID: <3D35BD3D.A47B2E09@iprg.nokia.com> Date: Wed, 17 Jul 2002 11:53:49 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717140100.C4A734B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Itojun, itojun@iijlab.net wrote: > as you may have heard during IETF54 IESG plenary panel session, > i would like to see the above "MUST" removed. there are large amount > of IPv6 install base, which supports no HAO, or old definition of HAO. > for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. > MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. > suspect they have no HAO support. > > we have no way to force upgrade for all users of the existing IPv6 > stacks. therefore, i believe it very important for mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO support, nor > binding error message support it is. if a CN does not support HAO, it will send an ICMP error message pointing to the offending octet. when the MN receives this message, it starts reverse-tunneling through the Home Agent. where is the problem? if this is not clearly specified in the MIPv6 draft, it can be. the binding error functionality can also be substituted by an ICMP error. Binding Error was specified so that it is easier for the MN to figure out whats going on. > - do not require any changes to existing implementations we dont have to. > - do not make them "non-conformant" everytime a new standard comes out, there is something new in it. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 15:03:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27409 for ; Wed, 17 Jul 2002 15:03:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07662; Wed, 17 Jul 2002 13:04:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27251; Wed, 17 Jul 2002 12:04:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HJ3CoN006700 for ; Wed, 17 Jul 2002 12:03:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HJ3BkT006699 for mobile-ip-dist; Wed, 17 Jul 2002 12:03:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HJ38oN006692 for ; Wed, 17 Jul 2002 12:03:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24254 for ; Wed, 17 Jul 2002 12:03:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07014 for ; Wed, 17 Jul 2002 13:03:09 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00124; Wed, 17 Jul 2002 12:03:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HJ38k25385; Wed, 17 Jul 2002 12:03:08 -0700 X-mProtect: <200207171903> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl26M4Z; Wed, 17 Jul 2002 12:03:05 PDT Message-ID: <3D35BF6A.81CEB6E5@iprg.nokia.com> Date: Wed, 17 Jul 2002 12:03:06 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207170229.g6H2ThGF067319@givry.rennes.enst-bretagne.fr> <3D35AB16.5E81EFBE@iprg.nokia.com> <3D35B422.2050107@nomadiclab.com> <3D35B7FE.62C3F601@iprg.nokia.com> <3D35BD1C.7070603@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > Vijay, > > I stand corrected. However, that fact doesn't change the > issue that RR does not work for mobile routers. And that > AFAIK nobody has suggested how it could be extended, even. thats true. I guess the NEMO BOF/WG would be investigating that. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 15:51:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28482 for ; Wed, 17 Jul 2002 15:51:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03457; Wed, 17 Jul 2002 13:49:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13453; Wed, 17 Jul 2002 12:49:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HJluoN006913 for ; Wed, 17 Jul 2002 12:47:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HJluqn006912 for mobile-ip-dist; Wed, 17 Jul 2002 12:47:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HJlroN006905 for ; Wed, 17 Jul 2002 12:47:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08059 for ; Wed, 17 Jul 2002 12:47:51 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05830 for ; Wed, 17 Jul 2002 13:47:49 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HJliRb020511; Wed, 17 Jul 2002 21:47:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS04SP5>; Wed, 17 Jul 2002 21:47:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Nikander'" , Vijay Devarapalli Cc: Francis Dupont , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] R (router) bit in BUs Date: Wed, 17 Jul 2002 21:47:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I stand corrected. However, that fact doesn't change the > issue that RR does not work for mobile routers. And that > AFAIK nobody has suggested how it could be extended, even. => That's correct of course. But this discussion is only related to the BU sent to the HA. The R bit is not used to route packets for a prefix, but merely for ND reasons as per Francis' email. So, it should never be set in a BU to a CN. Hesham > > Maybe I was confusing the issue with removing the routing > prefix, there I think the security issues were a part of > the story. Or maybe not. > > --Pekka > > Vijay Devarapalli wrote: > > hi Pekka, > > > > RR came much later. the 'R' bit was not there in draft 15. > > > > Vijay > > > > Pekka Nikander wrote: > > > >>One of the reasons why the R bit was taken away was > >>(and IMHO still is) security. As far as I understand, the > >>RR method does not work for mobile routers, but I may > >>be wrong. Furthermore, I haven't been following closely > >>enough, so I don't know if the base spec IPsec method > >>(for MN-HA security) is now clear enough so that the > >>R bit could be put back form MN-HA BUs. But AFAIK we still > >>cannot use it for MN-CN BUs, due to these security > >>consideratiosn. > >> > >>Maybe someone who has followed more closely the recent > >>security clarifications could add something here? > >> > >>--Pekka > >> > >>Vijay Devarapalli wrote: > >> > >>>it is perfectly fine with me if the 'R' bit is put back in the > >>>MIPv6 spec. > >>> > >>>Vijay > >>> > >>>Francis Dupont wrote: > >>> > >>> > >>>>In your previous mail you wrote: > >>>> > >>>> > PS: the R bit was added in I-D 08 (at my request) > >>>> > and lost in I-D 15 for an unknown reason (typo?). > >>>> > >>>> I think it was removed when Mobile Routers were > considered out of > >>>> scope of the current spec. the prefix length field > was also removed > >>>> from the BU at the same time for the same reason. I > thought it was > >>>> the WG decision to remove all references to mobile > routers in the > >>>> base MIPv6 spec. I dont remember. > >>>> > >>>>=> if this is the reason it is a bad one because a MR > is two different > >>>>things: > >>>>- a node which is a router too but in this context acts > as a host > >>>> (cf. the so called "host function" of routers in IPv4) > >>>>- a mobile router in the NEMO termonology. > >>>>The R bit belongs to the first part so should *not* be > removed as the > >>>>prefix length of second part. > >>>> > >>>> anyway we have defined the 'R' bit in > draft-kniveton-mobrtr-02.txt > >>>> (and a separate prefix option) > >>>> > >>>>=> in order to make the mobile router draft sound the R > bit should be > >>>>reserved in the MN document, so there is no real > argument against > >>>>to put it back into the MN document. Of course, this does *not* > >>>>applies to the prefix option. > >>>> > >>>>Regards > >>>> > >>>>Francis.Dupont@enst-bretagne.fr > >>> > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:22:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00133 for ; Wed, 17 Jul 2002 17:22:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15204; Wed, 17 Jul 2002 15:22:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24122; Wed, 17 Jul 2002 14:22:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLLPoN007180 for ; Wed, 17 Jul 2002 14:21:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLLPR9007179 for mobile-ip-dist; Wed, 17 Jul 2002 14:21:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLLGoN007164; Wed, 17 Jul 2002 14:21:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11706; Wed, 17 Jul 2002 14:21:17 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14058; Wed, 17 Jul 2002 15:21:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4853C4B22; Thu, 18 Jul 2002 06:21:10 +0900 (JST) To: Vijay Devarapalli Cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 11:53:49 MST. <3D35BD3D.A47B2E09@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 06:21:10 +0900 Message-Id: <20020717212110.4853C4B22@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >it is. if a CN does not support HAO, it will send an ICMP error message >pointing to the offending octet. when the MN receives this message, it >starts reverse-tunneling through the Home Agent. where is the problem? >if this is not clearly specified in the MIPv6 draft, it can be. the >binding error functionality can also be substituted by an ICMP error. >Binding Error was specified so that it is easier for the MN to figure >out whats going on. then I see no reason for the MUST. itojun From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:34:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00389 for ; Wed, 17 Jul 2002 17:34:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03470; Wed, 17 Jul 2002 15:34:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29026; Wed, 17 Jul 2002 14:34:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLXRoN007384 for ; Wed, 17 Jul 2002 14:33:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLXRv8007383 for mobile-ip-dist; Wed, 17 Jul 2002 14:33:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLXNoN007376; Wed, 17 Jul 2002 14:33:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17162; Wed, 17 Jul 2002 14:33:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02544; Wed, 17 Jul 2002 15:33:24 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA09219; Wed, 17 Jul 2002 14:33:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HLXM832063; Wed, 17 Jul 2002 14:33:22 -0700 X-mProtect: <200207172133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6Nu3Zt; Wed, 17 Jul 2002 14:33:21 PDT Message-ID: <3D35E2A1.18E60F30@iprg.nokia.com> Date: Wed, 17 Jul 2002 14:33:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717212110.4853C4B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. I was discounting the reason (the already IPv6 installed base) you gave. the MUST is for newer IPv6 CN implementations. as I told you already, it makes the MN's life easier. but the current spec does ensure that a MN can still have a session with an old IPv6 implementation (which does not implement HAO) through reverse tunneling. so again, where is the problem? why are you against the MUST? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:38:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00475 for ; Wed, 17 Jul 2002 17:38:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26798; Wed, 17 Jul 2002 14:37:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18551; Wed, 17 Jul 2002 14:37:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLZioN007473 for ; Wed, 17 Jul 2002 14:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLZhPq007472 for mobile-ip-dist; Wed, 17 Jul 2002 14:35:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLZdoN007465; Wed, 17 Jul 2002 14:35:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17845; Wed, 17 Jul 2002 14:35:40 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22144; Wed, 17 Jul 2002 15:35:40 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6HLZOqI012562; Wed, 17 Jul 2002 14:35:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE24062; Wed, 17 Jul 2002 14:30:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01095; Wed, 17 Jul 2002 14:35:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.58139.802666.499612@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 14:35:23 -0700 (PDT) To: itojun@iijlab.net Cc: Vijay Devarapalli , keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020717212110.4853C4B22@coconut.itojun.org> References: <3D35BD3D.A47B2E09@iprg.nokia.com> <20020717212110.4853C4B22@coconut.itojun.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit itojun@iijlab.net writes: > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. Sez RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Given that MIPv6 will interoperate without binding code in CN's, it looks pretty much like a SHOULD to me. Indeed, the protocol would not be robust if it didn't consider the case of a non-conformant CN. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:46:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00631 for ; Wed, 17 Jul 2002 17:46:44 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10572; Wed, 17 Jul 2002 15:47:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22392; Wed, 17 Jul 2002 14:46:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLjKoN007844 for ; Wed, 17 Jul 2002 14:45:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLjKqX007843 for mobile-ip-dist; Wed, 17 Jul 2002 14:45:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLjBoN007828; Wed, 17 Jul 2002 14:45:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03034; Wed, 17 Jul 2002 14:45:13 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01210; Wed, 17 Jul 2002 14:45:12 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HLj1rU015297; Wed, 17 Jul 2002 23:45:01 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VA55>; Wed, 17 Jul 2002 23:45:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Michael Thomas'" , itojun@iijlab.net Cc: Vijay Devarapalli , keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 23:44:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > itojun@iijlab.net writes: > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > Sez RFC 2119: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be > used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit > behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a > particular method > on implementors where the method is not required for > interoperability. > > Given that MIPv6 will interoperate without binding > code in CN's, it looks pretty much like a SHOULD > to me. Indeed, the protocol would not be robust if > it didn't consider the case of a non-conformant CN. => Exactly, IMHO the support for HAO is tied to RO support which is a SHOULD anyway, so the HAO should follow that. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:52:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00745 for ; Wed, 17 Jul 2002 17:52:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19732; Wed, 17 Jul 2002 15:53:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25307; Wed, 17 Jul 2002 14:53:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLploN008228 for ; Wed, 17 Jul 2002 14:51:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLpl6r008227 for mobile-ip-dist; Wed, 17 Jul 2002 14:51:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLpgoN008215; Wed, 17 Jul 2002 14:51:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24940; Wed, 17 Jul 2002 14:51:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18913; Wed, 17 Jul 2002 15:51:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA10381; Wed, 17 Jul 2002 14:51:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HLpgL32369; Wed, 17 Jul 2002 14:51:42 -0700 X-mProtect: <200207172151> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDerkWW; Wed, 17 Jul 2002 14:51:40 PDT Message-ID: <3D35E6EC.DC779400@iprg.nokia.com> Date: Wed, 17 Jul 2002 14:51:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Michael Thomas'" , itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <4DA6EA82906FD511BE2F00508BCF0538044F087E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Hesham, "Hesham Soliman (EAB)" wrote: > => Exactly, IMHO the support for HAO is tied to > RO support which is a SHOULD anyway, so the HAO > should follow that. we have been through this before. the support for HAO is tied to the verifiability of the home address (otherwise you can have reflection attacks). there are other mechanisms apart from RO to verify a particular home address. I am not going to get into those mechanisms now. check the archives. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 17:54:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00816 for ; Wed, 17 Jul 2002 17:54:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16405; Wed, 17 Jul 2002 14:48:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29103; Wed, 17 Jul 2002 14:48:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLkloN007874 for ; Wed, 17 Jul 2002 14:46:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLkls7007873 for mobile-ip-dist; Wed, 17 Jul 2002 14:46:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLkhoN007866; Wed, 17 Jul 2002 14:46:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22299; Wed, 17 Jul 2002 14:46:44 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10198; Wed, 17 Jul 2002 15:46:43 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6HLlEi15859; Thu, 18 Jul 2002 00:47:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 00:46:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 00:46:41 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 00:46:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt2tA/FtgIzJg+RKiy5eTmymsynQAACliw To: , Cc: , , , X-OriginalArrivalTime: 17 Jul 2002 21:46:41.0543 (UTC) FILETIME=[6FBB5170:01C22DDB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6HLkhoO007867 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Michael, > > then I see no reason for the MUST. > > Sez RFC 2119: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > Given that MIPv6 will interoperate without binding > code in CN's, it looks pretty much like a SHOULD > to me. Indeed, the protocol would not be robust if > it didn't consider the case of a non-conformant CN. I think we want to ask is, is it the right thing to do? For proper protocol functioning, will this lead to the correct behavior. If we think it is important, the MUST is OK. The spec does contain a mechanism to support existing implementations of IPv6, which means the protocol designers are doing their jobs. As I see it, we should focus on the behavior & if it is the right thing to do, then we should do it. John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 18:04:10 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01005 for ; Wed, 17 Jul 2002 18:04:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22385; Wed, 17 Jul 2002 14:58:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03326; Wed, 17 Jul 2002 14:58:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLuwoN008521 for ; Wed, 17 Jul 2002 14:56:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLuwrU008520 for mobile-ip-dist; Wed, 17 Jul 2002 14:56:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLutoN008513; Wed, 17 Jul 2002 14:56:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02928; Wed, 17 Jul 2002 14:56:56 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16513; Wed, 17 Jul 2002 15:56:55 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6HLvQi17960; Thu, 18 Jul 2002 00:57:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 00:56:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 00:56:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 00:56:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578A@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt29iVRvBHTOg1RfWdr49vHQaCggAAH6Yw To: , , Cc: , , , X-OriginalArrivalTime: 17 Jul 2002 21:56:53.0835 (UTC) FILETIME=[DCAFA9B0:01C22DDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6HLutoO008514 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hesham, > => Exactly, IMHO the support for HAO is tied to > RO support which is a SHOULD anyway, so the HAO > should follow that. Logically, you are inconsistant. As an example, RO is a should, protecting RO is a MUST. This set of mail exchanges have actually made me think that this is important functionally and that implementing HAO is important for security reasons and it is not unreasonable to insist all nodes implement it. John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 18:23:15 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01286 for ; Wed, 17 Jul 2002 18:23:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18003; Wed, 17 Jul 2002 16:23:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24068; Wed, 17 Jul 2002 15:23:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMM8oN008907 for ; Wed, 17 Jul 2002 15:22:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HMM8ku008906 for mobile-ip-dist; Wed, 17 Jul 2002 15:22:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMM3oN008896; Wed, 17 Jul 2002 15:22:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23582; Wed, 17 Jul 2002 15:22:05 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17199; Wed, 17 Jul 2002 16:22:04 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6HMLhOu015722; Wed, 17 Jul 2002 15:21:43 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE25457; Wed, 17 Jul 2002 15:17:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01099; Wed, 17 Jul 2002 15:21:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.60922.686205.742010@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 15:21:46 -0700 (PDT) To: Cc: , , , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > > Given that MIPv6 will interoperate without binding > > code in CN's, it looks pretty much like a SHOULD > > to me. Indeed, the protocol would not be robust if > > it didn't consider the case of a non-conformant CN. > > I think we want to ask is, is it the right thing to do? For > proper protocol functioning, will this lead to the correct > behavior. If we think it is important, the MUST is OK. The > spec does contain a mechanism to support existing implementations > of IPv6, which means the protocol designers are doing their > jobs. I think we're straying into a "good" as in "good for the overall health of the Internet" kind of good, rather than a "good" as in will the protocol operate correctly. For the former, I think you need to have extremely compelling motivation, as well as a lot of evidence that the health of the net will be imperiled if *all* nodes don't implement a particular function, which is what is at issue here. Frankly, I don't think that there is any evidence that the net would be substantially harmed if RO wasn't widely implemented and/or enabled. Indeed, I think there's good reason to believe that many/most nodes will not enable RO even if their kernel implements it. In some cases, it's likely to be a nice and useful optimization, but I really don't see it as a "if we don't do this the net will fall apart". As such, SHOULD seems like it strikes the right balance. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 18:30:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01406 for ; Wed, 17 Jul 2002 18:30:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21554; Wed, 17 Jul 2002 16:30:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15043; Wed, 17 Jul 2002 15:30:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMTcoN009175 for ; Wed, 17 Jul 2002 15:29:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HMTcnV009174 for mobile-ip-dist; Wed, 17 Jul 2002 15:29:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMTZoN009167 for ; Wed, 17 Jul 2002 15:29:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14507 for ; Wed, 17 Jul 2002 15:29:36 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25006 for ; Wed, 17 Jul 2002 16:29:35 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA12202 for ; Wed, 17 Jul 2002 15:29:35 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA19447 for ; Wed, 17 Jul 2002 15:28:19 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 17:29:32 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 17 Jul 2002 17:27:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Alper, Please find my inline reply. regards, ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, July 16, 2002 9:29 AM To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Hi Ajoy, > Ajoy-> Target trigger will be suitable for cellular > networks. BTW, even in case of WLAN, you can receive > L2-TT trigger at nAP. L2TT (Re-association Request) can > provide nAP the L2 address of the oldAP as well as L2 > address of the mobile node. If we implement FA function Does re-association also apply to BSS mode, or when the station moves between two different ESS? If it is only used when the station moves from one AP to another in the same ESS, this is not as interesting, because the mobility is already handled at link-layer in 802.11b. Ajoy-> Mostly I have seen Re-association Request is sent whenever an MN moves from one AP to other AP in the same ESS. This is partly because IAPP handles intra-ESS handoff. I believe this is an implementation issue and can be easily extended, if Mobile/IP provides appropriate hooks. > at AP, then this becomes an implementation issue. > If not, then you need to define some protocol between > AP and AR which can be addressed in separate document. http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt ... > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does > not work for network initiated trigger. BTW, based upon our > implementation, we found anticipated handover does not provide > good performance on cellular link. Hence, anticipated handover > is not going to address fast handoff need for various cellular networks. Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation? Ajoy-> We implemented FMIPv4. But I do not believe FMIPv6 implementation will provide substantially better performance. More or less the basic idea is same. I think the part of the problem is high RTT of 3G wireless link (MN to AR). So, adding lots of signaling messages over the high RTT link will require sufficiently higher anticipation time. If you keep very high anticipation time, handover may not be consistently reliable. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 19:42:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02609 for ; Wed, 17 Jul 2002 19:42:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10680; Wed, 17 Jul 2002 16:36:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04985; Wed, 17 Jul 2002 16:36:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNZ2oN009652 for ; Wed, 17 Jul 2002 16:35:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HNZ2YG009651 for mobile-ip-dist; Wed, 17 Jul 2002 16:35:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNYvoN009637; Wed, 17 Jul 2002 16:34:57 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04452; Wed, 17 Jul 2002 16:34:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09869; Wed, 17 Jul 2002 16:34:59 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA17241; Wed, 17 Jul 2002 16:34:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HNYwp08852; Wed, 17 Jul 2002 16:34:58 -0700 X-mProtect: <200207172334> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdg0rnDz; Wed, 17 Jul 2002 16:34:56 PDT Message-ID: <3D35FF20.2E5FCADF@iprg.nokia.com> Date: Wed, 17 Jul 2002 16:34:56 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, RO is a SHOULD, it is not a MUST in the current draft. we were not talking about route optimization. we were talking about processing a HAO. in the current spec HAO MUST be processed but not accepted if it cant be verified. verification can be in the form of checking for a valid BCE (created securely), IPsec protected data session, same trusted domain (where you dont expect people to do reflection attacks), the tagging proposal from Rajeev and Charlie, smart ingress filtering from Francis Dupont, etc... processing a HAO is simply replacing the source address with the contents of the HAO. earlier it is used to be a MUST without the verification step. IPv6 WG was okay with that. but people indentified some reflection attacks that are possible if you blindly accept unverified home address option. so now, it is a MUST with the verification step. regards Vijay Michael Thomas wrote: > > john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:03:40 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03008 for ; Wed, 17 Jul 2002 20:03:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19148; Wed, 17 Jul 2002 16:56:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00829; Wed, 17 Jul 2002 16:56:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNthoN009916 for ; Wed, 17 Jul 2002 16:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HNthcQ009915 for mobile-ip-dist; Wed, 17 Jul 2002 16:55:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNteoN009908; Wed, 17 Jul 2002 16:55:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11684; Wed, 17 Jul 2002 16:55:42 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28422; Wed, 17 Jul 2002 17:55:42 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6HNtOM2010893; Wed, 17 Jul 2002 16:55:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE28060; Wed, 17 Jul 2002 16:50:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01111; Wed, 17 Jul 2002 16:55:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15670.1003.493633.920465@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 16:55:23 -0700 (PDT) To: Vijay Devarapalli Cc: Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <3D35FF20.2E5FCADF@iprg.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > RO is a SHOULD, it is not a MUST in the current draft. we were > not talking about route optimization. we were talking about > processing a HAO. in the current spec HAO MUST be processed but > not accepted if it cant be verified. verification can be in the > form of checking for a valid BCE (created securely), IPsec > protected data session, same trusted domain (where you dont > expect people to do reflection attacks), the tagging proposal > from Rajeev and Charlie, smart ingress filtering from Francis > Dupont, etc... Oh, OK. Sorry about that. Still if the code isn't in the CN, the MN should still be able to operate correctly, right? That still seems to me to be a SHOULD rather than a MUST for the same reasons in my reply to John. I guess the long and short of this is that I'm somewhat skeptical of putting general node requirements in the MIP draft since it's probably not the first place one would be looking to figure out if they were an IPv6 compliant node. If it's really, really vital for the health of the net, yadda, yadda, it would be better to put it in a general v6 node requirements RFC, don't you think? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:14:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03250 for ; Wed, 17 Jul 2002 20:14:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28618; Wed, 17 Jul 2002 18:15:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07249; Wed, 17 Jul 2002 17:15:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0DjoN010115 for ; Wed, 17 Jul 2002 17:13:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0Dj6K010114 for mobile-ip-dist; Wed, 17 Jul 2002 17:13:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0DdoN010107; Wed, 17 Jul 2002 17:13:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17062; Wed, 17 Jul 2002 17:13:41 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04612; Wed, 17 Jul 2002 18:13:40 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I0EBi24441; Thu, 18 Jul 2002 03:14:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 03:13:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 03:13:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 03:13:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt7cTWMfDr88ZlQ3iaoLJAwT95/QAAdA9A To: , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 00:13:38.0943 (UTC) FILETIME=[F74FC8F0:01C22DEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I0DeoO010108 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:16:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03342 for ; Wed, 17 Jul 2002 20:16:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14098; Wed, 17 Jul 2002 17:15:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17626; Wed, 17 Jul 2002 17:15:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0D6oN010104 for ; Wed, 17 Jul 2002 17:13:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0D5TO010103 for mobile-ip-dist; Wed, 17 Jul 2002 17:13:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0CvoN010088; Wed, 17 Jul 2002 17:12:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18862; Wed, 17 Jul 2002 17:12:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27692; Wed, 17 Jul 2002 18:12:58 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 34F404B22; Thu, 18 Jul 2002 09:12:50 +0900 (JST) To: Vijay Devarapalli Cc: Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 16:34:56 MST. <3D35FF20.2E5FCADF@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 09:12:50 +0900 Message-Id: <20020718001250.34F404B22@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >processing a HAO is simply replacing the source address with >the contents of the HAO. earlier it is used to be a MUST without >the verification step. IPv6 WG was okay with that. but people >indentified some reflection attacks that are possible if you >blindly accept unverified home address option. so now, it is a >MUST with the verification step. IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, and i think it not reasonable for you to think that new-HAO is also OKed automaticalliy. itojun From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:20:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03533 for ; Wed, 17 Jul 2002 20:20:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22330; Wed, 17 Jul 2002 18:21:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19551; Wed, 17 Jul 2002 17:21:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0JuoN010414 for ; Wed, 17 Jul 2002 17:19:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0Juqp010413 for mobile-ip-dist; Wed, 17 Jul 2002 17:19:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0JloN010395; Wed, 17 Jul 2002 17:19:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19048; Wed, 17 Jul 2002 17:19:50 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29292; Wed, 17 Jul 2002 17:19:49 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6I0JfRb002615; Thu, 18 Jul 2002 02:19:41 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VSTZ>; Thu, 18 Jul 2002 02:19:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , "Hesham Soliman (EAB)" , mat@cisco.com, itojun@iijlab.net Cc: vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 02:19:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => Exactly, IMHO the support for HAO is tied to > > RO support which is a SHOULD anyway, so the HAO > > should follow that. > > Logically, you are inconsistant. > > As an example, RO is a should, protecting RO is a MUST. => Huh? Protecting it is a must for those who support it! But supporting it is a should. Hesham > > This set of mail exchanges have actually made me think > that this is important functionally and that implementing HAO is > important for security reasons and it is not unreasonable to > insist all nodes implement it. > > John > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:31:02 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03765 for ; Wed, 17 Jul 2002 20:30:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01794; Wed, 17 Jul 2002 17:25:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22958; Wed, 17 Jul 2002 17:25:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0NkoN010546 for ; Wed, 17 Jul 2002 17:23:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0Nk7R010545 for mobile-ip-dist; Wed, 17 Jul 2002 17:23:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0NgoN010535; Wed, 17 Jul 2002 17:23:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22495; Wed, 17 Jul 2002 17:23:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08703; Wed, 17 Jul 2002 18:23:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20331; Wed, 17 Jul 2002 17:23:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0NgS07794; Wed, 17 Jul 2002 17:23:42 -0700 X-mProtect: <200207180023> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCxPx1p; Wed, 17 Jul 2002 17:23:40 PDT Message-ID: <3D360A8C.928E9CAD@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:23:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > > >processing a HAO is simply replacing the source address with > >the contents of the HAO. earlier it is used to be a MUST without > >the verification step. IPv6 WG was okay with that. but people > >indentified some reflection attacks that are possible if you > >blindly accept unverified home address option. so now, it is a > >MUST with the verification step. > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, > and i think it not reasonable for you to think that new-HAO is also > OKed automaticalliy. new-HAO?? the format has not changed. neither has the processing. it is still a destination option. how is it new? infact it has been made secure by the new verification step. infact, (IMO) there is no need for this new verification step if we have smart ingress filtering as described by Francis Dupont in http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-filtering-00.txt. Francis is probably around somewhere. can you please talk to him? Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:39:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04041 for ; Wed, 17 Jul 2002 20:39:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23441; Wed, 17 Jul 2002 17:38:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24131; Wed, 17 Jul 2002 17:38:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0bAoN010846 for ; Wed, 17 Jul 2002 17:37:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0bAux010845 for mobile-ip-dist; Wed, 17 Jul 2002 17:37:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0b7oN010838; Wed, 17 Jul 2002 17:37:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26404; Wed, 17 Jul 2002 17:37:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13470; Wed, 17 Jul 2002 18:37:06 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20998; Wed, 17 Jul 2002 17:37:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0b5f24390; Wed, 17 Jul 2002 17:37:05 -0700 X-mProtect: <200207180037> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdETGokX; Wed, 17 Jul 2002 17:37:02 PDT Message-ID: <3D360D42.A934AA34@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:35:15 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Itojun, The home address option is the same in format as the previous version. The additional requirement now is only that now it's required to be secured somehow. Regards, Charlie P. itojun@iijlab.net wrote: > >processing a HAO is simply replacing the source address with > >the contents of the HAO. earlier it is used to be a MUST without > >the verification step. IPv6 WG was okay with that. but people > >indentified some reflection attacks that are possible if you > >blindly accept unverified home address option. so now, it is a > >MUST with the verification step. > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, > and i think it not reasonable for you to think that new-HAO is also > OKed automaticalliy. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:41:58 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04125 for ; Wed, 17 Jul 2002 20:41:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17111; Wed, 17 Jul 2002 18:42:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17116; Wed, 17 Jul 2002 17:42:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0fNoN011021 for ; Wed, 17 Jul 2002 17:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0fNBO011020 for mobile-ip-dist; Wed, 17 Jul 2002 17:41:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0fKoN011011; Wed, 17 Jul 2002 17:41:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16765; Wed, 17 Jul 2002 17:41:21 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16683; Wed, 17 Jul 2002 18:41:20 -0600 (MDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I0hMW10331; Thu, 18 Jul 2002 03:43:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 03:41:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 03:41:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 03:41:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38ECF@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8ZI6pG4dYJ6ERBKA9LCbowSLNwAAQizQ To: , , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 00:41:18.0675 (UTC) FILETIME=[D496CA30:01C22DF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I0fKoO011014 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Hesham, > > > => Exactly, IMHO the support for HAO is tied to > > > RO support which is a SHOULD anyway, so the HAO > > > should follow that. > > > > Logically, you are inconsistant. > > > > As an example, RO is a should, protecting RO is a MUST. > > => Huh? > > Protecting it is a must for those who support it! > But supporting it is a should. We're dangerously on the edge of a rathole. Debates on support / implement / use of various functions is something to often causes pointless discussions. The question more is, what do general implementations need to implement. In my opinion, general often equals robust. SHOULD does not mean optional, it means you do it unless you have good reason not to do it. I think the burden of proof, then, would be the endpoint which does not implement a certain feature. I think that since HAO is used for security reasons, it may have a strong need to be a must than other functionality. Just my opinion. John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:45:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04199 for ; Wed, 17 Jul 2002 20:45:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11132; Wed, 17 Jul 2002 18:45:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18377; Wed, 17 Jul 2002 17:45:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0iZoN011234 for ; Wed, 17 Jul 2002 17:44:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0iZEj011233 for mobile-ip-dist; Wed, 17 Jul 2002 17:44:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0iUoN011223 for ; Wed, 17 Jul 2002 17:44:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17881 for ; Wed, 17 Jul 2002 17:44:31 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18033 for ; Wed, 17 Jul 2002 18:44:30 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I0iAv26082; Thu, 18 Jul 2002 02:44:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA00714; Thu, 18 Jul 2002 02:44:11 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6I0iAGF070487; Thu, 18 Jul 2002 02:44:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180044.g6I0iAGF070487@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: Vijay Devarapalli , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-reply-to: Your message of Wed, 17 Jul 2002 21:14:58 +0300. <3D35B422.2050107@nomadiclab.com> Date: Thu, 18 Jul 2002 02:44:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: One of the reasons why the R bit was taken away was (and IMHO still is) security. As far as I understand, the RR method does not work for mobile routers, but I may be wrong. => the R bit is for MN->HA BUs so your argument is irrelevant. Furthermore, I haven't been following closely enough, so I don't know if the base spec IPsec method (for MN-HA security) is now clear enough so that the R bit could be put back form MN-HA BUs. => MN-HA authorizes far more than the R bit so I don't believe there is a security issue. But AFAIK we still cannot use it for MN-CN BUs, due to these security consideratiosn. => this doesn't matter. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:45:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04232 for ; Wed, 17 Jul 2002 20:45:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01108; Wed, 17 Jul 2002 18:44:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17844; Wed, 17 Jul 2002 17:44:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0hNoN011137 for ; Wed, 17 Jul 2002 17:43:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0hNBH011135 for mobile-ip-dist; Wed, 17 Jul 2002 17:43:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0hJoN011118; Wed, 17 Jul 2002 17:43:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17543; Wed, 17 Jul 2002 17:43:20 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08848; Wed, 17 Jul 2002 17:43:19 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Jul 2002 17:44:48 -0700 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DF4.1C40AC15" Date: Wed, 17 Jul 2002 17:43:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6B15@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8bZcWArFmmXXSCy6gTz5ONnANgAAlLug From: "Mohan Parthasarathy" To: "Vijay Devarapalli" , Cc: "Michael Thomas" , , , , X-OriginalArrivalTime: 18 Jul 2002 00:44:48.0234 (UTC) FILETIME=[517EF4A0:01C22DF4] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C22DF4.1C40AC15 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Vijay, I am missing something. Can we invent a new option in the future and call it a MUST be processed by all nodes ? If a node does not understand the option, it should use the icmp parameter problem to return errors. Not sure why we need something special for HAO. -mohan > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 > Sent: Wednesday, July 17, 2002 5:24 PM > To: itojun@iijlab.net > Cc: Michael Thomas; john.loughney@nokia.com;=20 > keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com;=20 > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated >=20 >=20 > itojun@iijlab.net wrote: > >=20 > > >processing a HAO is simply replacing the source address with the=20 > > >contents of the HAO. earlier it is used to be a MUST without the=20 > > >verification step. IPv6 WG was okay with that. but people=20 > indentified=20 > > >some reflection attacks that are possible if you blindly accept=20 > > >unverified home address option. so now, it is a MUST with the=20 > > >verification step. > >=20 > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a=20 > lot since then, > > and i think it not reasonable for you to think that=20 > new-HAO is also > > OKed automaticalliy. >=20 > new-HAO?? the format has not changed. neither has the=20 > processing. it is still a destination option. how is it new?=20 > infact it has=20 > been made secure by the new verification step. >=20 > infact, (IMO) there is no need for this new verification step=20 > if we have smart ingress filtering as described by Francis=20 > Dupont in=20 > http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress- filtering-00.txt. Francis is probably around somewhere. can you please talk to him? Vijay ------_=_NextPart_001_01C22DF4.1C40AC15 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated

Vijay,

I am missing something. Can we invent a new option in = the future
and call it a MUST be processed by all nodes ? If a = node does
not understand the option, it should use the icmp = parameter
problem to return errors. Not sure why we need = something special
for HAO.

-mohan


> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] =
> Sent: Wednesday, July 17, 2002 5:24 PM
> To: itojun@iijlab.net
> Cc: Michael Thomas; john.loughney@nokia.com; =
> keiichi@iij.ad.jp; = mobile-ip@sunroof.eng.sun.com;
> ipng@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Re: HAO and BE = processing will be mandated
>
>
> itojun@iijlab.net wrote:
> >
> > >processing a HAO is simply replacing = the source address with the
> > >contents of the HAO. earlier it is used = to be a MUST without the
> > >verification step. IPv6 WG was okay = with that. but people
> indentified
> > >some reflection attacks that are = possible if you blindly accept
> > >unverified home address option. so now, = it is a MUST with the
> > >verification step.
> >
> = >         IPv6 wg OKed HAO in = draft 5 or 6.  HAO changed a
> lot since then,
> = >         and i think it not = reasonable for you to think that
> new-HAO is also
> = >         OKed = automaticalliy.
>
> new-HAO?? the format has not changed. neither = has the
> processing. it is still a destination option. = how is it new?
> infact it has
> been made secure by the new verification = step.
>
> infact, (IMO) there is no need for this new = verification step
> if we have smart ingress filtering as described = by Francis
> Dupont in
> h= ttp://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-
filtering-00.txt.
Francis is probably around somewhere. can you please = talk to him?

Vijay

------_=_NextPart_001_01C22DF4.1C40AC15-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:54:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04786 for ; Wed, 17 Jul 2002 20:54:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22119; Wed, 17 Jul 2002 18:55:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28909; Wed, 17 Jul 2002 17:55:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0rtoN011587 for ; Wed, 17 Jul 2002 17:53:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0rtVk011586 for mobile-ip-dist; Wed, 17 Jul 2002 17:53:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0rkoN011571; Wed, 17 Jul 2002 17:53:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28284; Wed, 17 Jul 2002 17:53:48 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14214; Wed, 17 Jul 2002 18:53:46 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6I0reRb004021; Thu, 18 Jul 2002 02:53:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VWQ6>; Thu, 18 Jul 2002 02:53:40 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0881@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , "Hesham Soliman (EAB)" , mat@cisco.com, itojun@iijlab.net Cc: vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 02:53:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > The question more is, what do general implementations need > to implement. > In my opinion, general often equals robust. SHOULD does not mean > optional, it means you do it unless you have good reason > not to do it. > I think the burden of proof, then, would be the endpoint > which does not > implement a certain feature. => So are you saying should is ok? because that's all I'm saying. > I think that since HAO is used for security reasons, it may > have a strong > need to be a must than other functionality. Just my opinion. => The HAO is not needed for security reasons at all. All these arguments for SHOULD vs MUST are essentially because some people want to allow triangular routing _for_IPsec_protected_ traffic _only_. As I said a few mails back, the HAO is only accepted if the packet is protected by IPsec or if a BCE exists. Hesham > > John > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 20:56:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04853 for ; Wed, 17 Jul 2002 20:56:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23172; Wed, 17 Jul 2002 18:57:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29662; Wed, 17 Jul 2002 17:57:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0tgoN011638 for ; Wed, 17 Jul 2002 17:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0tgeq011637 for mobile-ip-dist; Wed, 17 Jul 2002 17:55:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0tdoN011630; Wed, 17 Jul 2002 17:55:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02262; Wed, 17 Jul 2002 17:55:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19769; Wed, 17 Jul 2002 18:55:39 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA21860; Wed, 17 Jul 2002 17:55:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0tbt19812; Wed, 17 Jul 2002 17:55:37 -0700 X-mProtect: <200207180055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUkNVME; Wed, 17 Jul 2002 17:55:33 PDT Message-ID: <3D361206.B601A9B0@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:55:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Parthasarathy CC: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <416B5AF360DED54088DAD3CA8BFBEA6EAB6B15@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit a new spec comes out. it has a lot of features. some of the features are very important for the protocol (otherwise the protocol does not work well). so we say all nodes have to implement these features. on the other hand, the new spec should not screw up the earlier implementations. are we in agreement with the above? it is nice to consider legacy nodes. But software upgrades are also very routine. I dont have a machine which is running the earliest version of Windows/FreeBSD/Linux/...... regards Vijay > Mohan Parthasarathy wrote: > > Vijay, > > I am missing something. Can we invent a new option in the future > and call it a MUST be processed by all nodes ? If a node does > not understand the option, it should use the icmp parameter > problem to return errors. Not sure why we need something special > for HAO. > > -mohan > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Wednesday, July 17, 2002 5:24 PM > > To: itojun@iijlab.net > > Cc: Michael Thomas; john.loughney@nokia.com; > > keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; > > ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > > > > itojun@iijlab.net wrote: > > > > > > >processing a HAO is simply replacing the source address with the > > > >contents of the HAO. earlier it is used to be a MUST without the > > > >verification step. IPv6 WG was okay with that. but people > > indentified > > > >some reflection attacks that are possible if you blindly accept > > > >unverified home address option. so now, it is a MUST with the > > > >verification step. > > > > > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a > > lot since then, > > > and i think it not reasonable for you to think that > > new-HAO is also > > > OKed automaticalliy. > > > > new-HAO?? the format has not changed. neither has the > > processing. it is still a destination option. how is it new? > > infact it has > > been made secure by the new verification step. > > > > infact, (IMO) there is no need for this new verification step > > if we have smart ingress filtering as described by Francis > > Dupont in > > http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress- > filtering-00.txt. > Francis is probably around somewhere. can you please talk to him? > > Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 21:01:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05015 for ; Wed, 17 Jul 2002 21:01:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17038; Wed, 17 Jul 2002 18:59:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01221; Wed, 17 Jul 2002 17:59:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vdoN011808 for ; Wed, 17 Jul 2002 17:57:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0vdaC011807 for mobile-ip-dist; Wed, 17 Jul 2002 17:57:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vQoN011779; Wed, 17 Jul 2002 17:57:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22786; Wed, 17 Jul 2002 17:57:27 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00646; Wed, 17 Jul 2002 17:57:26 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I0v9v26566; Thu, 18 Jul 2002 02:57:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA00793; Thu, 18 Jul 2002 02:57:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6I0vAGF070550; Thu, 18 Jul 2002 02:57:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180057.g6I0vAGF070550@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Wed, 17 Jul 2002 14:33:21 PDT. <3D35E2A1.18E60F30@iprg.nokia.com> Date: Thu, 18 Jul 2002 02:57:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. I was discounting the reason (the already IPv6 installed base) you gave. the MUST is for newer IPv6 CN implementations. as I told you already, it makes the MN's life easier. but the current spec does ensure that a MN can still have a session with an old IPv6 implementation (which does not implement HAO) through reverse tunneling. so again, where is the problem? why are you against the MUST? => MUSTs are for interoperability problems, not for political matters. So Itojun is right and the fact that old IPv6 nodes still work with MNs proves the requirement should not be higher than SHOULD. Regards Francis.Dupont@enst-bretagne.fr PS: sorry but if someone is asking whether the RR/RO support should be mandatory I'll vote against it. And I can't see how the iETF will enforce it if I am being in the minority... (the topics has just been added to the ipv6 WG session agenda) From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 21:05:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05092 for ; Wed, 17 Jul 2002 21:05:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15859; Wed, 17 Jul 2002 18:00:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04467; Wed, 17 Jul 2002 17:59:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0w3oN011868 for ; Wed, 17 Jul 2002 17:58:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0w39B011867 for mobile-ip-dist; Wed, 17 Jul 2002 17:58:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vkoN011825; Wed, 17 Jul 2002 17:57:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03204; Wed, 17 Jul 2002 17:57:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20656; Wed, 17 Jul 2002 18:57:45 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3598C4B25; Thu, 18 Jul 2002 09:57:38 +0900 (JST) To: Vijay Devarapalli Cc: Mohan Parthasarathy , Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 17:55:34 MST. <3D361206.B601A9B0@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 09:57:38 +0900 Message-Id: <20020718005738.3598C4B25@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >it is nice to consider legacy nodes. But software upgrades >are also very routine. I dont have a machine which is running >the earliest version of Windows/FreeBSD/Linux/...... i don't think i have the same definition for "legacy" with you. itojun From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 21:13:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05253 for ; Wed, 17 Jul 2002 21:13:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29931; Wed, 17 Jul 2002 19:13:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29470; Wed, 17 Jul 2002 18:13:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CXoN012378 for ; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I1CXdt012377 for mobile-ip-dist; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CUoN012370; Wed, 17 Jul 2002 18:12:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05406; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06648; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 21:07:05 -0400 Message-ID: From: Phil Roberts To: "'Francis Dupont'" , Vijay Devarapalli Cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 21:07:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: A few issues have become mingled here. 1) Keiichi and others have raised the issue of MUST support for HAO and BE processing and have proposed a solution that allows communication to happen between any two nodes with clarification in the MIP spec of properly handling the ICMP errors returned. 2) There is a question about RO support requirements for all nodes. Actually the current spec doesn't give a recommendation for support of RO. If a node is supporting it, there are a bunch of MUSTs. We should make sure we agree as a working group on our consensus on these two issues. Perhaps we can sort this out on the MIP list first? > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, July 17, 2002 8:57 PM > To: Vijay Devarapalli > Cc: itojun@iijlab.net; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > In your previous mail you wrote: > > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > I was discounting the reason (the already IPv6 installed base) you > gave. the MUST is for newer IPv6 CN implementations. as I told you > already, it makes the MN's life easier. but the current spec does > ensure that a MN can still have a session with an old IPv6 > implementation (which does not implement HAO) through reverse > tunneling. so again, where is the problem? why are you against the > MUST? > > => MUSTs are for interoperability problems, not for political matters. > So Itojun is right and the fact that old IPv6 nodes still work with > MNs proves the requirement should not be higher than SHOULD. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: sorry but if someone is asking whether the RR/RO support should be > mandatory I'll vote against it. And I can't see how the iETF will > enforce it if I am being in the minority... > (the topics has just been added to the ipv6 WG session agenda) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:15:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07189 for ; Wed, 17 Jul 2002 22:15:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13969; Wed, 17 Jul 2002 20:16:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21124; Wed, 17 Jul 2002 19:16:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2EgoN012763 for ; Wed, 17 Jul 2002 19:14:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2EgU2012762 for mobile-ip-dist; Wed, 17 Jul 2002 19:14:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2EZoN012747; Wed, 17 Jul 2002 19:14:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16808; Wed, 17 Jul 2002 19:14:37 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13355; Wed, 17 Jul 2002 20:14:36 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C96E26A905; Thu, 18 Jul 2002 05:14:35 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 55CCD6A906; Thu, 18 Jul 2002 05:14:32 +0300 (EEST) Message-ID: <3D36233F.9050700@kolumbus.fi> Date: Thu, 18 Jul 2002 05:09:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: itojun@iijlab.net Cc: Keiichi SHIMA / ??? , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717140100.C4A734B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Itojun, > we have no way to force upgrade for all users of the existing IPv6 > stacks. therefore, i believe it very important for mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO support, nor > binding error message support This is already the case. Draft 18 always work even with an IPv6 node that has no MIPv6 support. A CN that doesn't support RR will be sending back ICMP Parameter Problems, which we take in account. (In the current draft also shows a rather special case where HAO could be used without RO if an SA exists, but even in that case we would get an ICMP back and be able to act if the other side didn't support this.) By the way, this ability to support non-MIPv6 nodes is a new feature from a couple of months back, a consequence of protecting against certain security attacks. I really like this feature, and it should make new implementations quite good in the interoperability sense. So, technically everything works. But it's a separate question whether the IETF wants to mandate (SHOULD/MUST) some level of additional support, such as for the HAO or even for the RO. But regardless of whether such mandates are accepted or implemented, the protocol should technically work in all cases. If you can see a case where this would not be the case, please let as know and we'll fix it. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:27:50 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07656 for ; Wed, 17 Jul 2002 22:27:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00884; Wed, 17 Jul 2002 19:26:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19766; Wed, 17 Jul 2002 19:26:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2PEoN012938 for ; Wed, 17 Jul 2002 19:25:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2PEWc012937 for mobile-ip-dist; Wed, 17 Jul 2002 19:25:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2P2oN012922; Wed, 17 Jul 2002 19:25:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19579; Wed, 17 Jul 2002 19:25:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07512; Wed, 17 Jul 2002 20:25:03 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I2OUv29036; Thu, 18 Jul 2002 04:24:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA01531; Thu, 18 Jul 2002 04:24:30 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6I2OTGF071088; Thu, 18 Jul 2002 04:24:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180224.g6I2OTGF071088@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Wed, 17 Jul 2002 17:23:40 PDT. <3D360A8C.928E9CAD@iprg.nokia.com> Date: Thu, 18 Jul 2002 04:24:29 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: new-HAO?? the format has not changed. neither has the processing. => this is not true, now the HAO must be verificable/verified. infact, (IMO) there is no need for this new verification step if we have smart ingress filtering as described by Francis Dupont in http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-filtering-00.txt. Francis is probably around somewhere. can you please talk to him? => this solution was rejected by the DT... In fact even the verification concept (from a Charlie Perkins' attempt to avoid mandatory BCE check) is at the margin of the DT decision. Regards Francis.Dupont@enst-bretagne.fr PS: I believe Pekka can summarize his ideas about CoA stuff at the alternate security of Mobile IPv6 bar BOF. From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:37:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08265 for ; Wed, 17 Jul 2002 22:37:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03861; Wed, 17 Jul 2002 19:35:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21610; Wed, 17 Jul 2002 19:35:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2YjoN013117 for ; Wed, 17 Jul 2002 19:34:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2Yj59013116 for mobile-ip-dist; Wed, 17 Jul 2002 19:34:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2YgoN013109; Wed, 17 Jul 2002 19:34:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21718; Wed, 17 Jul 2002 19:34:44 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03404; Wed, 17 Jul 2002 19:34:43 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I2Yfv29408; Thu, 18 Jul 2002 04:34:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA01625; Thu, 18 Jul 2002 04:34:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6I2YfGF071146; Thu, 18 Jul 2002 04:34:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180234.g6I2YfGF071146@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: john.loughney@nokia.com cc: hesham.soliman@era.ericsson.se, mat@cisco.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Thu, 18 Jul 2002 03:41:18 +0300. <0C1353ABB1DEB74DB067ADFF749C4EEFD38ECF@esebe004.NOE.Nokia.com> Date: Thu, 18 Jul 2002 04:34:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I think that since HAO is used for security reasons, it may have a strong need to be a must than other functionality. Just my opinion. => I disagree: HAO is only a tunnel optimization and is *not* used for security reasons. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:39:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08395 for ; Wed, 17 Jul 2002 22:39:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12217; Wed, 17 Jul 2002 20:39:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22900; Wed, 17 Jul 2002 19:39:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2cGoN013309 for ; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2cGqB013308 for mobile-ip-dist; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2c6oN013287; Wed, 17 Jul 2002 19:38:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22501; Wed, 17 Jul 2002 19:38:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22744; Wed, 17 Jul 2002 20:38:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 266876A906; Thu, 18 Jul 2002 05:38:00 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C9856A905; Thu, 18 Jul 2002 05:37:56 +0300 (EEST) Message-ID: <3D362A71.20606@kolumbus.fi> Date: Thu, 18 Jul 2002 05:39:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Vijay Devarapalli , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> <15670.1003.493633.920465@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? That _is_ actually the intention. We tried to formulate section 8.2. (RO requirements) in the MIPv6 draft so that it describes what you have to do to support RO, but not when you have to support it. And we are expecting the node requirements document to say MAY/SHOULD/MUST for the RO feature. I think that's the right place to make the determination. Ok? Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:39:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08412 for ; Wed, 17 Jul 2002 22:39:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04776; Wed, 17 Jul 2002 19:38:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25736; Wed, 17 Jul 2002 19:38:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2akoN013199 for ; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2akrN013198 for mobile-ip-dist; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2aaoN013174; Wed, 17 Jul 2002 19:36:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22174; Wed, 17 Jul 2002 19:36:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19124; Wed, 17 Jul 2002 19:36:38 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8F9F06A906; Thu, 18 Jul 2002 05:36:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E92236A905; Thu, 18 Jul 2002 05:36:33 +0300 (EEST) Message-ID: <3D362A1E.3080101@kolumbus.fi> Date: Thu, 18 Jul 2002 05:38:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Moore Cc: itojun@iijlab.net, Keiichi SHIMA / =?ISO-8859-1?Q?=3F=3F=3F?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207171531.g6HFVft12848@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keith Moore wrote: > the purpose of a standard is to describe what is necessary for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate whether a feature > is a MUST in a new version of a standard unless interoperability with the > installed base is important (it generally is) and imposing the MUST condition > on implementations that conform with the new version of the standard affects > interoperability with the installed base. Agree with all of the above. In this case, there are no interoperability problems. Since draft N-2 Mobile IPv6 has been able to work with IPv6 nodes that have *no* MIPv6 specific code. Again, this is separate from what the IETF may mandate for IPv6 nodes to support. To take a clearly unreasonable example, we could mandate every node to support a 1,000,000 entry bindind cache. Even with such a mandate a node conforming to this requirement would work with a node that has never heard of MIPv6. So, interoperability and must-implement are different in this particular case. I think that's good because we can then decide more freely what to require from all implementations. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:42:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08521 for ; Wed, 17 Jul 2002 22:42:10 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13458; Wed, 17 Jul 2002 20:42:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23928; Wed, 17 Jul 2002 19:42:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2froN013599 for ; Wed, 17 Jul 2002 19:41:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2frrP013598 for mobile-ip-dist; Wed, 17 Jul 2002 19:41:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2fjoN013579; Wed, 17 Jul 2002 19:41:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26586; Wed, 17 Jul 2002 19:41:48 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21234; Wed, 17 Jul 2002 19:41:47 -0700 (PDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user38.cisco.com [10.70.82.38]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id EAA20829; Thu, 18 Jul 2002 04:41:18 +0200 (MET DST) From: "Pascal Thubert" To: , , Cc: , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 11:41:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit * Just as an FYI, I replied to the earlier mail because I am > trying to sort this out for the node requirements. I think > that in MIPv6, it is OK that MIPv6 makes this recommendation (given > working group consensus, IESG approval, etc.) but the Node Requirements > document is the final word on the issue (assuming WG consensus, > IESG approval, etc.). This issue seems to delay MIPv6 till the node requirement is out; so could we not just recommend that the Mobile Node SHOULD use the reverse tunnel till some part of the RR test is complete? If we do so, then a potential CN that fails to respond to the CoT test would be considered as a legacy device and we would not perform RO at all. My initial proposal is to negotiate the RO the following way: Cot Fails : The MN MUST use the reverse tunnel for all traffic Cot works, Hot Fails : The CN accepts the HaO but is not willing to manage a Bind Cache -> triangular routing (E.g. a clustered web server) Both work: The CN is willing to receive bind updates. What do you think? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of john.loughney@nokia.com Sent: Thursday, July 18, 2002 2:14 AM To: mat@cisco.com; vijayd@iprg.nokia.com Cc: itojun@iijlab.net; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:49:31 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08751 for ; Wed, 17 Jul 2002 22:49:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21795; Wed, 17 Jul 2002 19:43:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24334; Wed, 17 Jul 2002 19:43:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2guoN013649 for ; Wed, 17 Jul 2002 19:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2gudT013648 for mobile-ip-dist; Wed, 17 Jul 2002 19:42:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2gkoN013621; Wed, 17 Jul 2002 19:42:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23989; Wed, 17 Jul 2002 19:42:48 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA24319; Wed, 17 Jul 2002 20:42:47 -0600 (MDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user38.cisco.com [10.70.82.38]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id EAA20858; Thu, 18 Jul 2002 04:42:25 +0200 (MET DST) From: "Pascal Thubert" To: , , Cc: , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 11:42:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit * Just as an FYI, I replied to the earlier mail because I am > trying to sort this out for the node requirements. I think > that in MIPv6, it is OK that MIPv6 makes this recommendation (given > working group consensus, IESG approval, etc.) but the Node Requirements > document is the final word on the issue (assuming WG consensus, > IESG approval, etc.). This issue seems to delay MIPv6 till the node requirement is out; so could we not just recommend that the Mobile Node SHOULD use the reverse tunnel till some part of the RR test is complete? If we do so, then a potential CN that fails to respond to the CoT test would be considered as a legacy device and we would not perform RO at all. My initial proposal is to negotiate the RO the following way: Cot Fails : The MN MUST use the reverse tunnel for all traffic Cot works, Hot Fails : The CN accepts the HaO but is not willing to manage a Bind Cache -> triangular routing (E.g. a clustered web server) Both work: The CN is willing to receive bind updates. What do you think? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of john.loughney@nokia.com Sent: Thursday, July 18, 2002 2:14 AM To: mat@cisco.com; vijayd@iprg.nokia.com Cc: itojun@iijlab.net; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:51:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08860 for ; Wed, 17 Jul 2002 22:51:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08881; Wed, 17 Jul 2002 19:50:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24794; Wed, 17 Jul 2002 19:50:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2mnoN014044 for ; Wed, 17 Jul 2002 19:48:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2mnbN014043 for mobile-ip-dist; Wed, 17 Jul 2002 19:48:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2mgoN014026; Wed, 17 Jul 2002 19:48:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24434; Wed, 17 Jul 2002 19:48:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08433; Wed, 17 Jul 2002 19:48:43 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 980366A906; Thu, 18 Jul 2002 05:48:42 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2A9E26A905; Thu, 18 Jul 2002 05:48:38 +0300 (EEST) Message-ID: <3D362CF2.6070301@kolumbus.fi> Date: Thu, 18 Jul 2002 05:50:26 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> <3D360A8C.928E9CAD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.4 required=5.0 tests=ONE_HUNDRED_PC_FREE version=2.20 X-Spam-Level: ** Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > new-HAO?? the format has not changed. neither has the processing. > it is still a destination option. how is it new? infact it has > been made secure by the new verification step. The processing has changed in the sense that there is a new verification step. Basically, we don't accept unverified HAOs, either an SA or RR BCE must exist before they can be used. This limits in a sense the use of the HAO in a completely free way, as it used to be. (The most efficient routing case, RO, is of course still supported and that's what we hope will be used in most cases.) (Back in the old versions of the draft, HAO needed to be a MUST because otherwise interoperability would have failed.) Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 22:51:47 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08873 for ; Wed, 17 Jul 2002 22:51:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22565; Wed, 17 Jul 2002 19:45:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25035; Wed, 17 Jul 2002 19:45:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2j6oN013821 for ; Wed, 17 Jul 2002 19:45:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2j5e0013820 for mobile-ip-dist; Wed, 17 Jul 2002 19:45:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2j2oN013807 for ; Wed, 17 Jul 2002 19:45:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27200 for ; Wed, 17 Jul 2002 19:45:04 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25017 for ; Wed, 17 Jul 2002 20:45:03 -0600 (MDT) Message-ID: <006d01c22e04$756ab6f0$ba4c5d85@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "'James Kempf'" , "Rajeev Koodli" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 17 Jul 2002 19:40:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ajoy, > Hi Ajoy, > > > Ajoy-> Target trigger will be suitable for cellular > > networks. BTW, even in case of WLAN, you can receive > > L2-TT trigger at nAP. L2TT (Re-association Request) can > > provide nAP the L2 address of the oldAP as well as L2 > > address of the mobile node. If we implement FA function > > Does re-association also apply to BSS mode, or when > the station moves between two different ESS? > > If it is only used when the station moves from one AP > to another in the same ESS, this is not as interesting, > because the mobility is already handled at link-layer > in 802.11b. > > Ajoy-> Mostly I have seen Re-association Request is sent > whenever an MN moves from one AP to other AP in the same ESS. > This is partly because IAPP handles intra-ESS handoff. Exactly.... So, IAPP already takes care of the mobility, no need for higher layer mobility management in that particular case. > I believe this is an implementation issue and > can be easily extended, if Mobile/IP provides appropriate hooks. I wonder if the spec allows/enables use of re-association messages in BSS mode. And than, if client is already sending a re-association message, why not use ESS and IAPP for this? Why would people need another protocol that looks like IAPP on the same network.. > > > at AP, then this becomes an implementation issue. > > If not, then you need to define some protocol between > > AP and AR which can be addressed in separate document. > > http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt > > ... > > > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does > > not work for network initiated trigger. BTW, based upon our > > implementation, we found anticipated handover does not provide > > good performance on cellular link. Hence, anticipated handover > > is not going to address fast handoff need for various cellular networks. > > Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation? > > Ajoy-> We implemented FMIPv4. But I do not believe FMIPv6 implementation > will provide substantially better performance. More or less the basic > idea is same. I think the part of the problem is high RTT of 3G wireless > link (MN to AR). So, adding lots of signaling messages over the high RTT > link will require sufficiently higher anticipation time. If you keep > very high anticipation time, handover may not be consistently > reliable. > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and then applying to "anticipated FMIPv6" without experimenting is not a good idea. Protocols are sufficiently different to make considerable performance differences. alper > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 17 23:05:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09169 for ; Wed, 17 Jul 2002 23:05:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13424; Wed, 17 Jul 2002 20:04:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00290; Wed, 17 Jul 2002 20:04:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I33boN014292 for ; Wed, 17 Jul 2002 20:03:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I33bba014291 for mobile-ip-dist; Wed, 17 Jul 2002 20:03:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I33ToN014276; Wed, 17 Jul 2002 20:03:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27187; Wed, 17 Jul 2002 20:03:32 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28134; Wed, 17 Jul 2002 20:03:31 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 6BFCE6A906; Thu, 18 Jul 2002 06:03:30 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DD5C66A905; Thu, 18 Jul 2002 06:03:25 +0300 (EEST) Message-ID: <3D36306A.3030808@kolumbus.fi> Date: Thu, 18 Jul 2002 06:05:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: john.loughney@nokia.com, mat@cisco.com, vijayd@iprg.nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pascal Thubert wrote: > * Just as an FYI, I replied to the earlier mail because I am > >>trying to sort this out for the node requirements. I think >>that in MIPv6, it is OK that MIPv6 makes this recommendation (given >>working group consensus, IESG approval, etc.) but the Node Requirements >>document is the final word on the issue (assuming WG consensus, >>IESG approval, etc.). >> > > This issue seems to delay MIPv6 till the node requirement is out; so could we > not just recommend that the Mobile Node SHOULD use the reverse tunnel till some > part of the RR test is complete? If we do so, then a potential CN that fails to > respond to the CoT test would be considered as a legacy device and we would not > perform RO at all. My initial proposal is to negotiate the RO the following > way: This is what the spec has been saying for some time. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 00:13:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10425 for ; Thu, 18 Jul 2002 00:13:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22505; Wed, 17 Jul 2002 22:13:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07032; Wed, 17 Jul 2002 21:13:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4CCoN014577 for ; Wed, 17 Jul 2002 21:12:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4CC5t014576 for mobile-ip-dist; Wed, 17 Jul 2002 21:12:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4C8oN014569; Wed, 17 Jul 2002 21:12:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12188; Wed, 17 Jul 2002 21:12:08 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18071; Wed, 17 Jul 2002 21:12:07 -0700 (PDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I4Cci08693; Thu, 18 Jul 2002 07:12:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 07:12:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 07:12:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 07:12:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65794@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuByyL3HPCS9V9RJyUXIPriJqhyAACci5g To: , , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 04:12:06.0392 (UTC) FILETIME=[47373F80:01C22E11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I4C8oO014570 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Pascal, > This issue seems to delay MIPv6 till the node requirement is > out; I disagree. I think that MIP WG should specify what it thinks is correct & documents it. If the documentation is good & reasons are sufficient, I don't think that supportting it in the Node Requirements document will be a problem. John From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 00:18:56 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10514 for ; Thu, 18 Jul 2002 00:18:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18304; Wed, 17 Jul 2002 21:13:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12394; Wed, 17 Jul 2002 21:13:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4BvoN014561 for ; Wed, 17 Jul 2002 21:11:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4Bvxt014560 for mobile-ip-dist; Wed, 17 Jul 2002 21:11:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4BroN014553 for ; Wed, 17 Jul 2002 21:11:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13854 for ; Wed, 17 Jul 2002 21:11:54 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22139 for ; Wed, 17 Jul 2002 22:11:54 -0600 (MDT) Message-ID: <011201c22e11$0420dee0$256015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0879@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Fast handovers - proposal for moving forward Date: Wed, 17 Jul 2002 19:32:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > But we disagree on the level of detail at which L2 triggers > should be included in the draft, and the value of tunnel-based > handover (I think). > There is an additional point on which we disagree. The need for a handover solution in which there is no over the air signaling, either pre- or posthandover. > I think that the current draft (v5) provides an > access independent framework for Fast handovers, > assuming some hints from lower layers, like > L2 (in the MN or the AR depending on the type > of link) knows that handover is about to happen > and will inform the IP layer. Well, the claim was made that the current draft was specfically written to exclude any reference to hints from Layer 2. My opinion is that it was written to specificallly exclude certain handover techniques that require hints from Layer 2, namely those that require no over the air signaling, and to relegate those that require posthandover over the air signaling to error cases. Those that require prehandover over the air signaling were included as the normal cases, regardless of whether they required layer 2 information or not. Curiously, the normal cases were exactly those that were included in draft 02, which was the result of now long concluded design team discussions. Thus, I have a difficult time understanding the logic behind what was included and eliminated from draft 4. >I believe that's > about as far as the doc needs to say. However, > to get this stuff deployed and make it useful, > more detail is needed. But I don't think that > this draft can possibly include all the details > relevant to all link layers. This is where Fast > Handovers over foo documents would be needed. > > These documents can show exactly what triggers > are needed, and how to integrate FMIPv6 signalling > at the right time. Frankly, even if the current > draft shows some names for L2 triggers, I don't > think it would be useful. We need more detail > for each link layer. > > So, to this extent, I think that an FMIPv6 over > 802.11 doc is needed. But I definitely don't think we should > do a different IP layer protocol standardised for each link > layer. I believe it is unnecessary, let alone > defeats the purpose of doing any fast handover scheme > on the IP layer. > Here's what I think the current draft needs: 1) A clear statement of the problem. 2) A high level perspective on the proposed solution space that clearly describes the two processes proposed for solving the problem of optimizing Mobile IP handover: a) Prehandover address configuration b) Repair of routing failure due to old link termination. The first process is not required because it is not possible for certain link layers, the second is required for optimization otherwise the mobile node loses in flight packets. 3) A short description of requirements on link layers. These requirements may not all hold for all link layers. In addition, this should include a grouping of requirements into classes of link layers based on what kinds of prehandover and posthandover information is available on handover sequencing. For example, one class has prehandover sequencing information available on the mobile node, and thus can support prehandover address configuration. This section should also describe when this protocol is not required, for example, when the layer 2 supports make before break handover. 4) A description of the IP signaling required to perform prehandover address configuration, and the IP signaling required to perform routing failure repair, without any reference to the availabity of layer 2 handover sequencing information. 5) A description of what IP signaling would occur for particular classes of available layer 2 handover sequencing information. If this sounds complicated, its because there are time dependencies and dependencies on lower layers that don't occur for other IP protocols. I believe igoring those would result in a base specification without sufficient detail to guide implementors having to implement the protocol on a particular link layer. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 00:48:37 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11122 for ; Thu, 18 Jul 2002 00:48:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02207; Wed, 17 Jul 2002 22:49:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13742; Wed, 17 Jul 2002 21:48:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4m3oN015025 for ; Wed, 17 Jul 2002 21:48:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4m3uN015024 for mobile-ip-dist; Wed, 17 Jul 2002 21:48:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4ltoN015006; Wed, 17 Jul 2002 21:47:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13596; Wed, 17 Jul 2002 21:47:56 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20937; Wed, 17 Jul 2002 22:47:55 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 015FB6A906; Thu, 18 Jul 2002 07:47:54 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 294556A905; Thu, 18 Jul 2002 07:47:51 +0300 (EEST) Message-ID: <3D3648E4.8050701@kolumbus.fi> Date: Thu, 18 Jul 2002 07:49:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mat@cisco.com, itojun@iijlab.net, keiichi@iij.ad.jp Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] summary of HAO, BE processing discussion References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm trying to summarize the discussion on the HAO and BE processing. Here's a few things that came up in the discussion: * MUSTs should be used only if interoperability is at danger, or if the health of the internet is in question even if protocols would operate correctly. * There will be existing IPv6 nodes that do not yet have MIPv6 support, and not all of them can be changed overnight when a new IPv6 RFC comes out. * The current MIPv6 protocol works technically even with non-MIPv6 nodes. The MNs will not normally attempt to use HAO without establishing a binding. If the CN does not support MIPv6 RR, it sends back an ICMPv6 parameter problem. And even if the MN went ahead and used HAO (as in with IPsec, for instance), the CN would also respond with a parameter problem. This is in the current draft*. * There are two potential node requirements from the MIPv6 functionality: - Route optimization, the main benefit (section 8.2) - Basic HAO supported, a subset of the above and used for HAO under IPsec with triangular routing (8.1). Includes also BEs. * The current draft does not state what the keyword is for the RO functionality (so far left for the node requirements team to decide, yet we intend to recommend something). The draft does say MUST for basic HAO support, however. * The IETF is free to decide what kind of requirement to place on nodes for these functions, since there are no interoperability concerns. * IPv6 WG has in the past accepted the HAO as a mandatory feature for all IPv6 nodes. Arguments have been made, however, that the processing of the HAO has been changed and the situation may now be different. * Arguments have been raised that the basic HAO support does not fullfil conditions to be a MUST. * Earlier discussions have looked upon what is the right level of support for RO. Proposals ranging from MAY to MUST were then mentioned, and arguments about congestion-like effects of non-optimal routing were used among others. Jari * A last call comment requested more text for the HAO-without-RO case. From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 00:51:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11174 for ; Thu, 18 Jul 2002 00:51:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12107; Wed, 17 Jul 2002 21:45:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21078; Wed, 17 Jul 2002 21:45:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4ivoN014896 for ; Wed, 17 Jul 2002 21:44:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4ivAG014895 for mobile-ip-dist; Wed, 17 Jul 2002 21:44:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4iooN014880; Wed, 17 Jul 2002 21:44:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12940; Wed, 17 Jul 2002 21:44:51 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19912; Wed, 17 Jul 2002 22:44:50 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 65A756A906; Thu, 18 Jul 2002 07:44:49 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A5C656A905; Thu, 18 Jul 2002 07:44:44 +0300 (EEST) Message-ID: <3D364829.90806@kolumbus.fi> Date: Thu, 18 Jul 2002 07:46:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: pthubert@cisco.com, mat@cisco.com, vijayd@iprg.nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65794@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Pascal, > > >>This issue seems to delay MIPv6 till the node requirement is >>out; >> > > I disagree. I think that MIP WG should specify what it thinks > is correct & documents it. If the documentation is good & > reasons are sufficient, I don't think that supportting it > in the Node Requirements document will be a problem. I agree with John on this. Note also that even if the final keyword would be found in the node requirements document, MIPv6 can still be deployed as soon as its spec is out. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 01:16:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11628 for ; Thu, 18 Jul 2002 01:16:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12396; Wed, 17 Jul 2002 23:16:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22665; Wed, 17 Jul 2002 22:16:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5FHoN015271 for ; Wed, 17 Jul 2002 22:15:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5FHrE015270 for mobile-ip-dist; Wed, 17 Jul 2002 22:15:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5FDoN015252; Wed, 17 Jul 2002 22:15:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22433; Wed, 17 Jul 2002 22:15:14 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21609; Wed, 17 Jul 2002 22:15:14 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 01:09:47 -0400 Message-ID: From: Phil Roberts To: "'Jari Arkko'" , mat@cisco.com, itojun@iijlab.net, keiichi@iij.ad.jp Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] RE: summary of HAO, BE processing discussion Date: Thu, 18 Jul 2002 01:09:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: When the next version of the draft is issued, incorporating all the agreed resolutions of WG last call comments, we'll post a note to the ipng mailing list summarizing the requirements that the MIP WG is recommending. Phil > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, July 18, 2002 12:50 AM > To: mat@cisco.com; itojun@iijlab.net; keiichi@iij.ad.jp > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: summary of HAO, BE processing discussion > > > > I'm trying to summarize the discussion on the HAO and BE > processing. > > Here's a few things that came up in the discussion: > > * MUSTs should be used only if interoperability is > at danger, or if the health of the internet is > in question even if protocols would operate > correctly. > > * There will be existing IPv6 nodes that do not > yet have MIPv6 support, and not all of them can > be changed overnight when a new IPv6 RFC comes out. > > * The current MIPv6 protocol works technically even > with non-MIPv6 nodes. The MNs will not normally > attempt to use HAO without establishing a binding. > If the CN does not support MIPv6 RR, it sends back > an ICMPv6 parameter problem. And even if the MN > went ahead and used HAO (as in with IPsec, for instance), > the CN would also respond with a parameter problem. > > This is in the current draft*. > > * There are two potential node requirements from the > MIPv6 functionality: > - Route optimization, the main benefit (section 8.2) > - Basic HAO supported, a subset of the above and > used for HAO under IPsec with triangular routing > (8.1). Includes also BEs. > > * The current draft does not state what the keyword > is for the RO functionality (so far left for the node > requirements team to decide, yet we intend to recommend > something). The draft does say MUST for basic > HAO support, however. > > * The IETF is free to decide what kind of requirement to > place on nodes for these functions, since there are > no interoperability concerns. > > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. > > * Arguments have been raised that the basic HAO support does > not fullfil conditions to be a MUST. > > * Earlier discussions have looked upon what is the right > level of support for RO. Proposals ranging from MAY to > MUST were then mentioned, and arguments about congestion-like > effects of non-optimal routing were used among others. > > Jari > > * A last call comment requested more text for the HAO-without-RO case. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 01:21:07 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11852 for ; Thu, 18 Jul 2002 01:21:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12532; Wed, 17 Jul 2002 23:21:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29593; Wed, 17 Jul 2002 22:21:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KPoN015423 for ; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5KPkV015422 for mobile-ip-dist; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KLoN015415; Wed, 17 Jul 2002 22:20:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18711; Wed, 17 Jul 2002 22:20:23 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23539; Wed, 17 Jul 2002 22:20:22 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA28494; Thu, 18 Jul 2002 14:20:21 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA28160; Thu, 18 Jul 2002 14:20:19 +0900 (JST) Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST) Message-Id: <20020718.141850.32635405.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3648E4.8050701@kolumbus.fi> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 01:24:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11973 for ; Thu, 18 Jul 2002 01:24:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14197; Wed, 17 Jul 2002 23:25:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24294; Wed, 17 Jul 2002 22:25:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5OPoN015601 for ; Wed, 17 Jul 2002 22:24:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5OOja015600 for mobile-ip-dist; Wed, 17 Jul 2002 22:24:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5OLoN015593 for ; Wed, 17 Jul 2002 22:24:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19704 for ; Wed, 17 Jul 2002 22:24:23 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12597 for ; Wed, 17 Jul 2002 23:24:22 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 01:18:55 -0400 Message-ID: From: Phil Roberts To: "'Hesham Soliman (EAB)'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Fast handovers - proposal for moving forward Date: Thu, 18 Jul 2002 01:18:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, July 17, 2002 12:52 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fast handovers - proposal for moving forward > > > Hi, > > I didn't have enough time in the meeting to explain > clearly what I meant when we discussed Phil's proposal. > Since I suddenly have excellent WLAN coverage in the > room, I'll try to do it now! > > First of all, I'm not sure that the WG is actually > split. In fact, after reading all emails, I think we > agree on many issues. Let me try to list them and > see if I'm right. I think we agree on the following: > > - L2 triggers will make Fast handovers perform better. > - L2 triggers are needed. > - We need an access independent solution. > > But we disagree on the level of detail at which L2 triggers > should be included in the draft, and the value of tunnel-based > handover (I think). > > So, to make my comment clear, I wasn't not against > Phil's proposal to have a separate draft for Fast > Handovers in 802.11. I was only against the implicit > content of such document. > > I think that the current draft (v5) provides an > access independent framework for Fast handovers, > assuming some hints from lower layers, like > L2 (in the MN or the AR depending on the type > of link) knows that handover is about to happen > and will inform the IP layer. I believe that's > about as far as the doc needs to say. However, > to get this stuff deployed and make it useful, > more detail is needed. But I don't think that > this draft can possibly include all the details > relevant to all link layers. This is where Fast > Handovers over foo documents would be needed. > > These documents can show exactly what triggers > are needed, and how to integrate FMIPv6 signalling > at the right time. Frankly, even if the current > draft shows some names for L2 triggers, I don't > think it would be useful. We need more detail > for each link layer. > > So, to this extent, I think that an FMIPv6 over > 802.11 doc is needed. But I definitely don't think we should > do a different IP layer protocol standardised for each link > layer. I believe it is unnecessary, let alone > defeats the purpose of doing any fast handover scheme > on the IP layer. > > Does this make sense to anyone ? > I wish we had a show of hands during the meeting but > there was no time to discuss it, because I don't think > the WG is very divided on this actually. Makes perfect sense. I read the sense of the working group differently than you do, but as in many things YMMV. It appears I wasn't clear about my intentions for the document. I agree there should not be a different IP layer protocol standardized for each link layer, and for a new draft, I'd want it to take a subset of what is in the larger spec. The end goal, as I tried to say, is a base fho spec with specific applicability to various underlying technologies in separate docs. This is a pragmatic step to solve a subset of the problem as a means to the eventual end goal. Phil > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 02:01:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15961 for ; Thu, 18 Jul 2002 02:01:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15434; Thu, 18 Jul 2002 00:01:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25795; Wed, 17 Jul 2002 23:01:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I60noN015902 for ; Wed, 17 Jul 2002 23:00:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I60nD0015901 for mobile-ip-dist; Wed, 17 Jul 2002 23:00:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I60goN015885; Wed, 17 Jul 2002 23:00:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25621; Wed, 17 Jul 2002 23:00:44 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23877; Thu, 18 Jul 2002 00:00:43 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6I5ucQ24877; Thu, 18 Jul 2002 00:56:38 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 00:56:23 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24051C132F@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Michael Thomas , john.loughney@nokia.com Cc: itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 00:56:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E1F.D87FE740" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E1F.D87FE740 Content-Type: text/plain; charset="iso-8859-1" Michael Thomas wrote: > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > I could not agree more with this point. RO would be a required functionality a number of years back, when the net was in it's infancy and bandwidth availability in the backbone networks (even transoceanic links) were severely limited. We are in the age of OC-192/768s over DWDM. The delay that an IP packet incurs in the core is almost negligible. If bottleneck in the HA is the primary driver for RO, then it is possible to solve the problem with load balancing with DHAAD. My two cents. Regards, Kuntal ------_=_NextPart_001_01C22E1F.D87FE740 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

Michael Thomas wrote:
>    Frankly, I don't think that there is any evidence
>    that the net would be substantially harmed if RO
>    wasn't widely implemented and/or enabled. Indeed,
>    I think  there's good reason to believe that many/most
>    nodes will not enable RO even if their kernel
>    implements it. In some cases, it's likely to be
>    a nice and useful optimization, but I really
>    don't see it as a "if we don't do this the net
>    will fall apart". As such, SHOULD seems like it
>    strikes the right balance.
>
>              Mike
>

I could not agree more with this point. RO would be a required
functionality a number of years back, when the net was in it's
infancy and bandwidth availability in the backbone networks
(even transoceanic links) were severely limited.
We are in the age of OC-192/768s over DWDM. The delay that an IP
packet incurs in the core is almost negligible.
If bottleneck in the HA is the primary driver for RO, then it is
possible to solve the problem with load balancing with DHAAD.

My two cents.

Regards,
Kuntal

------_=_NextPart_001_01C22E1F.D87FE740-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 02:42:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23676 for ; Thu, 18 Jul 2002 02:42:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11830; Thu, 18 Jul 2002 00:43:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08603; Wed, 17 Jul 2002 23:43:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6gCoN016163 for ; Wed, 17 Jul 2002 23:42:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I6gC0T016162 for mobile-ip-dist; Wed, 17 Jul 2002 23:42:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6fwoN016130; Wed, 17 Jul 2002 23:41:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03341; Wed, 17 Jul 2002 23:41:59 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28444; Thu, 18 Jul 2002 00:41:58 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2007E6A906; Thu, 18 Jul 2002 09:41:57 +0300 (EEST) Received: from ericsson.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A80B76A905; Thu, 18 Jul 2002 09:41:44 +0300 (EEST) Message-ID: <3D36638E.3050803@ericsson.fi> Date: Thu, 18 Jul 2002 09:43:26 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: shima Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> <20020718.141850.32635405.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi SHIMA wrote: > Let me add one thing. > > From: Jari Arkko > >>* IPv6 WG has in the past accepted the HAO as a mandatory >> feature for all IPv6 nodes. Arguments have been made, >> however, that the processing of the HAO has been changed >> and the situation may now be different. >> > > In addition, the current draft requires not only HAO but also BE. > This means all IPv6 nodes must implement a new extention header > (mobility header). Correct. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 05:08:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26476 for ; Thu, 18 Jul 2002 05:08:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16008; Thu, 18 Jul 2002 03:08:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27739; Thu, 18 Jul 2002 02:08:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I97joN016995 for ; Thu, 18 Jul 2002 02:07:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I97jHi016994 for mobile-ip-dist; Thu, 18 Jul 2002 02:07:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I97coN016978; Thu, 18 Jul 2002 02:07:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04466; Thu, 18 Jul 2002 02:07:39 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04388; Thu, 18 Jul 2002 03:07:38 -0600 (MDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user36.cisco.com [10.70.82.36]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA19847; Thu, 18 Jul 2002 10:59:48 +0200 (MET DST) From: "Pascal Thubert" To: "=?us-ascii?B?S2VpaWNoaSBTSElNQSAvICI/T2NeZQ==?=" , Cc: , , , Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion Date: Thu, 18 Jul 2002 18:00:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020718.141850.32635405.keiichi@iij.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think I've been a little cryptic: Some devices such as a fridge may be happy to have a minimum set of requirements for IPv6. Other devices such as clustered servers may not be able to maintain a BCE at all because the cluster IP address is shared among all the members of the cluster -- unless they perform a new protocol to distribute the BCEs-. Furthermore, if the cluster uses a dispatcher that is not on the return path, then the dispatcher cannot provide the MIP termination, either. However, if that same dispatcher terminates an IPSEC tunnel, or by other means to be defined later such as piggy backing, it could be possible to trust a Home address option and perform triangular routing. Using a Binding Cache as opposed to piggy backing the BU with each packet assumes that memory scales better than CPU. This seems a reasonable approach, so does delaying the support of piggybacking. But still, we must allow for the case where this trade-off does not apply. Say the dispatcher I just mentioned has a hardware accelerated crypto engine; say it can cache some recent computations in a LRU fashion; say it has limited memory capabilities to keep many BCEs long term; and say it needs to serve requests for a huge amount of unrelated users; in that case, the trade-off is the wrong choice, and triangular may be the best can do, unless the client sources its requests with its CoA, which leads to more open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de facto. If we agree that there can be several levels of support by the CN for RO, then we could define what the behaviour is for each level and how to negotiate that between the CN and the MN. My suggestion was to do that negotiation at RR test time so that no bind support would be necessary unless both parties agree upon bi-directional route optimization. A way to perform that negotiation is to give a meaning to the response to HoTi and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and mostly by accepting an ICMP error as a 'no' response. So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per the draft 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the draft 'Yes' to CoTi only means support for Home Address option but not for Bind Cache 'Yes' to HoTi only does not make sense to me at the moment ??? This is not exactly the way the draft presents things, mostly for the triangular part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the reader believe that MIP could not work without support of the Home Address option by all nodes, "since otherwise communications may be impossible". I believe that this is misleading, and that we should rather explain the different scenarios and pro/cons of each level of support by the CN. I believe we ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. Does that make sense? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Keiichi SHIMA / "?Oc^e Sent: Thursday, July 18, 2002 7:19 AM To: jari.arkko@kolumbus.fi Cc: mat@cisco.com; itojun@iijlab.net; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 09:38:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02346 for ; Thu, 18 Jul 2002 09:38:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08379; Thu, 18 Jul 2002 06:37:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20722; Thu, 18 Jul 2002 06:37:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZAoN017878 for ; Thu, 18 Jul 2002 06:35:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IDZAba017877 for mobile-ip-dist; Thu, 18 Jul 2002 06:35:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZ0oN017855; Thu, 18 Jul 2002 06:35:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09002; Thu, 18 Jul 2002 06:35:02 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18606; Thu, 18 Jul 2002 07:35:01 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 5A0996A907; Thu, 18 Jul 2002 16:35:00 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5E1556A908; Thu, 18 Jul 2002 16:34:56 +0300 (EEST) Message-ID: <3D36A53F.4070106@kolumbus.fi> Date: Thu, 18 Jul 2002 14:23:43 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: summary of HAO, BE processing discussion References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pascal Thubert wrote: > I think I've been a little cryptic: > > Some devices such as a fridge may be happy to have a minimum set of requirements > for IPv6. Other devices such as clustered servers may not be able to maintain a > BCE at all because the cluster IP address is shared among all the members of the > cluster -- unless they perform a new protocol to distribute the BCEs-. > Furthermore, if the cluster uses a dispatcher that is not on the return path, > then the dispatcher cannot provide the MIP termination, either. However, if that > same dispatcher terminates an IPSEC tunnel, or by other means to be defined > later such as piggy backing, it could be possible to trust a Home address option > and perform triangular routing. > > Using a Binding Cache as opposed to piggy backing the BU with each packet > assumes that memory scales better than CPU. This seems a reasonable approach, so > does delaying the support of piggybacking. But still, we must allow for the case > where this trade-off does not apply. Say the dispatcher I just mentioned has a > hardware accelerated crypto engine; say it can cache some recent computations in > a LRU fashion; say it has limited memory capabilities to keep many BCEs long > term; and say it needs to serve requests for a huge amount of unrelated users; > in that case, the trade-off is the wrong choice, and triangular may be the best > can do, unless the client sources its requests with its CoA, which leads to more > open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de > facto. > > If we agree that there can be several levels of support by the CN for RO, then > we could define what the behaviour is for each level and how to negotiate that > between the CN and the MN. My suggestion was to do that negotiation at RR test > time so that no bind support would be necessary unless both parties agree upon > bi-directional route optimization. > > A way to perform that negotiation is to give a meaning to the response to HoTi > and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and > mostly by accepting an ICMP error as a 'no' response. I've thought about this in the context non-RR RO security schemes. We can already do this, by adding a new mobility option to be carried by hoti and then returned by hot if the peer supports it. > So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir > MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per > the draft > 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the > draft Good. > 'Yes' to CoTi only means support for Home Address option but not for Bind Cache > 'Yes' to HoTi only does not make sense to me at the moment ??? Do we really need this kind of negotiation just to figure out whether the receiver can support HAO or not? If yes, I think it would be much better to have the RO and HAO support together. That is, the peer supports HAO if and only if it supports RO and RR. > This is not exactly the way the draft presents things, mostly for the triangular > part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the > reader believe that MIP could not work without support of the Home Address > option by all nodes, "since otherwise communications may be impossible". I Uh... that's not right. > believe that this is misleading, and that we should rather explain the different > scenarios and pro/cons of each level of support by the CN. I believe we Yes. > ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. > > Does that make sense? Yes. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 10:26:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03321 for ; Thu, 18 Jul 2002 10:26:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16734; Thu, 18 Jul 2002 08:26:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00595; Thu, 18 Jul 2002 07:26:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEPdoN018135 for ; Thu, 18 Jul 2002 07:25:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IEPdwu018134 for mobile-ip-dist; Thu, 18 Jul 2002 07:25:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEPVoN018119; Thu, 18 Jul 2002 07:25:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19596; Thu, 18 Jul 2002 07:25:31 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14761; Thu, 18 Jul 2002 08:25:31 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g6IEP6S02473; Thu, 18 Jul 2002 09:25:06 -0500 (CDT) Message-ID: <3D36CFE3.9090605@alcatel.com> Date: Thu, 18 Jul 2002 09:25:39 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas CC: john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael, I do not understand why you are insisting on SHOULD? If IETF is not against having such MUSTs as in this case, let's have it. How can a revolutionary technology such as MIPv6 allow HA reverse tunneling like MIPv4 does? Another benefit will be to mandate HAO in any new implementations. Becasue of all these, I think that we should (or MUST) keep the MUST there, what the heck? Regards, Michael Thomas wrote: >john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 10:31:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03456 for ; Thu, 18 Jul 2002 10:31:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19415; Thu, 18 Jul 2002 08:31:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21038; Thu, 18 Jul 2002 07:31:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEUdoN018284 for ; Thu, 18 Jul 2002 07:30:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IEUdBD018283 for mobile-ip-dist; Thu, 18 Jul 2002 07:30:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEUaoN018276 for ; Thu, 18 Jul 2002 07:30:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01931 for ; Thu, 18 Jul 2002 07:30:37 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05185 for ; Thu, 18 Jul 2002 07:30:36 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA21330 for ; Thu, 18 Jul 2002 07:30:36 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA15625 for ; Thu, 18 Jul 2002 07:30:49 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 18 Jul 2002 09:30:35 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 18 Jul 2002 09:30:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Alper, Please find my inline reply. regards, ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, July 17, 2002 9:40 PM To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Hi Ajoy, > Hi Ajoy, > > > Ajoy-> Target trigger will be suitable for cellular > > networks. BTW, even in case of WLAN, you can receive > > L2-TT trigger at nAP. L2TT (Re-association Request) can > > provide nAP the L2 address of the oldAP as well as L2 > > address of the mobile node. If we implement FA function > > Does re-association also apply to BSS mode, or when > the station moves between two different ESS? > > If it is only used when the station moves from one AP > to another in the same ESS, this is not as interesting, > because the mobility is already handled at link-layer > in 802.11b. > > Ajoy-> Mostly I have seen Re-association Request is sent > whenever an MN moves from one AP to other AP in the same ESS. > This is partly because IAPP handles intra-ESS handoff. Exactly.... So, IAPP already takes care of the mobility, no need for higher layer mobility management in that particular case. > I believe this is an implementation issue and > can be easily extended, if Mobile/IP provides appropriate hooks. I wonder if the spec allows/enables use of re-association messages in BSS mode. And than, if client is already sending a re-association message, why not use ESS and IAPP for this? Why would people need another protocol that looks like IAPP on the same network.. Ajoy-> Typically (I think) the IP address of MN is topologically not correct after inter ESS handoff. This why Mobile/IP is required. BTW, this mobility should not be handled by IAPP. Hope this helps. > > > at AP, then this becomes an implementation issue. > > If not, then you need to define some protocol between > > AP and AR which can be addressed in separate document. > > http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt > > ... > > > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does > > not work for network initiated trigger. BTW, based upon our > > implementation, we found anticipated handover does not provide > > good performance on cellular link. Hence, anticipated handover > > is not going to address fast handoff need for various cellular networks. > > Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation? > > Ajoy-> We implemented FMIPv4. But I do not believe FMIPv6 implementation > will provide substantially better performance. More or less the basic > idea is same. I think the part of the problem is high RTT of 3G wireless > link (MN to AR). So, adding lots of signaling messages over the high RTT > link will require sufficiently higher anticipation time. If you keep > very high anticipation time, handover may not be consistently > reliable. > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and then applying to "anticipated FMIPv6" without experimenting is not a good idea. Protocols are sufficiently different to make considerable performance differences. Ajoy-> I think claiming something works without proper data and argument is also not a good idea. BTW, do you agree that due to higher RTT of cellular link, FMIPv6 will require higher anticipation time ? As you increase anticipation time, the likelihood of handover failure will increase. I do not think this has anything to do with FMIPv6 or FMIPv4. You will observe similar behavior in either case. alper > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 10:54:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03938 for ; Thu, 18 Jul 2002 10:54:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17068; Thu, 18 Jul 2002 07:52:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10901; Thu, 18 Jul 2002 07:52:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEpQoN018503 for ; Thu, 18 Jul 2002 07:51:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IEpQbs018502 for mobile-ip-dist; Thu, 18 Jul 2002 07:51:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEpIoN018486; Thu, 18 Jul 2002 07:51:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10649; Thu, 18 Jul 2002 07:51:19 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16442; Thu, 18 Jul 2002 07:51:18 -0700 (PDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user276.cisco.com [10.70.83.20]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA10522; Thu, 18 Jul 2002 16:50:57 +0200 (MET DST) From: "Pascal Thubert" To: "Behcet Sarikaya" , "Michael Thomas" Cc: , , , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 23:51:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D36CFE3.9090605@alcatel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Face it: Many of today's large web servers will not want to maintain binding caches. Because: - They are clustered (see my previous mail on this thread) - Visits are short and unrelated (the caches are not reused) - RR reduces the throughput and the response time - They may even blindly accept the Home Address option since the AAA takes place at session level anyway using cookies and such. How much of the global IP traffic does this represent today? What will mobile devices do at least in the short term? We must provide a way for servers to simply and politely decline RO. We may want to permit triangular routing. The minimum we can do to ease IPv6 transition is at least to allow the current v4 applications to run in equivalent conditions. It's a SHOULD. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Behcet Sarikaya Sent: Thursday, July 18, 2002 4:26 PM To: Michael Thomas Cc: john.loughney@nokia.com; itojun@iijlab.net; vijayd@iprg.nokia.com; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Michael, I do not understand why you are insisting on SHOULD? If IETF is not against having such MUSTs as in this case, let's have it. How can a revolutionary technology such as MIPv6 allow HA reverse tunneling like MIPv4 does? Another benefit will be to mandate HAO in any new implementations. Becasue of all these, I think that we should (or MUST) keep the MUST there, what the heck? Regards, Michael Thomas wrote: >john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 17:07:45 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12728 for ; Thu, 18 Jul 2002 17:07:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00704; Thu, 18 Jul 2002 15:08:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28671; Thu, 18 Jul 2002 14:07:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IL6YoN020191 for ; Thu, 18 Jul 2002 14:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IL6YMa020190 for mobile-ip-dist; Thu, 18 Jul 2002 14:06:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IL6QoN020175; Thu, 18 Jul 2002 14:06:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22469; Thu, 18 Jul 2002 14:06:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16832; Thu, 18 Jul 2002 14:06:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1C9226A907; Fri, 19 Jul 2002 00:06:19 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 193D26A905; Fri, 19 Jul 2002 00:06:14 +0300 (EEST) Message-ID: <3D372E33.9010701@kolumbus.fi> Date: Fri, 19 Jul 2002 00:08:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: Behcet Sarikaya , Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pascal Thubert wrote: > Face it: Many of today's large web servers will not want to maintain binding > caches. Because: > - They are clustered (see my previous mail on this thread) > - Visits are short and unrelated (the caches are not reused) > - RR reduces the throughput and the response time The current spec allows CNs to decline a RO/RR request. This is of course necessary, we couldn't mandate that they have sufficient memory etc. in all cases to handle these requests. > - They may even blindly accept the Home Address option since the AAA takes place > at session level anyway using cookies and such. Most likely we can't do this. Earlier analysis indicated that unverified home address option could lead to reflection attacks. > How much of the global IP traffic does this represent today? What will mobile > devices do at least in the short term? We must provide a way for servers to > simply and politely decline RO. We may want to permit triangular routing. The > minimum we can do to ease IPv6 transition is at least to allow the current v4 > applications to run in equivalent conditions. Yes, and they can decline RO already now. Triangular routing will only be allowed under a special condition (existing SA), which I think is probably not compatible with your scenario of web servers. > It's a SHOULD. I'm not really arguing against that... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 22:18:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19057 for ; Thu, 18 Jul 2002 22:18:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02775; Thu, 18 Jul 2002 20:18:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09472; Thu, 18 Jul 2002 19:18:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2GmoN021002 for ; Thu, 18 Jul 2002 19:16:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J2GlN3021001 for mobile-ip-dist; Thu, 18 Jul 2002 19:16:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2GeoN020985; Thu, 18 Jul 2002 19:16:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16733; Thu, 18 Jul 2002 19:16:42 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06643; Thu, 18 Jul 2002 20:16:40 -0600 (MDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user259.cisco.com [10.70.83.3]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id EAA12891; Fri, 19 Jul 2002 04:16:32 +0200 (MET DST) From: "Pascal Thubert" To: "Jari Arkko" Cc: , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Fri, 19 Jul 2002 11:16:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D372E33.9010701@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jari: What I'm trying to get here: 1) SHOULD in 9.1. I support a requirement introduced in this thread. The requirement is to legalize hosts that would not support MIP for valid reasons. I provided examples where I think it's needed. I also believe there should be a little rewording in section 9.1 to come with it. 2) Minimize the content of the SHOULD. I propose a slight change in the draft in order to decline RO at RR test time in an architected fashion as opposed to side effect of ICMP errors. At this point, the binding flow is not part of the SHOULD anymore. Since 9.4.6 should not occur, I suppose that an ICMP error would be fine in that case. The problem is that the politically correct way to decline RO at the moment seems to be binding Ack with code 130 Insufficient resources (correct?), which requires support for BU. Since we are foreseeing the overloading of the RR test as a capability negociation mechanism (e.g. C1), could we not just architect something to negotiate Bind capabilities there already? The discussion about whether binding cache and Home Address option are necessarily coupled is yet an other one, which is related to C1 and C2. I tried to give an example where they could be separated by using piggy backing instead of an SA, but that discussion is not needed right now. I started that to decouple the RR test and the binding flow a little bit more. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Jari Arkko Sent: Thursday, July 18, 2002 11:08 PM To: Pascal Thubert Cc: Behcet Sarikaya; Michael Thomas; john.loughney@nokia.com; itojun@iijlab.net; vijayd@iprg.nokia.com; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Pascal Thubert wrote: > Face it: Many of today's large web servers will not want to maintain binding > caches. Because: > - They are clustered (see my previous mail on this thread) > - Visits are short and unrelated (the caches are not reused) > - RR reduces the throughput and the response time The current spec allows CNs to decline a RO/RR request. This is of course necessary, we couldn't mandate that they have sufficient memory etc. in all cases to handle these requests. > - They may even blindly accept the Home Address option since the AAA takes place > at session level anyway using cookies and such. Most likely we can't do this. Earlier analysis indicated that unverified home address option could lead to reflection attacks. > How much of the global IP traffic does this represent today? What will mobile > devices do at least in the short term? We must provide a way for servers to > simply and politely decline RO. We may want to permit triangular routing. The > minimum we can do to ease IPv6 transition is at least to allow the current v4 > applications to run in equivalent conditions. Yes, and they can decline RO already now. Triangular routing will only be allowed under a special condition (existing SA), which I think is probably not compatible with your scenario of web servers. > It's a SHOULD. I'm not really arguing against that... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 18 22:59:07 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20157 for ; Thu, 18 Jul 2002 22:59:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06494; Thu, 18 Jul 2002 19:51:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25288; Thu, 18 Jul 2002 19:51:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2oMoN021265 for ; Thu, 18 Jul 2002 19:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J2oMlt021264 for mobile-ip-dist; Thu, 18 Jul 2002 19:50:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2oJoN021257 for ; Thu, 18 Jul 2002 19:50:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18848 for ; Thu, 18 Jul 2002 19:50:21 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11148 for ; Thu, 18 Jul 2002 20:50:20 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KKA2STUMHM8ZPGI7@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 19 Jul 2002 12:49:56 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id C084C12C00F; Fri, 19 Jul 2002 02:49:55 +0000 (/etc/localtime) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 39E3912C00D; Fri, 19 Jul 2002 12:21:56 +1000 (EST) Date: Fri, 19 Jul 2002 11:21:56 +0900 From: Brett Pentland Subject: [mobile-ip] Clarification sought on role of MIN_DELAY_BETWEEN_RAS To: mobile-ip@sunroof.eng.sun.com Message-id: <125608d1254b64.1254b64125608d@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi folks, I was just wondering if anyone can confirm that the protocol constant "MIN_DELAY_BETWEEN_RAS" defined in RFC2461 as 3 seconds only relates to multicast RAs sent in response to an RS and thus is unrelated to the configuration variable "MinRtrAdvInterval" for unsolicited multicast RAs which is redefined in the Mobile IPv6 I-D. Thanks, Brett. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 19 00:30:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21277 for ; Fri, 19 Jul 2002 00:30:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06463; Thu, 18 Jul 2002 22:30:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10652; Thu, 18 Jul 2002 21:30:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4TGoN021661 for ; Thu, 18 Jul 2002 21:29:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J4TGEj021660 for mobile-ip-dist; Thu, 18 Jul 2002 21:29:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4TDoN021653 for ; Thu, 18 Jul 2002 21:29:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10010 for ; Thu, 18 Jul 2002 21:29:14 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10170 for ; Thu, 18 Jul 2002 22:29:12 -0600 (MDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g6J4S9211940 for ; Fri, 19 Jul 2002 12:28:09 +0800 (SGT) Received: from infd6 ([192.168.133.102]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0GZH005CQB5W89@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Fri, 19 Jul 2002 12:30:00 +0800 (SGT) Date: Fri, 19 Jul 2002 12:37:45 +0800 From: zhang zhishou Subject: [mobile-ip] questions on binding update To: Mobileip Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi, folks: I am newbie in Mobile IP and IPsec. Please forgive me for my stupid questions. Why is IPsec not used for binding updates between MN and CN? If this is topic that was already discussed and clarified, please give me some reference, so that I could catch up with it. thanks in advance !! zzs From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 19 00:57:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21590 for ; Fri, 19 Jul 2002 00:57:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14593; Thu, 18 Jul 2002 22:57:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15906; Thu, 18 Jul 2002 21:57:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4unoN021814 for ; Thu, 18 Jul 2002 21:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J4un78021813 for mobile-ip-dist; Thu, 18 Jul 2002 21:56:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4ukoN021806 for ; Thu, 18 Jul 2002 21:56:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14357 for ; Thu, 18 Jul 2002 21:56:47 -0700 (PDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14326 for ; Thu, 18 Jul 2002 22:56:47 -0600 (MDT) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 96E0B12; Fri, 19 Jul 2002 08:00:28 +0300 (EEST) Message-ID: <3D379C0E.5080006@nomadiclab.com> Date: Fri, 19 Jul 2002 07:56:46 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020712 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhang zhishou Cc: Mobileip Subject: Re: [mobile-ip] questions on binding update References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit zhang zhishou wrote: > Hi, folks: > > I am newbie in Mobile IP and IPsec. Please forgive me for my stupid > questions. > > Why is IPsec not used for binding updates between MN and CN? > If this is topic that was already discussed and clarified, please give me > some reference, so that I could catch up with it. Short answer: Problems with scalability in key management. Longer answer: How do you arrange a pair of SAs between two arbitrary nodes that may not have anything to do with each other? Well, you could have a global PKI, but such thing does not exist today, and even if it did, you would need to make sure that the PKI carries the right kind of *authorization* information, in addition to public keys for authentication. Still longer answer: There are lots of related text, but I don't know if there is anything that just discusses your question and nothing else. There is something in the earlier texts, e.g. - Pekka Nikander, An Address Ownership Problem in IPv6, work in progress, Internet-Draft (expired), February 2001. http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt - Michael Roe, Greg O'Shea, "Child-proof Authentication for Mobile IPv6," CCR, April 2001, http://www.research.microsoft.com/~mroe/ccr2001.pdf --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 19 04:34:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03292 for ; Fri, 19 Jul 2002 04:34:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13290; Fri, 19 Jul 2002 02:34:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02004; Fri, 19 Jul 2002 01:34:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8XfoN022227 for ; Fri, 19 Jul 2002 01:33:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J8XeZm022226 for mobile-ip-dist; Fri, 19 Jul 2002 01:33:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8XboN022219; Fri, 19 Jul 2002 01:33:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17499; Fri, 19 Jul 2002 01:33:39 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14273; Fri, 19 Jul 2002 02:33:38 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6J8XXi12149; Fri, 19 Jul 2002 11:33:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Jul 2002 11:32:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 11:32:57 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Jul 2002 11:32:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579E@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuay+d+/st/HV1RuaOF1btR7N9uQAk10Sw To: , , Cc: , , , , X-OriginalArrivalTime: 19 Jul 2002 08:32:57.0411 (UTC) FILETIME=[E25CF930:01C22EFE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6J8XcoO022220 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Pascal, > Face it: Many of today's large web servers will not want to > maintain binding caches. We are not talking about forcing deployments to use RO, but to have to code to support it & have code to support the HAO. Think of it this way, this might always be a premium service a web service could provide. If their OS has the code, they could selectively support RO to premium clients. John From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 19 04:38:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03359 for ; Fri, 19 Jul 2002 04:38:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16332; Fri, 19 Jul 2002 02:38:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18160; Fri, 19 Jul 2002 01:38:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8bRoN022371 for ; Fri, 19 Jul 2002 01:37:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J8bRCU022370 for mobile-ip-dist; Fri, 19 Jul 2002 01:37:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8bNoN022363 for ; Fri, 19 Jul 2002 01:37:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06553 for ; Fri, 19 Jul 2002 01:37:25 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15963 for ; Fri, 19 Jul 2002 02:37:24 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6J8b4Y03996; Fri, 19 Jul 2002 10:37:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12729; Fri, 19 Jul 2002 10:37:04 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6J8axGF075211; Fri, 19 Jul 2002 10:37:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207190837.g6J8axGF075211@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: zhang zhishou cc: Mobileip Subject: Re: [mobile-ip] questions on binding update In-reply-to: Your message of Fri, 19 Jul 2002 12:37:45 +0800. Date: Fri, 19 Jul 2002 10:36:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Why is IPsec not used for binding updates between MN and CN? => it may be used but it is not (more) the default solution because it needs a proper authorization and some kind of global PKI. I have a ton of mails about this in my laptop but I am currently in the Narita Express (http://www.nex.v6pc.jp/) so it is a bit hard to send them... When you'll know well please read my draft about IPsec and Mobile iPv6: draft-dupont-ipsec-mipv6-01.txt Regards Francis.Dupont@enst-bretagne.fr Ps I've seen an answer from Pekka, so you should already have an idea about the authorization issue. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 19 18:46:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18541 for ; Fri, 19 Jul 2002 18:46:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07198; Fri, 19 Jul 2002 16:47:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21432; Fri, 19 Jul 2002 15:46:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JMjgoN023958 for ; Fri, 19 Jul 2002 15:45:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6JMjf8r023957 for mobile-ip-dist; Fri, 19 Jul 2002 15:45:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JMjcoN023950; Fri, 19 Jul 2002 15:45:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21064; Fri, 19 Jul 2002 15:45:40 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11765; Fri, 19 Jul 2002 16:45:39 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Jul 2002 15:45:38 -0700 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F76.00C6C21B" x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 19 Jul 2002 15:45:38 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF221@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Re: summary of HAO, BE processing discussion Thread-Index: AcIuJpR4gKOJXbemTYG0aTQaWrrv9QBTsxzQ From: "Mohan Parthasarathy" To: , "shima" Cc: , , , X-OriginalArrivalTime: 19 Jul 2002 22:45:38.0849 (UTC) FILETIME=[00F4E110:01C22F76] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C22F76.00C6C21B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 > >=20 > >>* IPv6 WG has in the past accepted the HAO as a mandatory > >> feature for all IPv6 nodes. Arguments have been made, > >> however, that the processing of the HAO has been changed > >> and the situation may now be different. > >> > >=20 > > In addition, the current draft requires not only HAO but=20 > also BE. This=20 > > means all IPv6 nodes must implement a new extention header=20 > (mobility=20 > > header). >=20 >=20 > Correct. >=20 If you read section 9.4.6, "Sending Binding Errors", yes it is correct. But reading section 6.3 "Home Address option", it says that if a node does not understand this option, it should return ICMP parameter problem. Are these in conflict ? thanks mohan ------_=_NextPart_001_01C22F76.00C6C21B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: summary of HAO, BE processing = discussion

 
> >
> >>* IPv6 WG has in the past accepted the = HAO as a mandatory
> >>   feature for all IPv6 nodes. = Arguments have been made,
> >>   however, that the = processing of the HAO has been changed
> >>   and the situation may now = be different.
> >>
> >
> > In addition, the current draft requires not = only HAO but
> also BE. This
> > means all IPv6 nodes must implement a new = extention header
> (mobility
> > header).
>
>
> Correct.
>
If you read section 9.4.6, "Sending Binding = Errors", yes it is
correct. But reading section 6.3 "Home Address = option", it says
that if a node does not understand this option, it = should return
ICMP parameter problem. Are these in conflict = ?

thanks
mohan

------_=_NextPart_001_01C22F76.00C6C21B-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 20 05:53:54 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07788 for ; Sat, 20 Jul 2002 05:53:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08835; Sat, 20 Jul 2002 03:54:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20387; Sat, 20 Jul 2002 02:53:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9r1oN025160 for ; Sat, 20 Jul 2002 02:53:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6K9r0vr025159 for mobile-ip-dist; Sat, 20 Jul 2002 02:53:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9qtoN025149 for ; Sat, 20 Jul 2002 02:52:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24322 for ; Sat, 20 Jul 2002 02:52:57 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03585 for ; Sat, 20 Jul 2002 03:52:56 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098H08J>; Sat, 20 Jul 2002 05:52:55 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46012031CF@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'carlw@docomolabs-usa.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] LMM draft comments Date: Sat, 20 Jul 2002 05:52:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Carl, Here is some input into the LMM requirements draft. An additional requirement into LMM is the ability to aggregate as well as localise hand-off for multiple HoAs. A MN that has more than one HoA presently has to update multiple global HAs in parallel on each hand-off because traditional MIP signalling is HoA specific. If LMM only addresses localisation then each local hand-off will still need to be replicated. Multiple HoAs is a requirement in 3G and non-MIP mechanisms are presently used for LMM in 3G to enable a MN to hand-off all its concurrent sessions at once (RNC relocation etc). LMM needs to reproduce this capability so that the MN can use LMM aggregate signalling to avoid sending multiple parallel hand-off signals. One obvious use for two HoAs is that one is used for global remote access (inter-domain mobility) and one for local access (intra-domain mobility). This enables a foreign operator to sell optimised Internet access via LMM whilst in addition scalably supporting a users corporate access. I would therefore also further suggest an additional requirement should be that LMM mechanisms be able to support both local and remote services. As both local and remote services are on the MN and both use MIP, not considering or including this capability in the requirements is I think a hole. Additional motivation for LMM is that of operator decoupling. If a MN is in a foreign domain then the hand-off performance in that foreign domain should not / must not be dependent on the availability and dimensioning of links and nodes, including the global HA, in a different domain. LMM serves to ensure that the foreign domain is solely in a position to decide the performance of the hand-off. This is particularly important as HAs become increasingly deployed into SMEs and home networks, potentially over on-demand links. Introduction Bottom page 2 it states that binding updates during RO are issued by the MN which is an MIPv6 specific comment. In MIPv4 they are issued by the HA. I would instead generalise this statement to simply say an authorized MIP node issues the BU.. Terminology - wrt Nested MIP I am a little concerned about the use of the term 'coverage area' which may easily be confused with L2 wireless use of 'coverage area'. The Local Coverage Area is called a Region in Nested MIP (local mobility region - the region of local mobility) and the specific Local Mobility Agents are a local HA (also known as the Regional Mobility Agent) and the access routers (FA in v4). The term global HA is used therefore to distinguish it from the local HA. I am however happy to accept the terminology in LMM for the purposes of the LMM draft, but the particular terminology in Nested MIP is I feel better suited to the centralised topology in that solution. I hope that that is ok with you. You may however wish to update the LMM terminology in the light of these comments. 3.4.3 "The LMM framework MUST NOT create single points of failure in the network. The current access router would be excluded from this requirement." The global and local HAs assigned to this MN must also be excluded from this requirement. However, a better to way to describe the requirement might be to simply state that the solution must have minimal, preferably zero impact on the availability of the MN / global HA / CN traffic and signalling. NEW 3.4.9 The LMM framework must ensure that the LMAs can be placed so as to avoid locations that are bandwdith constrained or costly, and which minimise signalling and packet redirection over such links. Such a requirement is critical given the topologies in cellular systems whereby basestations are typically connected to the core network over expensive links. **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 20 05:55:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07809 for ; Sat, 20 Jul 2002 05:55:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27042; Sat, 20 Jul 2002 02:54:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11647; Sat, 20 Jul 2002 02:54:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9qxoN025157 for ; Sat, 20 Jul 2002 02:52:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6K9qxx4025156 for mobile-ip-dist; Sat, 20 Jul 2002 02:52:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9qsoN025142 for ; Sat, 20 Jul 2002 02:52:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20324 for ; Sat, 20 Jul 2002 02:52:56 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08674 for ; Sat, 20 Jul 2002 03:52:55 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098H082>; Sat, 20 Jul 2002 05:52:53 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46012031CD@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue 63: Multicast Date: Sat, 20 Jul 2002 05:52:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks Eric, The mist is clearing... -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: 17 July 2002 20:09 To: Alan O'Neill Cc: 'Erik Nordmark'; 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Issue 63: Multicast > However, it is not clear at the moment whether foreign network multicast > should ultimately use the the CoA or the HoA as the source address, so we > should do that work before giving the MN the option of origination into the > foreign system because of forwards compatibility. The current archiecture requires that the CoA is used as a source when sending multicast packets on the foreign link and the HoA when reverse tunneling them through the HA. An example of this architecture is this statement in draft-ietf-ipv6-default-addr-select: For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. (And, as an aside, the precense of ingress filtering routers apply the same restriction to unicast packets from mobile nodes that are away from home). AWO> Sure - I fully appreciate that the present barriers to using the HoA as a foreign multicast source address are significant and hence why I am not suggesting adding that to the spec. These barriers additionally include the RPF check of course. Note though that hybrid multicast does not break either requirement, but again I also have some concerns with adding that to the spec. My only concern is whether the use of the CoA in MIPv6 should be allowed in the base spec given the thrashing risk which you comment on below. The current architecture of IPv6 allows the CoA address and is fine because their is no mobility. My concern is limited to MIPv6 which has its own additional architecture given that mobility, and I believe the draft 18 architecture has problems that are of concern. IPv6 also has a routing header but in the case of mobility a special type header was needed instead..mobility changes things.. So all I am requesting here is that draft 18 be amended if there is a problem, and as has happened before, IPv6 architecture should not just be accepted within MIPv6 without consideration of new mobility specific problems...In addition, IPv6 architecture will change as we learn more..I should also mention that given this issue also exists for MIPv4, there is less of an 'architectural' barrier there because the MN is not prohibited in IPv4 from using the HoA as a source address on a foreign link. Perhaps there are possible future architectures that do not have these constraints, and perhaps it makes sense exploring them to provide different performance for multicast for MNs. But I suspect this would result in added total complexity to the system. The point is that the draft is about the current architecture. AWO> And I certainly do not want to add additional complexity unless it is necessary..But I would rather have some additional complexity than a useless or unstable feature, in the same way that RR complexity had to be added to RO for different but important reasons. > I don't understand how a potential thrashing problem can be allowed to > progress through the base spec. Maybe you don't believe this exists, or is > that you believe we can trust vendors and operators to do the right thing ? I don't understand why mobility creates a unique problem here. IP traffic is known to be bursty, thus the multicast routing system needs to be able to deal with bursty sources on widely varying time scales. A mobile node moving around and using the CoA as the source just looks like multiple (bursty) sources that are not moving. AWO> Ok - so lets concentrate on this point, so that the wg can agree if there is, or is not, a problem. We can then come back to discuss / address the barriers wrt solving it. I have a couple of other jobs I have to get done first (other MIPwg stuff) and then I'll send some e-mails explaining where this is similar yet very different from the bursty source problem in conjunction with different multicast protocols. I'll also copy in some multicast experts so we can ensure we isolate the correct issues and get best advice on progression. I hope that is ok. > Clarifying this would help...Maybe this could alternatively be addressed > with some applicability words that specifically does not rule out hybrid or > otheruses of the HoA as a foreign multicast source address ? Using the HoA as source on the visited link doesn't work due to RPF checks in the current archiecture as you already pointed out. AWO> Absolutely..no disagreement here. The hybrid approach might though give us a working feature..and if none of these work then we have to either restrict the base spec, add applicability stuff and/or fix the architecture(s).. Regards, Alan. **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 20 09:50:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10305 for ; Sat, 20 Jul 2002 09:50:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22468; Sat, 20 Jul 2002 07:50:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18162; Sat, 20 Jul 2002 06:50:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KDnjoN025536 for ; Sat, 20 Jul 2002 06:49:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6KDnjxI025535 for mobile-ip-dist; Sat, 20 Jul 2002 06:49:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KDngoN025528 for ; Sat, 20 Jul 2002 06:49:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18006 for ; Sat, 20 Jul 2002 06:49:42 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19766 for ; Sat, 20 Jul 2002 07:49:41 -0600 (MDT) Received: from zhanghaofeng ([202.204.12.140]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id WAA18531 for ; Sat, 20 Jul 2002 22:55:16 +0900 (CDT) Message-ID: <001701c23072$03476210$8c0cccca@zhanghaofeng> From: "Zhang haofeng" To: References: <3D3317D6.58ADBEE0@iprg.nokia.com> Subject: Re: [mobile-ip] minor comments on draft 18 Date: Sat, 20 Jul 2002 21:49:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am also wondering how can the MN know the amount of traffic with CN justifies the use of route optimization or not. In my opinion, once a MN receives a Binding Refresh Request it SHOULD start a RR procedure. If that, is it proper? Regards Haofeng ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Monday, July 15, 2002 11:43 AM Subject: [mobile-ip] minor comments on draft 18 > 1) > Section 6.1.2 > > When a mobile node receives a > > packet containing a Binding Refresh Request message and there > > already exists a Binding Update List entry for the source of the > > Binding Refresh Request, it MAY start a return routability procedure > > (see Section 5.2) if it believes the amount of traffic with the > > correspondent justifies the use of route optimization. From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 20 18:44:23 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16813 for ; Sat, 20 Jul 2002 18:44:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14427; Sat, 20 Jul 2002 15:42:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10435; Sat, 20 Jul 2002 15:42:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KMfroN026337 for ; Sat, 20 Jul 2002 15:41:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6KMfrTp026336 for mobile-ip-dist; Sat, 20 Jul 2002 15:41:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KMfioN026321; Sat, 20 Jul 2002 15:41:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14946; Sat, 20 Jul 2002 15:41:45 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21660; Sat, 20 Jul 2002 16:41:44 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AEEC64B22; Sun, 21 Jul 2002 07:41:37 +0900 (JST) To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: charliep's message of Wed, 17 Jul 2002 17:35:15 MST. <3D360D42.A934AA34@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Sun, 21 Jul 2002 07:41:37 +0900 Message-Id: <20020720224137.AEEC64B22@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >The home address option is the same in format as the >previous version. The additional requirement now is >only that now it's required to be secured somehow. no it is not. also option type # got changed draft 04-06: type, length and an IPv6 address, type # = "196???" draft 07: type, length, an IPv6 address and suboptions, type # = "196???" draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 draft 17-18: type, length and an IPv6 address, type # = 201 note that existence/non-existence of suboption will affect validation of incoming messages. no wonder vendors ship without HAO support, it is impossible to support something that changes this often. as for *BSD/KAME, it is decided that we won't merge anything related to mobile-ip6 into main *BSD distribution until mobile-ip6 becomes RFC (so it won't show up onto ExtremeWare, JunOS, MacOS X, ...). if i remember correctly WinXP is shipping with HAO support, i'm not sure which draft it is based. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 11:36:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07033 for ; Sun, 21 Jul 2002 11:36:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27274; Sun, 21 Jul 2002 09:36:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20271; Sun, 21 Jul 2002 08:36:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFZVoN028093 for ; Sun, 21 Jul 2002 08:35:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LFZVW0028092 for mobile-ip-dist; Sun, 21 Jul 2002 08:35:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFZSoN028085 for ; Sun, 21 Jul 2002 08:35:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20207 for ; Sun, 21 Jul 2002 08:35:29 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04033 for ; Sun, 21 Jul 2002 09:35:28 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6LFZKC01268; Sun, 21 Jul 2002 17:35:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA22469; Sun, 21 Jul 2002 17:35:21 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6LFZJGF084332; Sun, 21 Jul 2002 17:35:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207211535.g6LFZJGF084332@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: ipsec@lists.tislabs.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Re: IPsec and Mobile IPv6 In-reply-to: Your message of Wed, 17 Jul 2002 08:53:48 +0300. <3D35066C.4060900@piuha.net> Date: Sun, 21 Jul 2002 17:35:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I've revisited your classification: 1A) [Already in IPsec specs] C1, C2, G, H, I, J, L1, L2, M, Q, R 1B) [Already in Mobile IPv6 specs] A, E1, E2, E3, O 2) [Fixes for Mobile IPv6] N, P 3) [Fixes for IPsec in a Mobile IPv6 context] none 4) [IPsec improvements for Mobile IPv6] B, F, K 5) [Architectural long-term recommendations] Appendix B 6) [Other stuffs] D, Appendix D Is there anything in the MIPv6 documents that you'd like to clarify in class 1? => I believe we should make the mobile VPN a subset of Mobile IPv6. Mostly we have to relax the usage of tunnels between a CN and a MN, in current specifications we have for the CN: - if the packet is not genuine (i.e., is forwarded): * nothing if the CN is not the HA * tunneling if the CN is the HA - lookup in the binding cache per CN address * nothing is no entry found, fallback to the previous case on the HA * routing header if a valid entry is found. On a mobile VPN CNs have no BC and the SG takes the role of the HA but it puts all packets in the tunnel, so I propose to relax the Mobile IPv6 rules in two ways: - tunneling may replace the routing header (this is useful for the mobile to mobile case too) - the only mandatory usage of a routing header is for signaling (i.e., for genuine packets with a mobile header). For the MN, the obvious thing is to authorize tunneling in place of the HAO for non-signaling traffic. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 12:00:43 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07242 for ; Sun, 21 Jul 2002 12:00:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20870; Sun, 21 Jul 2002 08:59:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22361; Sun, 21 Jul 2002 08:59:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFw8oN028242 for ; Sun, 21 Jul 2002 08:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LFw8ah028241 for mobile-ip-dist; Sun, 21 Jul 2002 08:58:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFw4oN028234; Sun, 21 Jul 2002 08:58:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18964; Sun, 21 Jul 2002 08:58:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28870; Sun, 21 Jul 2002 09:58:06 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA22731; Sun, 21 Jul 2002 08:58:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6LFw3e18692; Sun, 21 Jul 2002 08:58:03 -0700 X-mProtect: <200207211558> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.111, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxI4hsh; Sun, 21 Jul 2002 08:57:59 PDT Message-ID: <3D3AD97F.F5D1927A@iprg.nokia.com> Date: Sun, 21 Jul 2002 08:55:43 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020720224137.AEEC64B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Itojun, Your argument is not very convincing: itojun@iijlab.net wrote: > >The home address option is the same in format as the > >previous version. The additional requirement now is > >only that now it's required to be secured somehow. > > no it is not. also option type # got changed > draft 04-06: type, length and an IPv6 address, type # = "196???" > draft 07: type, length, an IPv6 address and suboptions, > type # = "196???" These drafts are many years old. I reckon the base IPv6 specifications have a number of features that have changed more than the HAO option has changes since these very old drafts. > > draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 > draft 17-18: type, length and an IPv6 address, type # = 201 There is no difference. There were no valid suboptions defined for earlier drafts, even though the field was shown as possibly there for future suboptions. In the drafts after 16, a reasonable implementation should still allow for future suboptions that don't exist yet. > no wonder vendors ship without HAO support, it is impossible to > support something that changes this often. as for *BSD/KAME, it is > decided that we won't merge anything related to mobile-ip6 into main > *BSD distribution until mobile-ip6 becomes RFC (so it won't show up > onto ExtremeWare, JunOS, MacOS X, ...). > if i remember correctly WinXP is shipping with HAO support, i'm not > sure which draft it is based. I hope things change after we have Proposed Standard and a number of interoperable implementations. I regret that your experience has caused discomfort. However, it is the nature of IETF Internet Drafts that they often change. Even Proposed Standards change. In fact, if I remember right, there is even now some movement towards changing the Draft Standard about site local addresses. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 17:30:54 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10767 for ; Sun, 21 Jul 2002 17:30:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18911; Sun, 21 Jul 2002 14:29:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18762; Sun, 21 Jul 2002 14:29:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLSSoN028707 for ; Sun, 21 Jul 2002 14:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LLSSZx028706 for mobile-ip-dist; Sun, 21 Jul 2002 14:28:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLSJoN028691; Sun, 21 Jul 2002 14:28:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11109; Sun, 21 Jul 2002 14:28:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28538; Sun, 21 Jul 2002 15:28:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3C4D34B22; Mon, 22 Jul 2002 06:28:11 +0900 (JST) To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: charliep's message of Sun, 21 Jul 2002 08:55:43 MST. <3D3AD97F.F5D1927A@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Mon, 22 Jul 2002 06:28:11 +0900 Message-Id: <20020721212811.3C4D34B22@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 >> draft 17-18: type, length and an IPv6 address, type # = 201 >There is no difference. There were no valid suboptions defined for >earlier drafts, even though the field was shown as possibly there >for future suboptions. In the drafts after 16, a reasonable implementation >should still allow for future suboptions that don't exist yet. i don't think draft 17/18 implementation will allow suboptions. see the 17/18 languge about HAO option length. if we follow this, there's no chance we will see suboptions. you have to take a security stance. having loose inbound packet validation == more chances for security vulnerabilities. draft 17/18 implementations that allow option length != 16 are buggy. > Option Type > > 201 = 0xC9 > > Option Length > > 8-bit unsigned integer. Length of the option, in octets, > excluding the Option Type and Option Length fields. This field > MUST be set to 16. >> no wonder vendors ship without HAO support, it is impossible to >> support something that changes this often. as for *BSD/KAME, it is >> decided that we won't merge anything related to mobile-ip6 into main >> *BSD distribution until mobile-ip6 becomes RFC (so it won't show up >> onto ExtremeWare, JunOS, MacOS X, ...). >> if i remember correctly WinXP is shipping with HAO support, i'm not >> sure which draft it is based. >I hope things change after we have Proposed Standard and a number >of interoperable implementations. I regret that your experience has >caused discomfort. However, it is the nature of IETF Internet Drafts >that they often change. Even Proposed Standards change. In fact, >if I remember right, there is even now some movement towards >changing the Draft Standard about site local addresses. when moving from PS to DS, they *remove* functionality. they usually don't mandate new things. your example above does not convince me. i'm very concerned about the use of MUST for HAO since mobile-ip6 draft 18 is trying to mandate new thing to all IPv6 (RFC2460) implementations. SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at this stage of RFC2460-based IPv6 deployment. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 18:00:48 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11019 for ; Sun, 21 Jul 2002 18:00:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24578; Sun, 21 Jul 2002 14:59:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16437; Sun, 21 Jul 2002 14:59:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLwaoN028879 for ; Sun, 21 Jul 2002 14:58:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LLwZEU028878 for mobile-ip-dist; Sun, 21 Jul 2002 14:58:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLwWoN028871; Sun, 21 Jul 2002 14:58:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00731; Sun, 21 Jul 2002 14:58:33 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA24392; Sun, 21 Jul 2002 14:58:31 -0700 (PDT) Received: from btmail.net.cn([202.106.196.72]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm83d3b59f7; Sun, 21 Jul 2002 21:58:27 -0000 Received: from nwkea-mail-1.sun.com([192.18.42.13]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm273d368549; Thu, 18 Jul 2002 03:57:33 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05094; Wed, 17 Jul 2002 19:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25904; Wed, 17 Jul 2002 19:38:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2akoN013199 for ; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2akrN013198 for mobile-ip-dist; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2aaoN013174; Wed, 17 Jul 2002 19:36:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22174; Wed, 17 Jul 2002 19:36:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19124; Wed, 17 Jul 2002 19:36:38 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8F9F06A906; Thu, 18 Jul 2002 05:36:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E92236A905; Thu, 18 Jul 2002 05:36:33 +0300 (EEST) Message-ID: <3D362A1E.3080101@kolumbus.fi> Date: Thu, 18 Jul 2002 05:38:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Moore Cc: itojun@iijlab.net, Keiichi SHIMA / =?ISO-8859-1?Q?=3F=3F=3F?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207171531.g6HFVft12848@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keith Moore wrote: > the purpose of a standard is to describe what is necessary for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate whether a feature > is a MUST in a new version of a standard unless interoperability with the > installed base is important (it generally is) and imposing the MUST condition > on implementations that conform with the new version of the standard affects > interoperability with the installed base. Agree with all of the above. In this case, there are no interoperability problems. Since draft N-2 Mobile IPv6 has been able to work with IPv6 nodes that have *no* MIPv6 specific code. Again, this is separate from what the IETF may mandate for IPv6 nodes to support. To take a clearly unreasonable example, we could mandate every node to support a 1,000,000 entry bindind cache. Even with such a mandate a node conforming to this requirement would work with a node that has never heard of MIPv6. So, interoperability and must-implement are different in this particular case. I think that's good because we can then decide more freely what to require from all implementations. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 18:01:59 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11049 for ; Sun, 21 Jul 2002 18:01:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27829; Sun, 21 Jul 2002 16:02:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17583; Sun, 21 Jul 2002 15:02:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LM0ooN029252 for ; Sun, 21 Jul 2002 15:00:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LM0np7029247 for mobile-ip-dist; Sun, 21 Jul 2002 15:00:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LM0coN029174; Sun, 21 Jul 2002 15:00:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22409; Sun, 21 Jul 2002 15:00:39 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA03896; Sun, 21 Jul 2002 15:00:37 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm243d3b5a75; Sun, 21 Jul 2002 22:00:33 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm03d366226; Thu, 18 Jul 2002 03:59:12 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22937; Wed, 17 Jul 2002 19:14:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00103; Wed, 17 Jul 2002 18:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CXoN012378 for ; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I1CXdt012377 for mobile-ip-dist; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CUoN012370; Wed, 17 Jul 2002 18:12:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05406; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06648; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 21:07:05 -0400 Message-ID: From: Phil Roberts To: "'Francis Dupont'" , Vijay Devarapalli Cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 21:07:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: A few issues have become mingled here. 1) Keiichi and others have raised the issue of MUST support for HAO and BE processing and have proposed a solution that allows communication to happen between any two nodes with clarification in the MIP spec of properly handling the ICMP errors returned. 2) There is a question about RO support requirements for all nodes. Actually the current spec doesn't give a recommendation for support of RO. If a node is supporting it, there are a bunch of MUSTs. We should make sure we agree as a working group on our consensus on these two issues. Perhaps we can sort this out on the MIP list first? > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, July 17, 2002 8:57 PM > To: Vijay Devarapalli > Cc: itojun@iijlab.net; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > In your previous mail you wrote: > > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > I was discounting the reason (the already IPv6 installed base) you > gave. the MUST is for newer IPv6 CN implementations. as I told you > already, it makes the MN's life easier. but the current spec does > ensure that a MN can still have a session with an old IPv6 > implementation (which does not implement HAO) through reverse > tunneling. so again, where is the problem? why are you against the > MUST? > > => MUSTs are for interoperability problems, not for political matters. > So Itojun is right and the fact that old IPv6 nodes still work with > MNs proves the requirement should not be higher than SHOULD. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: sorry but if someone is asking whether the RR/RO support should be > mandatory I'll vote against it. And I can't see how the iETF will > enforce it if I am being in the minority... > (the topics has just been added to the ipv6 WG session agenda) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 21 19:54:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12143 for ; Sun, 21 Jul 2002 19:54:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23566; Sun, 21 Jul 2002 16:53:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07803; Sun, 21 Jul 2002 16:53:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LNqboN001227 for ; Sun, 21 Jul 2002 16:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LNqb1i001226 for mobile-ip-dist; Sun, 21 Jul 2002 16:52:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LNqXoN001219; Sun, 21 Jul 2002 16:52:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07690; Sun, 21 Jul 2002 16:52:35 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA23426; Sun, 21 Jul 2002 16:52:32 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm4d3d3b74b1; Sun, 21 Jul 2002 23:52:29 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm893d367a78; Thu, 18 Jul 2002 05:52:23 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22309; Wed, 17 Jul 2002 20:40:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23295; Wed, 17 Jul 2002 19:40:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2cGoN013309 for ; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2cGqB013308 for mobile-ip-dist; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2c6oN013287; Wed, 17 Jul 2002 19:38:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22501; Wed, 17 Jul 2002 19:38:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22744; Wed, 17 Jul 2002 20:38:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 266876A906; Thu, 18 Jul 2002 05:38:00 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C9856A905; Thu, 18 Jul 2002 05:37:56 +0300 (EEST) Message-ID: <3D362A71.20606@kolumbus.fi> Date: Thu, 18 Jul 2002 05:39:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Vijay Devarapalli , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> <15670.1003.493633.920465@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? That _is_ actually the intention. We tried to formulate section 8.2. (RO requirements) in the MIPv6 draft so that it describes what you have to do to support RO, but not when you have to support it. And we are expecting the node requirements document to say MAY/SHOULD/MUST for the RO feature. I think that's the right place to make the determination. Ok? Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 02:32:58 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26726 for ; Mon, 22 Jul 2002 02:32:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04385; Sun, 21 Jul 2002 23:31:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09571; Sun, 21 Jul 2002 23:31:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M6UNoN002835 for ; Sun, 21 Jul 2002 23:30:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6M6UNe8002834 for mobile-ip-dist; Sun, 21 Jul 2002 23:30:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M6UJoN002827; Sun, 21 Jul 2002 23:30:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19024; Sun, 21 Jul 2002 23:30:19 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA03951; Sun, 21 Jul 2002 23:30:15 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm183d3bd1e5; Mon, 22 Jul 2002 06:30:09 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmb13d3709f7; Thu, 18 Jul 2002 12:29:53 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14634; Wed, 17 Jul 2002 23:22:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29865; Wed, 17 Jul 2002 22:22:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KPoN015423 for ; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5KPkV015422 for mobile-ip-dist; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KLoN015415; Wed, 17 Jul 2002 22:20:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18711; Wed, 17 Jul 2002 22:20:23 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23539; Wed, 17 Jul 2002 22:20:22 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA28494; Thu, 18 Jul 2002 14:20:21 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA28160; Thu, 18 Jul 2002 14:20:19 +0900 (JST) Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST) Message-Id: <20020718.141850.32635405.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3648E4.8050701@kolumbus.fi> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 11:46:20 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08102 for ; Mon, 22 Jul 2002 11:46:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27501; Mon, 22 Jul 2002 09:46:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28427; Mon, 22 Jul 2002 08:46:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MFjhoN005278 for ; Mon, 22 Jul 2002 08:45:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MFjhu6005277 for mobile-ip-dist; Mon, 22 Jul 2002 08:45:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MFjdoN005270; Mon, 22 Jul 2002 08:45:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18224; Mon, 22 Jul 2002 08:45:41 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25272; Mon, 22 Jul 2002 09:45:40 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MFnVj16102; Mon, 22 Jul 2002 10:49:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 10:45:38 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 10:45:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 10:45:36 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIw/bvWnlQi/O5cQtCbCv1U27ZizwAmRC1g To: , Cc: , X-OriginalArrivalTime: 22 Jul 2002 15:45:37.0411 (UTC) FILETIME=[D2F7DD30:01C23196] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6MFjeoO005271 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello Itojun, > i'm very concerned about the use of MUST for HAO since > mobile-ip6 draft 18 is trying to mandate new thing to all IPv6 > (RFC2460) implementations. > SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at > this stage of RFC2460-based IPv6 deployment. If the intent is to support mobility in IPv6 networks as an integral aspect of the protocol, I believe the HAO processing is a MUST. I believe the Mobile IP WG is of this opinion. If the IESG and the IPv6 WGs disagree with this opinion when the Mobile IPv6 spec goes to IETF last call we can deal with it. But for now I am in favor of keeping the MUST for the HAO processing for all IPv6 nodes. I am of the opinion that the scale of IPv6 deployment today is still in its infancy and the impacts associated with mandating the HAO processing on all IPv6 nodes is far less than maybe two years from now. > >itojun > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 12:28:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12030 for ; Mon, 22 Jul 2002 12:28:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13508; Mon, 22 Jul 2002 10:28:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01933; Mon, 22 Jul 2002 09:28:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MGRBoN005518 for ; Mon, 22 Jul 2002 09:27:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MGRArK005517 for mobile-ip-dist; Mon, 22 Jul 2002 09:27:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MGR7oN005510; Mon, 22 Jul 2002 09:27:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17258; Mon, 22 Jul 2002 09:27:09 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21474; Mon, 22 Jul 2002 10:27:08 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6MGPWhI008750; Mon, 22 Jul 2002 09:25:32 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE93242; Mon, 22 Jul 2002 09:20:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02944; Mon, 22 Jul 2002 09:25:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15676.12796.24879.810873@thomasm-u1.cisco.com> Date: Mon, 22 Jul 2002 09:25:32 -0700 (PDT) To: Basavaraj.Patil@nokia.com Cc: , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com writes: > If the intent is to support mobility in IPv6 networks as an integral > aspect of the protocol, I believe the HAO processing is a MUST. I > believe the Mobile IP WG is of this opinion. That sure hasn't been my read of the consensus. In fact, the consensus seems to be exactly opposite. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 13:21:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18676 for ; Mon, 22 Jul 2002 13:21:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07985; Mon, 22 Jul 2002 10:19:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06744; Mon, 22 Jul 2002 10:18:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MHI1oN005810 for ; Mon, 22 Jul 2002 10:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MHI15n005809 for mobile-ip-dist; Mon, 22 Jul 2002 10:18:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MHHvoN005802; Mon, 22 Jul 2002 10:17:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06142; Mon, 22 Jul 2002 10:17:58 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07318; Mon, 22 Jul 2002 10:17:57 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MHISx07747; Mon, 22 Jul 2002 12:18:28 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 12:17:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 12:16:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231A3.7A9D2A4A" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 12:16:12 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1315C@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuITR8hcubAKJeTZWcDWWAP6l2RQDgj8bg To: , , Cc: , , , , X-OriginalArrivalTime: 22 Jul 2002 17:16:13.0868 (UTC) FILETIME=[7B595EC0:01C231A3] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C231A3.7A9D2A4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Michael Thomas wrote:=20 >> Frankly, I don't think that there is any evidence=20 >> that the net would be substantially harmed if RO=20 >> wasn't widely implemented and/or enabled. Indeed,=20 >> I think there's good reason to believe that many/most=20 >> nodes will not enable RO even if their kernel=20 >> implements it. In some cases, it's likely to be=20 >> a nice and useful optimization, but I really=20 >> don't see it as a "if we don't do this the net=20 >> will fall apart". As such, SHOULD seems like it=20 >> strikes the right balance.=20 >>=20 >> Mike=20 >>=20 > >I could not agree more with this point. RO would be a required=20 >functionality a number of years back, when the net was in it's=20 >infancy and bandwidth availability in the backbone networks=20 >(even transoceanic links) were severely limited.=20 >We are in the age of OC-192/768s over DWDM. The delay that an IP=20 >packet incurs in the core is almost negligible.=20 >If bottleneck in the HA is the primary driver for RO, then it is=20 >possible to solve the problem with load balancing with DHAAD.=20 > >My two cents.=20 =20 RO gives you the capability of having two end-points connected without having to rely on intermediate nodes such as the HA being involved. The HA is not the bottleneck. One of the benefits of RO is lesser traffic in the backbone and to a certain degree reduced latency. But these are some of the lesser motivations.=20 =20 Having a mobile anchored at some point in the network (HA) when it is non-essential is just not the right approach. Mandating HAO processing in all IPv6 nodes is the only way to accomplish this and reverse tunnelling or having a node anchored at the HA is an option only for backward compatibility to the nodes that already deployed (which is a pretty small percentage of IP nodes). =20 > >Regards,=20 >Kuntal=20 > =20 -Basavaraj ------_=_NextPart_001_01C231A3.7A9D2A4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated

>Michael Thomas wrote:
>>    = Frankly, I=20 don't think that there is any evidence
>>    = that the=20 net would be substantially harmed if RO
>>    = wasn't=20 widely implemented and/or enabled. Indeed, =
>>    I=20 think  there's good reason to believe that many/most=20
>>    nodes will not enable RO even if their = kernel=20
>>    implements it. In some cases, it's likely = to be=20
>>    a nice and useful optimization, but I = really=20
>>    don't see it as a "if we don't do this = the net=20
>>    will fall apart". As such, SHOULD seems = like it=20
>>    strikes the right balance.
>>=20
>>          &= nbsp;  =20 Mike
>>
>
>I could not agree more with this = point. RO=20 would be a required
>functionality a number of years back, when = the net=20 was in it's
>infancy and bandwidth availability in the backbone = networks=20
>(even transoceanic links) were severely limited.
>We are = in the=20 age of OC-192/768s over DWDM. The delay that an IP
>packet incurs = in the=20 core is almost negligible.
>If bottleneck in the HA is the = primary driver=20 for RO, then it is
>possible to solve the problem with load = balancing=20 with DHAAD.
>
>My two cents.
 
RO gives you the capability of having two end-points connected=20 without
having to rely on intermediate nodes such as the HA=20 being
involved. The HA is not the bottleneck. One of the benefits of = RO=20 is
lesser traffic in the backbone and to a certain degree = reduced
latency.=20 But these are some of the lesser motivations.
 
Having a mobile anchored at some point in the network (HA) when it=20 is
non-essential is just not the right approach. Mandating HAO=20 processing
in all IPv6 nodes is the only way to accomplish this and=20 reverse
tunnelling or having a node anchored at the HA is an option = only=20 for
backward compatibility to the nodes that already deployed (which = is=20 a
pretty small percentage of IP nodes).
 
>
>Regards,
>Kuntal
>
 
-Basavaraj
------_=_NextPart_001_01C231A3.7A9D2A4A-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 13:34:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19894 for ; Mon, 22 Jul 2002 13:34:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10979; Mon, 22 Jul 2002 10:24:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23833; Mon, 22 Jul 2002 10:24:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MHN6oN005984 for ; Mon, 22 Jul 2002 10:23:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MHN6lO005983 for mobile-ip-dist; Mon, 22 Jul 2002 10:23:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MHN2oN005976 for ; Mon, 22 Jul 2002 10:23:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23487 for ; Mon, 22 Jul 2002 10:23:03 -0700 (PDT) Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26074 for ; Mon, 22 Jul 2002 11:23:02 -0600 (MDT) Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g6MHN1X18580 for mobile-ip@sunroof.eng.sun.com; Mon, 22 Jul 2002 19:23:01 +0200 Date: Mon, 22 Jul 2002 19:23:01 +0200 Message-Id: <200207221723.g6MHN1X18580@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: Michael Sessinghaus To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] possible movement scenarios with mobile ip Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello I am occupied with movement scenarios, which could be applicable for mobile IP. Do you know any references, which examined or concidered mobile ip scenarios? Please help me. Thanks and regards, Michael. ______________________________________________________________________________ WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/ From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 14:16:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24179 for ; Mon, 22 Jul 2002 14:16:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21129; Mon, 22 Jul 2002 12:17:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29498; Mon, 22 Jul 2002 11:16:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIFooN006356 for ; Mon, 22 Jul 2002 11:15:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MIFoFw006355 for mobile-ip-dist; Mon, 22 Jul 2002 11:15:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIFdoN006339; Mon, 22 Jul 2002 11:15:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28662; Mon, 22 Jul 2002 11:15:39 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10934; Mon, 22 Jul 2002 11:15:34 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MIDtd20729; Mon, 22 Jul 2002 13:13:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 13:13:40 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Basavaraj.Patil@nokia.com, mat@cisco.com, john.loughney@nokia.com Cc: itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 13:13:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231AB.7F844A20" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C231AB.7F844A20 Content-Type: text/plain Here are two of the reasons why I think RO will be undesirable: 1. It allows the users to entirely bypass the home IP provider's network. This will keep the home IP network providers out of added revenue streams. The situation will be even worse when the AAA clients for accounting are in the home IP network which will not be in the data path due to RO. 2. Imposes unnecessary processing requirement on ALL IPv6 devices to support this non-mandatory functionality. Here is a reason why I think RO will be meaningless: The core of the internet is managed by large carriers. These carriers use (or will be using) Constrained Based Routing (OSPF-TE) instead of plain OSPF. The main purpose is traffic engineering. Therefore the path between the CN and the MN may not always be the shortest one even with RO. It entirely depends on the traffic engineering of the intervening networks. As an example: If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the shortest route between Chicago and Dallas has less weight (not preferred by OSPF-TE) then all the IP packets between CN and the MN will be routed via an alternative path which may well be via Miami. Therefore RO will be a waste of time and resource. Regards, Kuntal >Michael Thomas wrote: >> Frankly, I don't think that there is any evidence >> that the net would be substantially harmed if RO >> wasn't widely implemented and/or enabled. Indeed, >> I think there's good reason to believe that many/most >> nodes will not enable RO even if their kernel >> implements it. In some cases, it's likely to be >> a nice and useful optimization, but I really >> don't see it as a "if we don't do this the net >> will fall apart". As such, SHOULD seems like it >> strikes the right balance. >> >> Mike >> > >I could not agree more with this point. RO would be a required >functionality a number of years back, when the net was in it's >infancy and bandwidth availability in the backbone networks >(even transoceanic links) were severely limited. >We are in the age of OC-192/768s over DWDM. The delay that an IP >packet incurs in the core is almost negligible. >If bottleneck in the HA is the primary driver for RO, then it is >possible to solve the problem with load balancing with DHAAD. > >My two cents. RO gives you the capability of having two end-points connected without having to rely on intermediate nodes such as the HA being involved. The HA is not the bottleneck. One of the benefits of RO is lesser traffic in the backbone and to a certain degree reduced latency. But these are some of the lesser motivations. Having a mobile anchored at some point in the network (HA) when it is non-essential is just not the right approach. Mandating HAO processing in all IPv6 nodes is the only way to accomplish this and reverse tunnelling or having a node anchored at the HA is an option only for backward compatibility to the nodes that already deployed (which is a pretty small percentage of IP nodes). > >Regards, >Kuntal > -Basavaraj ------_=_NextPart_001_01C231AB.7F844A20 Content-Type: text/html RE: [mobile-ip] Re: HAO and BE processing will be mandated
Here are two of the reasons why I think RO will be undesirable:
 
1. It allows the users to entirely bypass the home IP provider's network. This will keep the home IP network providers out of added revenue streams. The situation will be even worse when the AAA clients for accounting are in the home IP network which will not be in the data path due to RO.
 
2. Imposes unnecessary processing requirement on ALL IPv6 devices to support this non-mandatory functionality.
 
Here is a reason why I think RO will be meaningless:
 
The core of the internet is managed by large carriers. These carriers use (or will be using) Constrained Based Routing (OSPF-TE) instead of plain OSPF. The main purpose is traffic engineering. Therefore the path between the CN and the MN may not always be the shortest one even with RO. It entirely depends on the traffic engineering of the intervening networks. As an example:
If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the shortest route between Chicago and Dallas has less weight (not preferred by OSPF-TE) then all the IP packets between CN and the MN will be routed via an alternative path which may well be via Miami. Therefore RO will be a waste of time and resource.
 
 
Regards,
Kuntal
 
>Michael Thomas wrote:
>>    Frankly, I don't think that there is any evidence
>>    that the net would be substantially harmed if RO
>>    wasn't widely implemented and/or enabled. Indeed,
>>    I think  there's good reason to believe that many/most
>>    nodes will not enable RO even if their kernel
>>    implements it. In some cases, it's likely to be
>>    a nice and useful optimization, but I really
>>    don't see it as a "if we don't do this the net
>>    will fall apart". As such, SHOULD seems like it
>>    strikes the right balance.
>>
>>              Mike
>>
>
>I could not agree more with this point. RO would be a required
>functionality a number of years back, when the net was in it's
>infancy and bandwidth availability in the backbone networks
>(even transoceanic links) were severely limited.
>We are in the age of OC-192/768s over DWDM. The delay that an IP
>packet incurs in the core is almost negligible.
>If bottleneck in the HA is the primary driver for RO, then it is
>possible to solve the problem with load balancing with DHAAD.
>
>My two cents.
 
RO gives you the capability of having two end-points connected without
having to rely on intermediate nodes such as the HA being
involved. The HA is not the bottleneck. One of the benefits of RO is
lesser traffic in the backbone and to a certain degree reduced
latency. But these are some of the lesser motivations.
 
Having a mobile anchored at some point in the network (HA) when it is
non-essential is just not the right approach. Mandating HAO processing
in all IPv6 nodes is the only way to accomplish this and reverse
tunnelling or having a node anchored at the HA is an option only for
backward compatibility to the nodes that already deployed (which is a
pretty small percentage of IP nodes).
 
>
>Regards,
>Kuntal
>
 
-Basavaraj
------_=_NextPart_001_01C231AB.7F844A20-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 14:50:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27357 for ; Mon, 22 Jul 2002 14:50:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07237; Mon, 22 Jul 2002 12:43:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13131; Mon, 22 Jul 2002 11:43:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIfmoN006633 for ; Mon, 22 Jul 2002 11:41:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MIfmR2006632 for mobile-ip-dist; Mon, 22 Jul 2002 11:41:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIffoN006614; Mon, 22 Jul 2002 11:41:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24943; Mon, 22 Jul 2002 11:41:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06280; Mon, 22 Jul 2002 12:41:41 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6MIfYd22051; Mon, 22 Jul 2002 21:41:34 +0300 Date: Mon, 22 Jul 2002 21:41:33 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Trimmed up the Cc: list a bit. I think this is getting way off topic though.. On Mon, 22 Jul 2002, Kuntal Chowdhury wrote: > Here are two of the reasons why I think RO will be undesirable: > > 1. It allows the users to entirely bypass the home IP provider's network. > This will keep the home IP network providers out of added revenue streams. > The situation will be even worse when the AAA clients for accounting are in > the home IP network which will not be in the data path due to RO. The data does not go to the home IP provider's network so there is absolutely zero reason be able to gain revenue from that. > 2. Imposes unnecessary processing requirement on ALL IPv6 devices to support > this non-mandatory functionality. My personal opinion is a SHOULD, but I think 'unnecessary' is a bit harsh. > Here is a reason why I think RO will be meaningless: > > The core of the internet is managed by large carriers. These carriers use > (or will be using) Constrained Based Routing (OSPF-TE) instead of plain > OSPF. In which world? > The main purpose is traffic engineering. Therefore the path between > the CN and the MN may not always be the shortest one even with RO. It > entirely depends on the traffic engineering of the intervening networks. As > an example: > If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the > shortest route between Chicago and Dallas has less weight (not preferred by > OSPF-TE) then all the IP packets between CN and the MN will be routed via an > alternative path which may well be via Miami. Therefore RO will be a waste > of time and resource. If TE is used to route the traffic via such slow paths the difference is noticeable (at least, without measurement tools), the network is designed and operated badly, period. Nobody would want to pay for that kind of service. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 15:17:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29625 for ; Mon, 22 Jul 2002 15:17:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04008; Mon, 22 Jul 2002 13:17:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23075; Mon, 22 Jul 2002 12:17:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJGMoN006913 for ; Mon, 22 Jul 2002 12:16:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MJGLZf006912 for mobile-ip-dist; Mon, 22 Jul 2002 12:16:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJGDoN006896; Mon, 22 Jul 2002 12:16:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26514; Mon, 22 Jul 2002 12:15:44 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13242; Mon, 22 Jul 2002 12:15:44 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJFnd09795; Mon, 22 Jul 2002 14:15:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:15:35 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24052E0FDD@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Pekka Savola Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:15:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B4.23C0AFE0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C231B4.23C0AFE0 Content-Type: text/plain; charset="iso-8859-1" > > Here are two of the reasons why I think RO will be undesirable: > > > > 1. It allows the users to entirely bypass the home IP provider's network. > > This will keep the home IP network providers out of added revenue streams. > > The situation will be even worse when the AAA clients for accounting are in > > the home IP network which will not be in the data path due to RO. > > The data does not go to the home IP provider's network so there is > absolutely zero reason be able to gain revenue from that. I don't think I understood your point. Are you agreeing with me or disagreeing? > > > 2. Imposes unnecessary processing requirement on ALL IPv6 > devices to support > > this non-mandatory functionality. > > My personal opinion is a SHOULD, but I think 'unnecessary' is > a bit harsh. > No comment. > > Here is a reason why I think RO will be meaningless: > > > > The core of the internet is managed by large carriers. > These carriers use > > (or will be using) Constrained Based Routing (OSPF-TE) > instead of plain > > OSPF. > > In which world? > Not sure which world it will be :o), but here are some links on TE: http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-02.txt http://www.ietf.org/rfc/rfc3272.txt http://www.ietf.org/rfc/rfc3209.txt http://www.ietf.org/rfc/rfc3212.txt > > The main purpose is traffic engineering. Therefore the path between > > the CN and the MN may not always be the shortest one even with RO. It > > entirely depends on the traffic engineering of the intervening networks. As > > an example: > > If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the > > shortest route between Chicago and Dallas has less weight (not preferred by > > OSPF-TE) then all the IP packets between CN and the MN will be routed via an > > alternative path which may well be via Miami. Therefore RO will be a waste > > of time and resource. > > If TE is used to route the traffic via such slow paths the difference is > noticeable (at least, without measurement tools), the network is designed > and operated badly, period. Nobody would want to pay for that kind of > service. > What makes you think that the TEed route between the CN and the MN (i.e. Chicago -> Miami -> Dallas) will be a slow path? Do you think the shortest path is ALWAYS the best/fastest path? -Kuntal > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > ------_=_NextPart_001_01C231B4.23C0AFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated =

> > Here are two of the reasons why I think RO = will be undesirable:
> > 
> > 1. It allows the users to entirely bypass = the home IP provider's network.
> > This will keep the home IP network = providers out of added revenue streams.
> > The situation will be even worse when the = AAA clients for accounting are in
> > the home IP network which will not be in = the data path due to RO.
>
> The data does not go to the home IP provider's = network so there is
> absolutely zero reason be able to gain revenue = from that. 

I don't think I understood your point. Are you = agreeing with me or disagreeing?

>  
> > 2. Imposes unnecessary processing = requirement on ALL IPv6
> devices to support
> > this non-mandatory functionality.
>
> My personal opinion is a SHOULD, but I think = 'unnecessary' is
> a bit harsh.
>  

No comment.

> > Here is a reason why I think RO will be = meaningless:
> > 
> > The core of the internet is managed by = large carriers.
> These carriers use
> > (or will be using) Constrained Based = Routing (OSPF-TE)
> instead of plain
> > OSPF.
>
> In which world?
>

Not sure which world it will be :o), but here are = some links on TE:

http://www.ietf.org/internet-drafts/draft-katz-yeung-o= spf-traffic-06.txt
http://www.ietf.org/internet-drafts/draft-srisuresh-os= pf-te-02.txt
http://www.ietf.org/rfc/rfc3272.txt
http://www.ietf.org/rfc/rfc3209.txt
http://www.ietf.org/rfc/rfc3212.txt


> > The main purpose is traffic engineering. = Therefore the path between
> > the CN and the MN may not always be the = shortest one even with RO. It
> > entirely depends on the traffic = engineering of the intervening networks. As
> > an example:
> > If the CN is in Chicago, MN is in Dallas = and the HA is in Miami, if the
> > shortest route between Chicago and Dallas = has less weight (not preferred by
> > OSPF-TE) then all the IP packets between = CN and the MN will be routed via an
> > alternative path which may well be via = Miami. Therefore RO will be a waste
> > of time and resource.
>
> If TE is used to route the traffic via such = slow paths the difference is
> noticeable (at least, without measurement = tools), the network is designed
> and operated badly, period.  Nobody would = want to pay for that kind of
> service.
>

What makes you think that the TEed route between the = CN and the MN
(i.e. Chicago -> Miami -> Dallas) will be a = slow path?
Do you think the shortest path is ALWAYS the = best/fastest path?

-Kuntal



> --
> Pekka = Savola           =       "Tell me of difficulties = surmounted,
> Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
> Systems. Networks. Security.  -- Robert = Jordan: A Crown of Swords
>
>
>

------_=_NextPart_001_01C231B4.23C0AFE0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 15:20:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29966 for ; Mon, 22 Jul 2002 15:20:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15968; Mon, 22 Jul 2002 12:19:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28330; Mon, 22 Jul 2002 12:19:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJIMoN006953 for ; Mon, 22 Jul 2002 12:18:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MJIMOr006952 for mobile-ip-dist; Mon, 22 Jul 2002 12:18:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJIEoN006934; Mon, 22 Jul 2002 12:18:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27609; Mon, 22 Jul 2002 12:18:15 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28373; Mon, 22 Jul 2002 13:18:14 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJD5d09271; Mon, 22 Jul 2002 14:13:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:12:50 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04BFA175@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas , Basavaraj.Patil@nokia.com Cc: itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:12:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B3.C4E31A80" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C231B3.C4E31A80 Content-Type: text/plain; charset="iso-8859-1" I thought it was already decided that a CN MUST respond with a rate limited "lack of resources" response to the request for route optimization. If this is the case then it seems to follow that the processing of the HOA for this purpose MUST also be supported if the HOA is to be a part of the request to do route optimization - but only to this extent. Perhaps some clarification in the draft is all that is necessary as to what is meant by the MUST. ------_=_NextPart_001_01C231B3.C4E31A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated =

I thought it was already decided that a CN MUST = respond with a rate limited "lack of resources" response to = the request for route optimization. If this is the case then it seems = to follow that the processing of the HOA for this purpose MUST also be = supported if the HOA is to be a part of the request to do route = optimization - but only to this extent. Perhaps some clarification in = the draft is all that is necessary as to what is meant by the = MUST.

 

------_=_NextPart_001_01C231B3.C4E31A80-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 15:23:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00293 for ; Mon, 22 Jul 2002 15:23:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17987; Mon, 22 Jul 2002 12:21:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09723; Mon, 22 Jul 2002 12:21:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJKKoN007091 for ; Mon, 22 Jul 2002 12:20:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MJKJel007086 for mobile-ip-dist; Mon, 22 Jul 2002 12:20:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJK8oN007055; Mon, 22 Jul 2002 12:20:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09142; Mon, 22 Jul 2002 12:20:10 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16264; Mon, 22 Jul 2002 12:20:08 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJEvd09601; Mon, 22 Jul 2002 14:14:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:14:43 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04BFA18B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow" , Michael Thomas , Basavaraj.Patil@nokia.com Cc: itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:14:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B4.08176360" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C231B4.08176360 Content-Type: text/plain; charset="iso-8859-1" sed r//HOA//HAO/g > -----Original Message----- > From: Morrow, Glenn [RICH2:C310:EXCH] > Sent: Monday, July 22, 2002 2:17 PM > To: 'Michael Thomas'; Basavaraj.Patil@nokia.com > Cc: itojun@iijlab.net; charliep@iprg.nokia.com; > mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated > > > I thought it was already decided that a CN MUST respond with > a rate limited "lack of resources" response to the request > for route optimization. If this is the case then it seems to > follow that the processing of the HOA for this purpose MUST > also be supported if the HOA is to be a part of the request > to do route optimization - but only to this extent. Perhaps > some clarification in the draft is all that is necessary as > to what is meant by the MUST. > > ------_=_NextPart_001_01C231B4.08176360 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

sed r//HOA//HAO/g

> -----Original Message-----
> From: Morrow, Glenn [RICH2:C310:EXCH]
> Sent: Monday, July 22, 2002 2:17 PM
> To: 'Michael Thomas'; Basavaraj.Patil@nokia.com
> Cc: itojun@iijlab.net; charliep@iprg.nokia.com;
> mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated
>
>
> I thought it was already decided that a CN MUST respond with
> a rate limited "lack of resources" response to the request
> for route optimization. If this is the case then it seems to
> follow that the processing of the HOA for this purpose MUST
> also be supported if the HOA is to be a part of the request
> to do route optimization - but only to this extent. Perhaps
> some clarification in the draft is all that is necessary as
> to what is meant by the MUST.
> 
>

------_=_NextPart_001_01C231B4.08176360-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 16:53:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08220 for ; Mon, 22 Jul 2002 16:53:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25621; Mon, 22 Jul 2002 14:53:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15149; Mon, 22 Jul 2002 13:53:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKqdoN007866 for ; Mon, 22 Jul 2002 13:52:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKqdCp007865 for mobile-ip-dist; Mon, 22 Jul 2002 13:52:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKqWoN007850; Mon, 22 Jul 2002 13:52:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14767; Mon, 22 Jul 2002 13:52:32 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15508; Mon, 22 Jul 2002 14:52:32 -0600 (MDT) Message-ID: <01bc01c231c0$d0b945c0$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Kuntal Chowdhury" , , , Cc: , , , , References: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 13:46:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B9_01C23186.23891400" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_01B9_01C23186.23891400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated Here are two = of the reasons why I think RO will be undesirable: =20 1. It allows the users to entirely bypass the home IP provider's = network. This will keep the home =20 IP network providers out of added revenue streams. The situation will = be even worse when the =20 AAA clients for accounting are in the home IP network which will not = be in the data path due to=20 RO. This is not a techical reason, this is a business reason. If we get into = this aspect of technology deployment, protocol designs might change in rather = strange ways :) I don't think we want to go there. Also, if any operator is trying to bill users by baning route = optimizations, what is their plan for non-Mobile IP? What happens when mobile node uses its care-of = address as its end point of a communication? Despite any protocol work here, an operator can still force all the = traffic to flow through home network, if it is determined to do so... alper =20 ------=_NextPart_000_01B9_01C23186.23891400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated
  = Here are=20 two of the reasons why I think RO will be = undesirable:
 
  = 1. It allows=20 the users to entirely bypass the home IP provider's network. This will = keep the=20 home 
  IP=20 network providers out of added revenue streams. The situation will be = even worse=20 when the 
  = AAA clients=20 for accounting are in the home IP network which will not be in the data = path due=20 to
  = RO.
 
This is not a techical reason, this is a business reason. If we get = into=20 this aspect
of technology deployment, protocol designs might change in = rather=20 strange ways :)
I don't think we want to go there.
 
Also, if any operator is trying to bill users by baning = route=20 optimizations, what is their
plan for non-Mobile IP? What happens when mobile node uses its = care-of=20 address
as its end point of a communication?
 
Despite any protocol work here, an operator can still force all the = traffic=20 to
flow through home network, if it is determined to do so...
 
alper
 
 ------=_NextPart_000_01B9_01C23186.23891400-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 16:58:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08624 for ; Mon, 22 Jul 2002 16:58:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18410; Mon, 22 Jul 2002 14:58:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12335; Mon, 22 Jul 2002 13:58:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKveoN008030 for ; Mon, 22 Jul 2002 13:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKvd7S008029 for mobile-ip-dist; Mon, 22 Jul 2002 13:57:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKvToN008006; Mon, 22 Jul 2002 13:57:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28499; Mon, 22 Jul 2002 13:57:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06479; Mon, 22 Jul 2002 13:57:29 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6MKvMK23230; Mon, 22 Jul 2002 23:57:22 +0300 Date: Mon, 22 Jul 2002 23:57:22 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <23BDB0046F3ED51185CD0002A5608D24052E0FDD@zrc2c009.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 22 Jul 2002, Kuntal Chowdhury wrote: > > > > Here are two of the reasons why I think RO will be undesirable: > > > > > > 1. It allows the users to entirely bypass the home IP provider's > network. > > > This will keep the home IP network providers out of added revenue > streams. > > > The situation will be even worse when the AAA clients for accounting are > in > > > the home IP network which will not be in the data path due to RO. > > > > The data does not go to the home IP provider's network so there is > > absolutely zero reason be able to gain revenue from that. > > I don't think I understood your point. Are you agreeing with me or > disagreeing? Totally disagreeing. Assuming CN is in ISP 1's network, MN is vising ISP 2's network and HA is in ISP 3's network. Your argument was, if I got it right, that route optimizations is bad because traffic is between ISP 1 and ISP 2 so ISP 3 does not get revenue. This seems ridiculous. > > > Here is a reason why I think RO will be meaningless: > > > > > > The core of the internet is managed by large carriers. > > These carriers use > > > (or will be using) Constrained Based Routing (OSPF-TE) > > instead of plain > > > OSPF. > > > > In which world? > > > > Not sure which world it will be :o), but here are some links on TE: > > http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt > http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-02.txt > http://www.ietf.org/rfc/rfc3272.txt > http://www.ietf.org/rfc/rfc3209.txt > http://www.ietf.org/rfc/rfc3212.txt Sure, people write about it, but there's fiber in abundance. The problem is who is going to pay for the ISP for using it. This does not change the problem, only makes the problem more complex (like MPLS's TE components). > > If TE is used to route the traffic via such slow paths the difference is > > noticeable (at least, without measurement tools), the network is designed > > and operated badly, period. Nobody would want to pay for that kind of > > service. > > > > What makes you think that the TEed route between the CN and the MN > (i.e. Chicago -> Miami -> Dallas) will be a slow path? The speed of light is a constant. > Do you think the shortest path is ALWAYS the best/fastest path? Almost always, yes. When it's not, it's almost best, which is roughly the same thing. All of this amounts to advantages by route optimization. (I'm disregarding stuff like extremely severe network congestion here, as we're talking about stable scenarios here.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 18:40:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17201 for ; Mon, 22 Jul 2002 18:40:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17093; Mon, 22 Jul 2002 16:40:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23338; Mon, 22 Jul 2002 15:40:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMdjoN008389 for ; Mon, 22 Jul 2002 15:39:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MMdjcX008388 for mobile-ip-dist; Mon, 22 Jul 2002 15:39:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMdfoN008381 for ; Mon, 22 Jul 2002 15:39:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03797 for ; Mon, 22 Jul 2002 15:39:43 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02820 for ; Mon, 22 Jul 2002 16:39:42 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5462F1DEA for ; Mon, 22 Jul 2002 18:39:41 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 1AFDFA06 for ; Mon, 22 Jul 2002 15:39:41 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id SAA0000577418; Mon, 22 Jul 2002 18:39:39 -0400 (EDT) Message-ID: <3D3C89AB.7744893E@hp.com> Date: Mon, 22 Jul 2002 18:39:39 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: [mobile-ip] BU length incorrect Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Don't know if someone noticed this already, but the length of a BU in Section 6.1.7 is incorrect: "If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 4." A BU is the same size of a BAck now that the lifetime field was reduced to 16 bits and the Home Address removed, it should say: "If no options are present in this message, 4 bytes of padding is necessary and the Header Len field will be set to 2." -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 18:57:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18652 for ; Mon, 22 Jul 2002 18:57:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05962; Mon, 22 Jul 2002 15:56:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08992; Mon, 22 Jul 2002 15:56:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMseoN008578 for ; Mon, 22 Jul 2002 15:54:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MMseOp008577 for mobile-ip-dist; Mon, 22 Jul 2002 15:54:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMsVoN008562; Mon, 22 Jul 2002 15:54:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28163; Mon, 22 Jul 2002 15:54:33 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23912; Mon, 22 Jul 2002 16:54:32 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 087BD4B24; Tue, 23 Jul 2002 07:54:21 +0900 (JST) To: Basavaraj.Patil@nokia.com Cc: charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: Basavaraj.Patil's message of Mon, 22 Jul 2002 10:45:36 EST. <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Tue, 23 Jul 2002 07:54:20 +0900 Message-Id: <20020722225421.087BD4B24@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >I am of the opinion that the scale of IPv6 deployment today is still >in its infancy and the impacts associated with mandating the HAO >processing on all IPv6 nodes is far less than maybe two years from >now. here are a little (incomplete) list of RFC2460-compliant implementations that does not speak/understand HAO: JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, all BSD/OS since 4.1. and any product that ships with these operating systems (note that many uses *BSD in embedded products such as printers). and i would like to stress that it isn't matter of configuration, but matter of codebase (you can't say "well, they are not configured with IPv6"). and as you may aware, people do run older revisions of those operating systems (there still are Win3.1, you know). if it isn't enough to convince you otherwise, i think you are in a dream world. itojun From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 21:42:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02062 for ; Mon, 22 Jul 2002 21:42:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02755; Mon, 22 Jul 2002 19:42:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23862; Mon, 22 Jul 2002 18:42:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1f4oN009152 for ; Mon, 22 Jul 2002 18:41:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1f4OS009151 for mobile-ip-dist; Mon, 22 Jul 2002 18:41:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1f1oN009144; Mon, 22 Jul 2002 18:41:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24616; Mon, 22 Jul 2002 18:41:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11224; Mon, 22 Jul 2002 19:41:01 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA09477; Mon, 22 Jul 2002 18:41:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1exw19574; Mon, 22 Jul 2002 18:40:59 -0700 X-mProtect: <200207230140> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd06HkRt; Mon, 22 Jul 2002 18:40:58 PDT Message-ID: <3D3CB42A.235F463D@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:40:58 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> <15676.12796.24879.810873@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit you are both right. it was closed as 'Adopted' after there was concensus on the mailing list. see, issue 45 at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html it was reopened (unfortunately) as issue 53. Vijay Michael Thomas wrote: > > Basavaraj.Patil@nokia.com writes: > > If the intent is to support mobility in IPv6 networks as an integral > > aspect of the protocol, I believe the HAO processing is a MUST. I > > believe the Mobile IP WG is of this opinion. > > That sure hasn't been my read of the consensus. > In fact, the consensus seems to be exactly > opposite. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 21:47:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02646 for ; Mon, 22 Jul 2002 21:47:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04761; Mon, 22 Jul 2002 19:48:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26491; Mon, 22 Jul 2002 18:48:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1kkoN009297 for ; Mon, 22 Jul 2002 18:46:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1kkEB009296 for mobile-ip-dist; Mon, 22 Jul 2002 18:46:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1khoN009289; Mon, 22 Jul 2002 18:46:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26021; Mon, 22 Jul 2002 18:46:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18960; Mon, 22 Jul 2002 19:46:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA09749; Mon, 22 Jul 2002 18:46:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1kgv26226; Mon, 22 Jul 2002 18:46:42 -0700 X-mProtect: <200207230146> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4KPbqd; Mon, 22 Jul 2002 18:46:40 PDT Message-ID: <3D3CB580.708DE3A7@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:46:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020720224137.AEEC64B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Itojun, there have never been any suboptions defined for the home address option. itojun@iijlab.net wrote: > > >The home address option is the same in format as the > >previous version. The additional requirement now is > >only that now it's required to be secured somehow. > > no it is not. also option type # got changed > draft 04-06: type, length and an IPv6 address, type # = "196???" > draft 07: type, length, an IPv6 address and suboptions, > type # = "196???" > draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 > draft 17-18: type, length and an IPv6 address, type # = 201 > > note that existence/non-existence of suboption will affect validation > of incoming messages. when there is no vaild sub-option defined, I would expect one to write code which would drop the packet, if the packet came with some sub-option. > no wonder vendors ship without HAO support, it is impossible to > support something that changes this often. it has been an internet draft so far. people who implement internet drafts do it knowing very well that it could change. > as for *BSD/KAME, it is > decided that we won't merge anything related to mobile-ip6 into main > *BSD distribution until mobile-ip6 becomes RFC (so it won't show up > onto ExtremeWare, JunOS, MacOS X, ...). okay. fair enough. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 21:53:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03282 for ; Mon, 22 Jul 2002 21:53:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06924; Mon, 22 Jul 2002 19:53:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19821; Mon, 22 Jul 2002 18:53:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1qboN009484 for ; Mon, 22 Jul 2002 18:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1qaQ8009483 for mobile-ip-dist; Mon, 22 Jul 2002 18:52:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1qXoN009476; Mon, 22 Jul 2002 18:52:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19606; Mon, 22 Jul 2002 18:52:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20891; Mon, 22 Jul 2002 19:52:34 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA09968; Mon, 22 Jul 2002 18:52:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1qXD31896; Mon, 22 Jul 2002 18:52:33 -0700 X-mProtect: <200207230152> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdX4cpFh; Mon, 22 Jul 2002 18:52:31 PDT Message-ID: <3D3CB6DF.14DAA2CF@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:52:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Basavaraj.Patil@nokia.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020722225421.087BD4B24@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Itojun, > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. > > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). > > if it isn't enough to convince you otherwise, i think you are in > a dream world. dream world?? thats nonsense. I also think the current installed IPv6 base is going to be *insignificant* compared to the IPv6 base that is expected. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 22 23:08:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10182 for ; Mon, 22 Jul 2002 23:08:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09097; Mon, 22 Jul 2002 20:07:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16524; Mon, 22 Jul 2002 20:07:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N36PoN009851 for ; Mon, 22 Jul 2002 20:06:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N36P9P009850 for mobile-ip-dist; Mon, 22 Jul 2002 20:06:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N36HoN009835; Mon, 22 Jul 2002 20:06:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03391; Mon, 22 Jul 2002 20:06:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01188; Mon, 22 Jul 2002 21:06:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 36D5F4B25; Tue, 23 Jul 2002 12:06:08 +0900 (JST) To: Vijay Devarapalli Cc: Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Mon, 22 Jul 2002 18:46:40 MST. <3D3CB580.708DE3A7@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Tue, 23 Jul 2002 12:06:07 +0900 Message-Id: <20020723030608.36D5F4B25@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >there have never been any suboptions defined for the home address >option. >> draft 07: type, length, an IPv6 address and suboptions, >> type # = "196???" >> draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 >when there is no vaild sub-option defined, I would expect one >to write code which would drop the packet, if the packet came >with some sub-option. one problem is that draft 07-16 are silent about HAO processing when unknown suboption is attached. from the language in draft 16, i guess receiver should ignore suboptions if they are unknown to them (otherwise we cannot allow "future extension" - old implementation will not be able to talk with new implementation), but i could be wrong. anyways, the above is not the main focus of this discussion. itojun --- Sub-Options Additional information, associated with this Home Address option, that need not be present in all Home Address options sent. This use of sub-options also allows for future extensions to the format of the Home Address option to be defined. Currently, no valid sub-options are defined for use in a Home Address option. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 00:43:50 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17639 for ; Tue, 23 Jul 2002 00:43:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08425; Mon, 22 Jul 2002 21:42:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09157; Mon, 22 Jul 2002 21:42:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N4fXoN010154 for ; Mon, 22 Jul 2002 21:41:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N4fXDs010153 for mobile-ip-dist; Mon, 22 Jul 2002 21:41:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N4fToN010144 for ; Mon, 22 Jul 2002 21:41:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21978 for ; Mon, 22 Jul 2002 21:41:30 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA08940 for ; Mon, 22 Jul 2002 21:41:26 -0700 (PDT) Received: from btmail.net.cn([202.106.196.71]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm1e3d3d09e2; Tue, 23 Jul 2002 04:41:20 -0000 Received: from nwkea-mail-2.sun.com([192.18.42.14]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm363d385a27; Fri, 19 Jul 2002 10:41:04 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06905; Thu, 18 Jul 2002 19:52:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25500; Thu, 18 Jul 2002 19:52:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2oMoN021265 for ; Thu, 18 Jul 2002 19:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J2oMlt021264 for mobile-ip-dist; Thu, 18 Jul 2002 19:50:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2oJoN021257 for ; Thu, 18 Jul 2002 19:50:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18848 for ; Thu, 18 Jul 2002 19:50:21 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11148 for ; Thu, 18 Jul 2002 20:50:20 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KKA2STUMHM8ZPGI7@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 19 Jul 2002 12:49:56 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id C084C12C00F; Fri, 19 Jul 2002 02:49:55 +0000 (/etc/localtime) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 39E3912C00D; Fri, 19 Jul 2002 12:21:56 +1000 (EST) Date: Fri, 19 Jul 2002 11:21:56 +0900 From: Brett Pentland Subject: [mobile-ip] Clarification sought on role of MIN_DELAY_BETWEEN_RAS To: mobile-ip@sunroof.eng.sun.com Message-id: <125608d1254b64.1254b64125608d@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi folks, I was just wondering if anyone can confirm that the protocol constant "MIN_DELAY_BETWEEN_RAS" defined in RFC2461 as 3 seconds only relates to multicast RAs sent in response to an RS and thus is unrelated to the configuration variable "MinRtrAdvInterval" for unsolicited multicast RAs which is redefined in the Mobile IPv6 I-D. Thanks, Brett. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 03:51:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02611 for ; Tue, 23 Jul 2002 03:50:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18059; Tue, 23 Jul 2002 01:51:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02067; Tue, 23 Jul 2002 00:51:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N7nooN011519 for ; Tue, 23 Jul 2002 00:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N7noXe011518 for mobile-ip-dist; Tue, 23 Jul 2002 00:49:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N7nkoN011511; Tue, 23 Jul 2002 00:49:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27939; Tue, 23 Jul 2002 00:49:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08502; Tue, 23 Jul 2002 01:49:29 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6N7mXY27056; Tue, 23 Jul 2002 14:48:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6N7mOj11651; Tue, 23 Jul 2002 14:48:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020722225421.087BD4B24@coconut.itojun.org> References: <20020722225421.087BD4B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jul 2002 14:48:24 +0700 Message-ID: <11649.1027410504@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Tue, 23 Jul 2002 07:54:20 +0900 From: itojun@iijlab.net Message-ID: <20020722225421.087BD4B24@coconut.itojun.org> | here are a little (incomplete) list of RFC2460-compliant | implementations that does not speak/understand HAO: This is a totally irrelevant argument. It simply doesn't matter which current implementations do or do not understand the option when it comes to deciding if it should be specified as a MUST or not. That question is relevant when designing the option, and its processing in the first place though. That is, someone has to decide what happens when a new option is seen at an old node that doesn't understand it. There the choices are "too bad, old node can't participate", "old node will just ignore this and do things this other way - not optimal, but works", or "this option will be useless with all those old nodes, there's no point having it at all" (perhaps others). Here, from what I have seen, that question isn't an issue - it seems (I believe) that the "old nodes will work sub-optimally" is the approach taken - that is, they don't get communications denied (which they would if this was a new header) nor is the option just considered worthless to have at all. On the other hand, when deciding whether new implementations MUST or SHOULD implement some option, the question is entirely related to the benefit vs the cost of the option processing, for nodes that can & would implement it (or might decide not to). What old code, shipped before the option was invented, might do is clearly irrelevant - that's not going to implement it, it cannot. Continuing to talk about the existing non HAO-supporting code base when deciding MUST vs SHOULD isn't helping anyone. If your point in there somewhere is that mobile-ip won't work with old nodes, and that is important enough to worry about, then the solution would have to be to redesign the protocol, not change one compliance word. But I don't think that's it - it seems to be more related to whether all those old implementations would be conforming to a standard that didn't exist when they were shipped. And the answer is that of course they won't be, and who cares about that anyway? kre ps: this message is not stating an opinion on whether MUST or SHOULD is the right label for this option, just about this one argument point. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:08:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03041 for ; Tue, 23 Jul 2002 04:08:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17460; Tue, 23 Jul 2002 01:07:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28785; Tue, 23 Jul 2002 01:06:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N85noN011728 for ; Tue, 23 Jul 2002 01:05:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N85nvL011727 for mobile-ip-dist; Tue, 23 Jul 2002 01:05:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N85ioN011720 for ; Tue, 23 Jul 2002 01:05:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00779 for ; Tue, 23 Jul 2002 01:05:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12774 for ; Tue, 23 Jul 2002 02:05:45 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 063D86A905; Tue, 23 Jul 2002 11:05:34 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BE21E6A904; Tue, 23 Jul 2002 11:05:31 +0300 (EEST) Message-ID: <3D3D0EBF.6060704@kolumbus.fi> Date: Tue, 23 Jul 2002 11:07:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Haley Cc: mobile ip Subject: Re: [mobile-ip] BU length incorrect References: <3D3C89AB.7744893E@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > Don't know if someone noticed this already, but the length of a BU in > Section 6.1.7 is incorrect: > > "If no actual options are present in this message, no padding is > necessary and the Header Len field will be set to 4." > > A BU is the same size of a BAck now that the lifetime field was reduced > to 16 bits and the Home Address removed, it should say: > > "If no options are present in this message, 4 bytes of padding is > necessary and the Header Len field will be set to 2." Right. No, no one reported this before. I'll make it issue #77 and we'll take care of it. Thanks! Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:16:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03149 for ; Tue, 23 Jul 2002 04:16:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18055; Tue, 23 Jul 2002 02:16:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07379; Tue, 23 Jul 2002 01:16:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8G0oN011886 for ; Tue, 23 Jul 2002 01:16:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8FxTa011885 for mobile-ip-dist; Tue, 23 Jul 2002 01:15:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8FuoN011878 for ; Tue, 23 Jul 2002 01:15:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02965 for ; Tue, 23 Jul 2002 01:15:58 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA19733 for ; Tue, 23 Jul 2002 02:15:56 -0600 (MDT) Received: from btmail.net.cn([202.106.196.71]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm333d3d3c2c; Tue, 23 Jul 2002 08:15:52 -0000 Received: from nwkea-mail-2.sun.com([192.18.42.14]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm1a3d388032; Fri, 19 Jul 2002 14:14:59 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13367; Fri, 19 Jul 2002 01:39:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18355; Fri, 19 Jul 2002 01:39:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8bRoN022371 for ; Fri, 19 Jul 2002 01:37:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J8bRCU022370 for mobile-ip-dist; Fri, 19 Jul 2002 01:37:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8bNoN022363 for ; Fri, 19 Jul 2002 01:37:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06553 for ; Fri, 19 Jul 2002 01:37:25 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15963 for ; Fri, 19 Jul 2002 02:37:24 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6J8b4Y03996; Fri, 19 Jul 2002 10:37:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12729; Fri, 19 Jul 2002 10:37:04 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6J8axGF075211; Fri, 19 Jul 2002 10:37:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207190837.g6J8axGF075211@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: zhang zhishou cc: Mobileip Subject: Re: [mobile-ip] questions on binding update In-reply-to: Your message of Fri, 19 Jul 2002 12:37:45 +0800. Date: Fri, 19 Jul 2002 10:36:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Why is IPsec not used for binding updates between MN and CN? => it may be used but it is not (more) the default solution because it needs a proper authorization and some kind of global PKI. I have a ton of mails about this in my laptop but I am currently in the Narita Express (http://www.nex.v6pc.jp/) so it is a bit hard to send them... When you'll know well please read my draft about IPsec and Mobile iPv6: draft-dupont-ipsec-mipv6-01.txt Regards Francis.Dupont@enst-bretagne.fr Ps I've seen an answer from Pekka, so you should already have an idea about the authorization issue. From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:25:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03315 for ; Tue, 23 Jul 2002 04:25:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01902; Tue, 23 Jul 2002 02:26:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05341; Tue, 23 Jul 2002 01:26:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8O6oN012630 for ; Tue, 23 Jul 2002 01:24:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8O6rp012629 for mobile-ip-dist; Tue, 23 Jul 2002 01:24:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NuoN012614; Tue, 23 Jul 2002 01:23:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04917; Tue, 23 Jul 2002 01:23:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20784; Tue, 23 Jul 2002 02:23:46 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E5ECD6A907; Tue, 23 Jul 2002 11:23:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DE3CF6A904; Tue, 23 Jul 2002 11:23:43 +0300 (EEST) Message-ID: <3D3D1303.2010304@kolumbus.fi> Date: Tue, 23 Jul 2002 11:25:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kuntal Chowdhury Cc: Basavaraj.Patil@nokia.com, mat@cisco.com, john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kuntal Chowdhury wrote: > Here are two of the reasons why I think RO will be undesirable: There might be reasons at some situations to not do RO. But the spec already allows for that, either by the decision of the MN or the CN. So, we can cover the situations that you list, whether or not your reasons are valid. So can we please close this discussion, and concentrate only the discussion of what functionality is mandatory to support in the CNs? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:26:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03346 for ; Tue, 23 Jul 2002 04:26:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25494; Tue, 23 Jul 2002 01:25:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03992; Tue, 23 Jul 2002 01:25:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NaoN012612 for ; Tue, 23 Jul 2002 01:23:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8Na78012611 for mobile-ip-dist; Tue, 23 Jul 2002 01:23:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NToN012596; Tue, 23 Jul 2002 01:23:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03718; Tue, 23 Jul 2002 01:23:30 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20564; Tue, 23 Jul 2002 02:23:29 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F217A6A905; Tue, 23 Jul 2002 11:23:28 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EB3B46A904; Tue, 23 Jul 2002 11:23:26 +0300 (EEST) Message-ID: <3D3D12F2.6060805@kolumbus.fi> Date: Tue, 23 Jul 2002 11:25:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Glenn Morrow Cc: Michael Thomas , Basavaraj.Patil@nokia.com, itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <933FADF5E673D411B8A30002A5608A0E04BFA175@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn Morrow wrote: > I thought it was already decided that a CN MUST respond with a rate > limited "lack of resources" response to the request for route > optimization. Yes! > If this is the case then it seems to follow that the > processing of the HOA for this purpose MUST also be supported if the HOA > is to be a part of the request to do route optimization - but only to > this extent. Indeed. However, I believe this thread is not about the support of HAO with RO -- it is more about the support of HAO with IPsec and triangular routing. Folks are complaining that there is not sufficient reason to have a MUST for that special case. And I'm starting to agree... Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:43:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03698 for ; Tue, 23 Jul 2002 04:43:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29424; Tue, 23 Jul 2002 02:44:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08853; Tue, 23 Jul 2002 01:44:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8h7oN013045 for ; Tue, 23 Jul 2002 01:43:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8h7wS013044 for mobile-ip-dist; Tue, 23 Jul 2002 01:43:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8h0oN013029; Tue, 23 Jul 2002 01:43:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12757; Tue, 23 Jul 2002 01:43:02 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07370; Tue, 23 Jul 2002 01:43:01 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AB0326A904; Tue, 23 Jul 2002 11:42:54 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4F3616A905; Tue, 23 Jul 2002 11:42:52 +0300 (EEST) Message-ID: <3D3D177F.8090905@kolumbus.fi> Date: Tue, 23 Jul 2002 11:44:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: chowdury@nortelnetworks.com, mat@cisco.com, john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <697DAA22C5004B4596E033803A7CEF44A1315C@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > RO gives you the capability of having two end-points connected without > having to rely on intermediate nodes such as the HA being > involved. The HA is not the bottleneck. One of the benefits of RO is > lesser traffic in the backbone and to a certain degree reduced > latency. But these are some of the lesser motivations. Well, I think latency is still a very good motivation. Even if we upgraded the backbone, someone forgot to upgrade speed of light ;-) > Having a mobile anchored at some point in the network (HA) when it is > non-essential is just not the right approach. I agree. > Mandating HAO processing > in all IPv6 nodes is the only way to accomplish this and reverse > tunnelling or having a node anchored at the HA is an option only for > backward compatibility to the nodes that already deployed (which is a > pretty small percentage of IP nodes). Please remember that the HAO processing is not sufficient by itself. This whole debate is not really about RO and HAO processing -- currently the spec is NOT mandating that with any keyword, we are expecting the node requirements document to do that. However, we are mandating the combination of IPsec, triangular routing, and HAO processing. So, when you are saying "mandating HAO processing", do you IPsec+triangular+HAO combination? I would actually say that RR, RO, and HAO are really the main ingredients for a successful mobility solution. The other combination is really just a special case and I can't see it being used in the Internet for any sizeable fraction of traffic. In fact, in my code I would always do RO even if I had an IPsec SA, so the combination might not even be usable by everyone. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 04:57:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03873 for ; Tue, 23 Jul 2002 04:57:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14091; Tue, 23 Jul 2002 02:58:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10889; Tue, 23 Jul 2002 01:58:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8vFoN013196 for ; Tue, 23 Jul 2002 01:57:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8vFN9013195 for mobile-ip-dist; Tue, 23 Jul 2002 01:57:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8vCoN013188 for ; Tue, 23 Jul 2002 01:57:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11674 for ; Tue, 23 Jul 2002 01:57:14 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA13753 for ; Tue, 23 Jul 2002 02:57:10 -0600 (MDT) Received: from btmail.net.cn([202.106.196.72]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm3d3d3d45d4; Tue, 23 Jul 2002 08:57:04 -0000 Received: from patan.sun.com([192.18.98.43]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm2b3d386ff4; Fri, 19 Jul 2002 14:56:55 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19395; Thu, 18 Jul 2002 22:58:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16052; Thu, 18 Jul 2002 21:58:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4unoN021814 for ; Thu, 18 Jul 2002 21:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J4un78021813 for mobile-ip-dist; Thu, 18 Jul 2002 21:56:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J4ukoN021806 for ; Thu, 18 Jul 2002 21:56:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14357 for ; Thu, 18 Jul 2002 21:56:47 -0700 (PDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14326 for ; Thu, 18 Jul 2002 22:56:47 -0600 (MDT) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 96E0B12; Fri, 19 Jul 2002 08:00:28 +0300 (EEST) Message-ID: <3D379C0E.5080006@nomadiclab.com> Date: Fri, 19 Jul 2002 07:56:46 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020712 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhang zhishou Cc: Mobileip Subject: Re: [mobile-ip] questions on binding update References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit zhang zhishou wrote: > Hi, folks: > > I am newbie in Mobile IP and IPsec. Please forgive me for my stupid > questions. > > Why is IPsec not used for binding updates between MN and CN? > If this is topic that was already discussed and clarified, please give me > some reference, so that I could catch up with it. Short answer: Problems with scalability in key management. Longer answer: How do you arrange a pair of SAs between two arbitrary nodes that may not have anything to do with each other? Well, you could have a global PKI, but such thing does not exist today, and even if it did, you would need to make sure that the PKI carries the right kind of *authorization* information, in addition to public keys for authentication. Still longer answer: There are lots of related text, but I don't know if there is anything that just discusses your question and nothing else. There is something in the earlier texts, e.g. - Pekka Nikander, An Address Ownership Problem in IPv6, work in progress, Internet-Draft (expired), February 2001. http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt - Michael Roe, Greg O'Shea, "Child-proof Authentication for Mobile IPv6," CCR, April 2001, http://www.research.microsoft.com/~mroe/ccr2001.pdf --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 05:34:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04474 for ; Tue, 23 Jul 2002 05:34:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22182; Tue, 23 Jul 2002 03:34:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20211; Tue, 23 Jul 2002 02:34:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N9XZoN013989 for ; Tue, 23 Jul 2002 02:33:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N9XZ0N013988 for mobile-ip-dist; Tue, 23 Jul 2002 02:33:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N9XVoN013981 for ; Tue, 23 Jul 2002 02:33:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20060 for ; Tue, 23 Jul 2002 02:33:34 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28336 for ; Tue, 23 Jul 2002 02:33:33 -0700 (PDT) Received: from pdico (p-dico.rd.francetelecom.fr [10.193.165.17]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SGADPCJ; Tue, 23 Jul 2002 11:33:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2322B.F5E1E580" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] questions on binding update Date: Tue, 23 Jul 2002 11:32:53 +0200 Message-ID: Thread-Topic: [mobile-ip] questions on binding update Thread-Index: AcIyK/X7aRJQi54IEdaOfwCAXzHsRg== From: "Jean-Michel COMBES" To: "Pekka Nikander" , "zhang zhishou" Cc: "Mobileip" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2322B.F5E1E580 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Concerning the IPsec use with MIPv6, another document : Francis Dupont, How to make IPsec more mobile IPv6 friendly, June 2002, Internet Draft, draft-dupont-ipsec-mipv6-01.txt Concerning the key management, IMO, that depends on the context : 1. MN and CN in the same administrativ domain (ie. "Brother CN" case) Use of a local PKI or AAA 2. MN and CN in different administrative domains and partnership between the two domains (ie. "Friend CN" case) Use of AAA 3. MN and CN in different administrative domains and no partnership between the two domains (ie. "Random CN" case) Use of DNSsec Concerning the right kind of *authorization* information, the certs must contain the link Home Address/ID(NAI,user-FQDN, etc.). Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 -----Message d'origine----- De : Pekka Nikander [mailto:Pekka.Nikander@nomadiclab.com] Envoye : vendredi 19 juillet 2002 06:57 A : zhang zhishou Cc : Mobileip Objet : Re: [mobile-ip] questions on binding update zhang zhishou wrote: > Hi, folks: > > I am newbie in Mobile IP and IPsec. Please forgive me for my stupid > questions. > > Why is IPsec not used for binding updates between MN and CN? > If this is topic that was already discussed and clarified, please give me > some reference, so that I could catch up with it. Short answer: Problems with scalability in key management. Longer answer: How do you arrange a pair of SAs between two arbitrary nodes that may not have anything to do with each other? Well, you could have a global PKI, but such thing does not exist today, and even if it did, you would need to make sure that the PKI carries the right kind of *authorization* information, in addition to public keys for authentication. Still longer answer: There are lots of related text, but I don't know if there is anything that just discusses your question and nothing else. There is something in the earlier texts, e.g. - Pekka Nikander, An Address Ownership Problem in IPv6, work in progress, Internet-Draft (expired), February 2001. http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-owne rshi p-00.txt - Michael Roe, Greg O'Shea, "Child-proof Authentication for Mobile IPv6," CCR, April 2001, http://www.research.microsoft.com/~mroe/ccr2001.pdf --Pekka Nikander ------_=_NextPart_001_01C2322B.F5E1E580 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] questions on binding update

Hi,

Concerning the IPsec use with MIPv6, another document = :

Francis Dupont, How to make IPsec more mobile IPv6 = friendly, June 2002,
Internet Draft, = draft-dupont-ipsec-mipv6-01.txt


Concerning the key management, IMO, that depends on = the context :

1. MN and CN in the same administrativ domain (ie. = "Brother CN" case)
Use of a local PKI or AAA

2. MN and CN in different administrative domains and = partnership between the
two domains (ie. "Friend CN" case)
Use of AAA

3. MN and CN in different administrative domains and = no partnership between
the two domains (ie. "Random CN" = case)
Use of DNSsec


Concerning the right kind of *authorization* = information, the certs must
contain the link Home Address/ID(NAI,user-FQDN, = etc.).


Regards.

JMC.


France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@francetelecom.com
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 = 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 = 9E33 CFA7 0214
-----Message d'origine-----
De : Pekka Nikander [mailto:Pekka.Nikander@nomad= iclab.com]
Envoye : vendredi 19 juillet 2002 06:57
A : zhang zhishou
Cc : Mobileip
Objet : Re: [mobile-ip] questions on binding = update


zhang zhishou wrote:
> Hi, folks:
>
> I am newbie in Mobile IP and IPsec. Please = forgive me for my stupid
> questions.
>
> Why is IPsec not used for binding updates = between MN and CN?
> If this is topic that was already discussed and = clarified, please give me
> some reference, so that I could catch up with = it.
Short answer:  Problems with scalability in key = management.
Longer answer:  How do you arrange a pair of SAs = between two
arbitrary nodes that may not have anything to do with = each other?
Well, you could have a global PKI, but such thing = does not exist
today, and even if it did, you would need to make = sure that the
PKI carries the right kind of *authorization* = information, in
addition to public keys for authentication.
Still longer answer:  There are lots of related = text, but I don't
know if there is anything that just discusses your = question and
nothing else.  There is something in the earlier = texts, e.g.
- Pekka Nikander,  An Address Ownership Problem = in IPv6,
   work in progress, Internet-Draft = (expired), February 2001.

http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-= address-ownershi
p-00.txt
- Michael Roe, Greg O'Shea, "Child-proof = Authentication for Mobile IPv6,"
   CCR, April 2001, http://www.r= esearch.microsoft.com/~mroe/ccr2001.pdf
--Pekka Nikander

------_=_NextPart_001_01C2322B.F5E1E580-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 08:08:15 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07318 for ; Tue, 23 Jul 2002 08:08:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24117; Tue, 23 Jul 2002 06:08:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13219; Tue, 23 Jul 2002 05:08:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NC7coN014436 for ; Tue, 23 Jul 2002 05:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NC7cZC014435 for mobile-ip-dist; Tue, 23 Jul 2002 05:07:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NC7YoN014428 for ; Tue, 23 Jul 2002 05:07:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17053 for ; Tue, 23 Jul 2002 05:07:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22706 for ; Tue, 23 Jul 2002 06:07:35 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07197; Tue, 23 Jul 2002 08:06:32 -0400 (EDT) Message-Id: <200207231206.IAA07197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-satish-mobileip-inter-technology-00.txt Date: Tue, 23 Jul 2002 08:06:31 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP considerations for Inter-technology handovers Author(s) : S. Jamadagni, D. Satish Filename : draft-satish-mobileip-inter-technology-00.txt Pages : 8 Date : 22-Jul-02 Multi mode terminals are becoming pervasive. In a multi mode environment, Mobile Terminals (MTs) move from the coverage of one radio access network to another. There is a need to maintain ongoing network sessions to support seamless services. For example, a MT may roam between a 3G cellular network and a wireless LAN seamlessly with session continuity. It is possible for a single service provider to support multiple modes but it is expected that different modes will be supported by different service providers. For example WLAN support can be enterprise supported where as 3G services are supported by a wide area service provider. In this draft we discuss handover support between multiple domains (modes) where a MT can use different IP addresses or can use a global IP address. Handover between different modes will then require greater federation capabilities between the different IP domains. In this draft we discuss Home Agent federation capabilities over Mobile IP so that inter-technology, inter-domain handovers are better supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-satish-mobileip-inter-technology-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-satish-mobileip-inter-technology-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-satish-mobileip-inter-technology-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020722134439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-satish-mobileip-inter-technology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-satish-mobileip-inter-technology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020722134439.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 08:16:23 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07701 for ; Tue, 23 Jul 2002 08:16:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00508; Tue, 23 Jul 2002 05:15:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18644; Tue, 23 Jul 2002 05:14:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCE0oN014579 for ; Tue, 23 Jul 2002 05:14:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NCE0Jv014578 for mobile-ip-dist; Tue, 23 Jul 2002 05:14:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCDtoN014571 for ; Tue, 23 Jul 2002 05:13:56 -0700 (PDT) Received: from lillen (hobo076.Eng.Sun.COM [129.146.31.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6NCDpg25675; Tue, 23 Jul 2002 14:13:51 +0200 (MEST) Date: Tue, 23 Jul 2002 03:14:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Issue 63: Multicast To: "Alan O'Neill" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <8C92E23A3E87FB479988285F9E22BE46012031CD@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I should also mention that given this issue also > exists for MIPv4, there is less of an 'architectural' barrier there because > the MN is not prohibited in IPv4 from using the HoA as a source address on a > foreign link. The same real-world constraints exist in IPv4 (ingress filtering for all packets and RPF checks for multicast) as in IPv6. Of course, the mobile IPv4 documents might fail to mention this detail, but that isn't a fault of the mobile IPv6 document :-) > **************************************************************************** > ************************************ > This email may contain confidential and privileged material for the sole use > of the > intended recipient. Any review or distribution by others is strictly > prohibited. > If you are not the intended recipient please contact the sender and delete > all copies. > **************************************************************************** > ************************************* Could you fix the above trailer in the email? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 09:02:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09799 for ; Tue, 23 Jul 2002 09:02:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19146; Tue, 23 Jul 2002 07:03:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26571; Tue, 23 Jul 2002 06:03:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND1goN014836 for ; Tue, 23 Jul 2002 06:01:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ND1fIs014835 for mobile-ip-dist; Tue, 23 Jul 2002 06:01:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND1YoN014820; Tue, 23 Jul 2002 06:01:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05725; Tue, 23 Jul 2002 06:01:37 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15763; Tue, 23 Jul 2002 07:01:36 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NCvRd05592; Tue, 23 Jul 2002 07:57:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 07:57:13 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04C5D1C3@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Jari Arkko Cc: Michael Thomas , Basavaraj.Patil@nokia.com, itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 07:57:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23248.721EF220" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23248.721EF220 Content-Type: text/plain; charset="iso-8859-1" I agree - let's move on. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, July 23, 2002 3:25 AM > To: Morrow, Glenn [RICH2:C310:EXCH] > Cc: Michael Thomas; Basavaraj.Patil@nokia.com; itojun@iijlab.net; > charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > Glenn Morrow wrote: > > > I thought it was already decided that a CN MUST respond with a rate > > limited "lack of resources" response to the request for route > > optimization. > > > Yes! > > > If this is the case then it seems to follow that the > > processing of the HOA for this purpose MUST also be > supported if the HOA > > is to be a part of the request to do route optimization - > but only to > > this extent. > > > Indeed. > > However, I believe this thread is not about the support of > HAO with RO -- > it is more about the support of HAO with IPsec and triangular routing. > Folks are complaining that there is not sufficient reason to > have a MUST > for that special case. And I'm starting to agree... > > Jari > > > ------_=_NextPart_001_01C23248.721EF220 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

I agree - let's move on.

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
> Sent: Tuesday, July 23, 2002 3:25 AM
> To: Morrow, Glenn [RICH2:C310:EXCH]
> Cc: Michael Thomas; Basavaraj.Patil@nokia.com; itojun@iijlab.net;
> charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com;
> ipng@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated
>
>
> Glenn Morrow wrote:
>
> > I thought it was already decided that a CN MUST respond with a rate
> > limited "lack of resources" response to the request for route
> > optimization.
>
>
> Yes!
>
> > If this is the case then it seems to follow that the
> > processing of the HOA for this purpose MUST also be
> supported if the HOA
> > is to be a part of the request to do route optimization -
> but only to
> > this extent.
>
>
> Indeed.
>
> However, I believe this thread is not about the support of
> HAO with RO --
> it is more about the support of HAO with IPsec and triangular routing.
> Folks are complaining that there is not sufficient reason to
> have a MUST
> for that special case. And I'm starting to agree...
>
> Jari
>
>
>

------_=_NextPart_001_01C23248.721EF220-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 10:42:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14454 for ; Tue, 23 Jul 2002 10:42:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19203; Tue, 23 Jul 2002 08:42:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19162; Tue, 23 Jul 2002 07:42:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NEfYoN015130 for ; Tue, 23 Jul 2002 07:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NEfYqg015129 for mobile-ip-dist; Tue, 23 Jul 2002 07:41:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NEfUoN015122; Tue, 23 Jul 2002 07:41:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18917; Tue, 23 Jul 2002 07:41:31 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19748; Tue, 23 Jul 2002 08:41:30 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6NEjMj02093; Tue, 23 Jul 2002 09:45:22 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 09:41:28 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:41:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 09:41:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13177@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIx0r/Hi6aFc2SWR1WKDfjwI8vfFwAhDX+A To: Cc: , , X-OriginalArrivalTime: 23 Jul 2002 14:41:16.0977 (UTC) FILETIME=[00622210:01C23257] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6NEfVoO015123 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >>I am of the opinion that the scale of IPv6 deployment today is still >>in its infancy and the impacts associated with mandating the HAO >>processing on all IPv6 nodes is far less than maybe two years from >>now. > > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. So are you suggesting that these OS' will have no revisions whatsoever in the future and they are now frozen forever? > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). So every product that uses the IPv6 component of these OS' will not be compliant with the standard. These nodes can still operate just as well via the reverse tunnelling mechanism. I do not expect these nodes to be even upgraded to support the RR scheme as well. Thats just something we have to live with. > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). I know. But you also have to realize that OS' evolve and new features are added. > > if it isn't enough to convince you otherwise, i think you are in > a dream world. There is an aspect of *tunnel vision* w.r.t your statement above. I realize there are commercial networks and commercial products running IPv6 that do not have HAO processing capability. But you are not looking at the potential scale of the nodes that are yet to be developed and deployed. > >itojun > Anyway, this argument is not leading to any conclusions. I would recommend that we move forward. Let the IESG decide if the HAO processing as MUST is too cumbersome for IPv6 nodes. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 11:49:17 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19287 for ; Tue, 23 Jul 2002 11:49:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00226; Tue, 23 Jul 2002 09:49:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27183; Tue, 23 Jul 2002 08:49:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NFmLoN015429 for ; Tue, 23 Jul 2002 08:48:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NFmLD0015428 for mobile-ip-dist; Tue, 23 Jul 2002 08:48:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NFmEoN015412; Tue, 23 Jul 2002 08:48:14 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26744; Tue, 23 Jul 2002 08:48:16 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15175; Tue, 23 Jul 2002 08:48:15 -0700 (PDT) Received: from PTHUBERTW2K2 (dhcp-nic-val-26-104.cisco.com [64.103.26.104]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA11889; Tue, 23 Jul 2002 17:47:56 +0200 (MET DST) From: "Pascal Thubert" To: , Cc: , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 24 Jul 2002 00:48:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A13177@daebe007.NOE.Nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit >I am of the opinion that the scale of IPv6 deployment today is still >in its infancy and the impacts associated with mandating the HAO >processing on all IPv6 nodes is far less than maybe two years from >now. Is that the point? My point was that the support of binding exchange and binding cache will be useless is several widely deployed configurations, example: - Web clusters - Appliances - Core routers ... You name it. On the other hand, having to support BU is not only additional code, it's also additional resources in constrained environments, and lower quality of service, since it may delay the establishment of the connection (I'm not sure that the draft is very clear about the use of the reverse tunnel while the RO is being established). It's also assuming that the trade off of having a binding cache is always preferable as opposed to other means of validating the HAO. The "always" is a "more often than not" at best, IMHO. Again, examples: - Trusted environment such as Intranet - BU piggybacking, or other means to sign every HaO, for CPU rich - memory poor environments such as load balancers and traffic splitters - Uselessness for attackers if application layer AAA is performed before any other process takes place (e.g. Web Server in a DMZ) I would not "MUST" a design point which degrades the performances of all modes of operation based on the assumptions on one. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Basavaraj.Patil@nokia.com Sent: Tuesday, July 23, 2002 4:41 PM To: itojun@iijlab.net Cc: charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated >>I am of the opinion that the scale of IPv6 deployment today is still >>in its infancy and the impacts associated with mandating the HAO >>processing on all IPv6 nodes is far less than maybe two years from >>now. > > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. So are you suggesting that these OS' will have no revisions whatsoever in the future and they are now frozen forever? > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). So every product that uses the IPv6 component of these OS' will not be compliant with the standard. These nodes can still operate just as well via the reverse tunnelling mechanism. I do not expect these nodes to be even upgraded to support the RR scheme as well. Thats just something we have to live with. > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). I know. But you also have to realize that OS' evolve and new features are added. > > if it isn't enough to convince you otherwise, i think you are in > a dream world. There is an aspect of *tunnel vision* w.r.t your statement above. I realize there are commercial networks and commercial products running IPv6 that do not have HAO processing capability. But you are not looking at the potential scale of the nodes that are yet to be developed and deployed. > >itojun > Anyway, this argument is not leading to any conclusions. I would recommend that we move forward. Let the IESG decide if the HAO processing as MUST is too cumbersome for IPv6 nodes. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 14:29:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27978 for ; Tue, 23 Jul 2002 14:29:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17038; Tue, 23 Jul 2002 12:29:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10038; Tue, 23 Jul 2002 11:29:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NISOoN016041 for ; Tue, 23 Jul 2002 11:28:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NISOj1016040 for mobile-ip-dist; Tue, 23 Jul 2002 11:28:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NISLoN016033 for ; Tue, 23 Jul 2002 11:28:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07557 for ; Tue, 23 Jul 2002 11:28:23 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04085 for ; Tue, 23 Jul 2002 11:28:22 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6NISsi19485 for ; Tue, 23 Jul 2002 21:28:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 21:28:21 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 21:28:21 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 13:27:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Fast handovers - proposal for moving forward Date: Tue, 23 Jul 2002 13:27:36 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1318C@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Fast handovers - proposal for moving forward Thread-Index: AcItsnPxtOGzPo7kT/uJKHPcuIgnVwEw3vNA To: , X-OriginalArrivalTime: 23 Jul 2002 18:27:37.0551 (UTC) FILETIME=[9F0945F0:01C23276] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6NISLoN016034 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >Hi, > >I didn't have enough time in the meeting to explain >clearly what I meant when we discussed Phil's proposal. >Since I suddenly have excellent WLAN coverage in the >room, I'll try to do it now! > >First of all, I'm not sure that the WG is actually >split. In fact, after reading all emails, I think we >agree on many issues. Let me try to list them and >see if I'm right. I think we agree on the following: > >- L2 triggers will make Fast handovers perform better. I do not believe there is any disagreement about this. >- L2 triggers are needed. But the Mobile IP WG fast HO specification should only be cognizant of the existence of L2 triggers and not try to figure out what L2 triggers are available on various links. So the degree to which any details about L2 triggers are documented should be quite abstract. >- We need an access independent solution. I believe that is what the FMIPv6 spec's aim is. > >But we disagree on the level of detail at which L2 triggers >should be included in the draft, and the value of tunnel-based >handover (I think). Comment on detail of L2 tiggers above. >So, to make my comment clear, I wasn't not against >Phil's proposal to have a separate draft for Fast >Handovers in 802.11. I was only against the implicit >content of such document. The signaling details and message details for such a document would be derived from the FMIPv6 specification. I am of the opinion that a specification for FMIPv6 over 802.11 will simply specify a much more narrow scenario for doing Fast HOs. The current FMIPv6 specification provides multiple scenarios (MN sending a Proxy Solict or AR sending the Proxy Advt, MN moving before sending or receiving any solicit or advt etc.). Some of these may not be valid within the scope of 802.11. However I am not sure yet if the details of 802.11 link layer need to be covered here (eg. the MN completes the Associate with an AP. So will there be details about what the WLAN driver will provide to the FastHO module at the IP layer?) > >I think that the current draft (v5) provides an >access independent framework for Fast handovers, >assuming some hints from lower layers, like >L2 (in the MN or the AR depending on the type >of link) knows that handover is about to happen >and will inform the IP layer. I believe that's >about as far as the doc needs to say. However, >to get this stuff deployed and make it useful, >more detail is needed. But I don't think that >this draft can possibly include all the details >relevant to all link layers. This is where Fast >Handovers over foo documents would be needed. > >These documents can show exactly what triggers >are needed, and how to integrate FMIPv6 signalling >at the right time. Frankly, even if the current >draft shows some names for L2 triggers, I don't >think it would be useful. We need more detail >for each link layer. > I agree with your views here. However I believe that you could implement fast HOs based on implementation dependent triggers to test interoperability. If I have access to my WLAN driver code, I could build triggers that would initiate the Proxy Rtr Solicit from the MN. As long as the routers are capable of processing the request, Fast HO can be accomplished without having to do an explicit specification. >So, to this extent, I think that an FMIPv6 over >802.11 doc is needed. But I definitely don't think we should >do a different IP layer protocol standardised for each link >layer. I believe it is unnecessary, let alone >defeats the purpose of doing any fast handover scheme >on the IP layer. I do not believe anyone is proposing doing that. > >Does this make sense to anyone ? >I wish we had a show of hands during the meeting but >there was no time to discuss it, because I don't think >the WG is very divided on this actually. I tend to agree. There are a few issues on which people have some strong opinions, but the general consensus on the approach to fast HOs is far greater. > >Hesham > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 14:55:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29115 for ; Tue, 23 Jul 2002 14:55:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11296; Tue, 23 Jul 2002 12:55:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23104; Tue, 23 Jul 2002 11:55:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NIsjoN016392 for ; Tue, 23 Jul 2002 11:54:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NIsiIa016391 for mobile-ip-dist; Tue, 23 Jul 2002 11:54:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NIsboN016375; Tue, 23 Jul 2002 11:54:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18723; Tue, 23 Jul 2002 11:54:39 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01910; Tue, 23 Jul 2002 12:54:38 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NIsid11110; Tue, 23 Jul 2002 13:54:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 13:54:29 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D240531CEFE@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Pekka Savola Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Implications of Route Optimization Date: Tue, 23 Jul 2002 13:54:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2327A.5D35A1B0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2327A.5D35A1B0 Content-Type: text/plain; charset="iso-8859-1" Note: I am posting this as a new thread since we are not discussing about the issue of mandatory processing of HAO in the IPv6 CN anymore. Pekka Savola wrote: > Assuming CN is in ISP 1's network, MN is vising ISP 2's > network and HA is > in ISP 3's network. > > Your argument was, if I got it right, that route optimizations is bad > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > get revenue. > > This seems ridiculous. > Consider the scenario where ISP 3 (Home domain of the user) does volume based accounting i.e. byte counts. The visited domain (ISP 2) does not support volume based accounting. Therefore the home domain assigns an AAA client in a router (which may well be the HA) which is guaranteed to be in the data path. Reverse tunneling is enforced by the home domain to ensure that the all the data to/from the user pass through the home domain. Now the user performs RO with the CN. The CN starts sending data directly to the MN bypassing the home domain. Therefore the byte counts in the AAA client in the home domain will not be accurate. > > If TE is used to route the traffic via such slow paths the difference is > > noticeable (at least, without measurement tools), the network is designed > > and operated badly, period. Nobody would want to pay for that kind of > > service. > > > > What makes you think that the TEed route between the CN and the MN > (i.e. Chicago -> Miami -> Dallas) will be a slow path? > The speed of light is a constant. It seems the assumption is that the link between CN and the MN is an optical link. Let me explain what determines the speed and quality of an optical link. A few important factors for a light path are: 1. Fiber type (DSF, USF, NZDF etc.) 2. EDFAs and Ramans amplifiers. 3. Number of 3Rs (Retiming, Reshaping, Reamplifying function). 4. Transmission systems (OC-48/192/768 etc.) 5. Network type i.e. Ring or Mesh. Say CN is in site A, MN in site B and HA in site C. Say the link between site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs between A -> B is more than the number of 3Rs for the link A -> C -> B. Therefore the link speed, quality and available bandwidth will be far better for A -> C -> B than A -> B. Now if the MN performs RO, then it will end up shifting the traffic from a better link (A -> C -> B) to a worse link (A -> B). This will be the case when the link A -> B is not congested. When the link between A -> B is congested, and TE is implemented, the traffic may be shifted back to the original link A- > C -> B. That will have the opposite effect of RO. I hope it is clear now that the speed of light is not the limiting factor for a light path. Moreover performing RO w/o knowledge of the network topology and constraints does not guarantee good results. > > Do you think the shortest path is ALWAYS the best/fastest path? > Almost always, yes. When it's not, it's almost best, which is roughly the > same thing. All of this amounts to advantages by route optimization. > (I'm disregarding stuff like extremely severe network congestion here, as > we're talking about stable scenarios here.) The shortest path may not be the best/fastest path even in stable scenarios. It depends on the factors listed above for the light paths. ------_=_NextPart_001_01C2327A.5D35A1B0 Content-Type: text/html; charset="iso-8859-1" Implications of Route Optimization

Note: I am posting this as a new thread since we are not
discussing about the issue of mandatory processing of HAO in the IPv6 CN anymore.

Pekka Savola wrote:
> Assuming CN is in ISP 1's network, MN is vising ISP 2's
> network and HA is
> in ISP 3's network.
>
> Your argument was, if I got it right, that route optimizations is bad
> because traffic is between ISP 1 and ISP 2 so ISP 3 does not
> get revenue.
>
> This seems ridiculous. 
>

Consider the scenario where ISP 3 (Home domain of the user) does volume
based accounting i.e. byte counts. The visited domain (ISP 2) does
not support volume based accounting. Therefore the home domain assigns
an AAA client in a router (which may well be the HA) which is guaranteed to
be in the data path. Reverse tunneling is enforced by the home domain to
ensure that the all the  data to/from the user pass through the home
domain. Now the user performs RO with the CN. The CN starts sending data
directly to the MN bypassing the home domain. Therefore the byte counts
in the AAA client in the home domain will not be accurate.


> > If TE is used to route the traffic via such slow paths the difference is
> > noticeable (at least, without measurement tools), the network is designed
> > and operated badly, period.  Nobody would want to pay for that kind of
> > service.
> >
>
> What makes you think that the TEed route between the CN and the MN
> (i.e. Chicago -> Miami -> Dallas) will be a slow path?

> The speed of light is a constant.

It seems the assumption is that the link between CN and the MN is an optical
link. Let me explain what determines the speed and quality of an optical
link. A few important factors for a light path are:
1. Fiber type (DSF, USF, NZDF etc.)
2. EDFAs and Ramans amplifiers.
3. Number of 3Rs (Retiming, Reshaping, Reamplifying function).
4. Transmission systems (OC-48/192/768 etc.)
5. Network type i.e. Ring or Mesh.

Say CN is in site A, MN in site B and HA in site C. Say the link between
site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the
A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs
between A -> B is more than the number of 3Rs for the link A -> C -> B.
Therefore the link speed, quality and available bandwidth will be far better
for A -> C -> B than A -> B.
Now if the MN performs RO, then it will end up shifting the traffic from
a better link (A -> C -> B) to a worse link (A -> B). This will be the case
when the link A -> B is not congested.
When the link between A -> B is congested, and TE is implemented, the
traffic may be shifted back to the original link A- > C -> B. That will have
the opposite effect of RO.
I hope it is clear now that the speed of light is not the limiting factor for a
light path. Moreover performing RO w/o knowledge of the network topology
and constraints does not guarantee good results.


> > Do you think the shortest path is ALWAYS the best/fastest path?

> Almost always, yes.  When it's not, it's almost best, which is roughly the
> same thing.  All of this amounts to advantages by route optimization.

> (I'm disregarding stuff like extremely severe network congestion here, as
> we're talking about stable scenarios here.)

The shortest path may not be the best/fastest path even in stable scenarios.
It depends on the factors listed above for the light paths.

------_=_NextPart_001_01C2327A.5D35A1B0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 15:22:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00434 for ; Tue, 23 Jul 2002 15:22:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26347; Tue, 23 Jul 2002 13:22:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29174; Tue, 23 Jul 2002 12:22:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJLCoN016571 for ; Tue, 23 Jul 2002 12:21:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NJLBVp016570 for mobile-ip-dist; Tue, 23 Jul 2002 12:21:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJL8oN016563; Tue, 23 Jul 2002 12:21:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28690; Tue, 23 Jul 2002 12:21:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02550; Tue, 23 Jul 2002 12:21:10 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23146; Tue, 23 Jul 2002 12:21:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NJL9009122; Tue, 23 Jul 2002 12:21:09 -0700 X-mProtect: <200207231921> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd16ohAN; Tue, 23 Jul 2002 12:21:07 PDT Message-ID: <3D3DACA3.2E55F55D@iprg.nokia.com> Date: Tue, 23 Jul 2002 12:21:07 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020722225421.087BD4B24@coconut.itojun.org> <3D3CB6DF.14DAA2CF@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Randy Bush wrote: > the question is what works best. it would be good if we > focussed on that. exactly. couldnt agree more. but I keep hearing from the KAME folks again and again "we already have IPv6 implementations which do not understand HAO, we dont want HAO mandated" (which makes no sense to me). Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 15:31:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00795 for ; Tue, 23 Jul 2002 15:31:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24787; Tue, 23 Jul 2002 13:31:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06726; Tue, 23 Jul 2002 12:31:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJT5oN016733 for ; Tue, 23 Jul 2002 12:29:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NJT50r016732 for mobile-ip-dist; Tue, 23 Jul 2002 12:29:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJSuoN016717; Tue, 23 Jul 2002 12:28:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02023; Tue, 23 Jul 2002 12:28:58 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23364; Tue, 23 Jul 2002 13:28:57 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C2B514B23; Wed, 24 Jul 2002 04:28:34 +0900 (JST) To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Tue, 23 Jul 2002 12:21:07 MST. <3D3DACA3.2E55F55D@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Wed, 24 Jul 2002 04:28:33 +0900 Message-Id: <20020723192835.C2B514B23@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >but I keep hearing from the KAME folks again and again >"we already have IPv6 implementations which do not understand >HAO, we dont want HAO mandated" (which makes no sense to me). MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't need bidir-tunnel (since it won't be used). if we have bidir-tunnel, HAO is okay with SHOULD. i don't want a pie-throwing match, but it seems that you want it... i keep hearing from you "we can ignore currently-deployed IPv6 codebase" which is total nonsense (or total ignorance of the current situation) to me. IPv6 is not a toy in your lab any more. we have people depend on it, we have serious IPv6 commercial network operation. i suggest to leave the SHOULD/MUST decision to jari, the main editor. itojun From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 16:15:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02787 for ; Tue, 23 Jul 2002 16:15:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04467; Tue, 23 Jul 2002 14:15:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22997; Tue, 23 Jul 2002 13:15:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKDmoN017014 for ; Tue, 23 Jul 2002 13:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKDmP8017013 for mobile-ip-dist; Tue, 23 Jul 2002 13:13:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKDioN017006; Tue, 23 Jul 2002 13:13:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22424; Tue, 23 Jul 2002 13:13:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09838; Tue, 23 Jul 2002 14:13:45 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26121; Tue, 23 Jul 2002 13:13:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKDhS08879; Tue, 23 Jul 2002 13:13:43 -0700 X-mProtect: <200207232013> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgvhGEW; Tue, 23 Jul 2002 13:13:40 PDT Message-ID: <3D3DB8F5.D15CC4FA@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:13:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020723192835.C2B514B23@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Itojun, itojun@iijlab.net wrote: > > MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't > need bidir-tunnel (since it won't be used). if we have bidir-tunnel, > HAO is okay with SHOULD. it is a MUST implement, not MUST use. you might not be able to use it all the time. so we have bidirectional tunneling (when you cant/dont want to do Route Optimization or triangle routing). got it?? > i don't want a pie-throwing match, but it seems that you want it... > i keep hearing from you "we can ignore currently-deployed IPv6 > codebase" which is total nonsense (or total ignorance of the current where did you get that idea from? Mobile nodes can have sessions with IPv6 nodes, which dont implement HAO. its there in the current spec. got it?? look at Robert Elz's answer. I dont have to say anything more. > situation) to me. IPv6 is not a toy in your lab any more. we have > people depend on it, we have serious IPv6 commercial network operation. > > i suggest to leave the SHOULD/MUST decision to jari, the main editor. this is funny. the WG decides and Jari edits it in. maybe the WG chairs can clarify this to you. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 16:30:54 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03245 for ; Tue, 23 Jul 2002 16:30:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14005; Tue, 23 Jul 2002 14:31:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00129; Tue, 23 Jul 2002 13:31:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKThoN017206 for ; Tue, 23 Jul 2002 13:29:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKThRR017205 for mobile-ip-dist; Tue, 23 Jul 2002 13:29:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKTeoN017198; Tue, 23 Jul 2002 13:29:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00449; Tue, 23 Jul 2002 13:29:43 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22183; Tue, 23 Jul 2002 13:29:42 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 16:24:05 -0400 Message-ID: From: Phil Roberts To: "'itojun@iijlab.net'" , Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 16:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, this discussion doesn't seem to be going anywhere at the point. Perhaps we can drop it? The decision of MUST/SHOULD is up to the working group to recommend in its spec, and Jari will reflect that decision when he produces the final spec. The consensus that has been recorded so far is MUST for HAO processing, MUST for BE processing, SHOULD for RO support (although it's not listed in the node/host/ routers requirements section, 9.1 says it SHOULD be supported by all nodes). We'll look at the recent thread before determing whether the earlier consensus of MUST for HAO and BE processing are still intact. When MIP sends the spec up to the IESG for approval, we'll let the NG working group know the summary of the requirements that the MIP working group has recommended. Phil > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, July 23, 2002 3:29 PM > To: Vijay Devarapalli > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > >but I keep hearing from the KAME folks again and again > >"we already have IPv6 implementations which do not understand > >HAO, we dont want HAO mandated" (which makes no sense to me). > > MUST for HAO is self-contradictory at best. if HAO is > a MUST, we don't > need bidir-tunnel (since it won't be used). if we have > bidir-tunnel, > HAO is okay with SHOULD. > > i don't want a pie-throwing match, but it seems that > you want it... > i keep hearing from you "we can ignore currently-deployed IPv6 > codebase" which is total nonsense (or total ignorance > of the current > situation) to me. IPv6 is not a toy in your lab any > more. we have > people depend on it, we have serious IPv6 commercial > network operation. > > i suggest to leave the SHOULD/MUST decision to jari, > the main editor. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 16:44:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03578 for ; Tue, 23 Jul 2002 16:44:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18019; Tue, 23 Jul 2002 13:42:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05807; Tue, 23 Jul 2002 13:42:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKfNoN017387 for ; Tue, 23 Jul 2002 13:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKfNFZ017386 for mobile-ip-dist; Tue, 23 Jul 2002 13:41:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKfJoN017379; Tue, 23 Jul 2002 13:41:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05063; Tue, 23 Jul 2002 13:41:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10883; Tue, 23 Jul 2002 14:41:21 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27740; Tue, 23 Jul 2002 13:41:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKfKE16025; Tue, 23 Jul 2002 13:41:20 -0700 X-mProtect: <200207232041> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpUnVbe; Tue, 23 Jul 2002 13:41:18 PDT Message-ID: <3D3DBF6E.B7E419D@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:41:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Roberts CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit thanks Phil. this approach sounds good. Vijay Phil Roberts wrote: > > Folks, > > this discussion doesn't seem to be going anywhere at the point. Perhaps > we > can drop it? > > The decision of MUST/SHOULD is up to the working group to recommend in > its > spec, and Jari will reflect that decision when he produces the final spec. > The consensus that has been recorded so far is MUST for HAO processing, MUST > for > BE processing, SHOULD for RO support (although it's not listed in the > node/host/ > routers requirements section, 9.1 says it SHOULD be supported by all nodes). > We'll > look at the recent thread before determing whether the earlier consensus of > MUST for > HAO and BE processing are still intact. > > When MIP sends the spec up to the IESG for approval, we'll let the NG > working > group know the summary of the requirements that the MIP working group has > recommended. > > Phil > > > -----Original Message----- > > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > > Sent: Tuesday, July 23, 2002 3:29 PM > > To: Vijay Devarapalli > > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > > > > >but I keep hearing from the KAME folks again and again > > >"we already have IPv6 implementations which do not understand > > >HAO, we dont want HAO mandated" (which makes no sense to me). > > > > MUST for HAO is self-contradictory at best. if HAO is > > a MUST, we don't > > need bidir-tunnel (since it won't be used). if we have > > bidir-tunnel, > > HAO is okay with SHOULD. > > > > i don't want a pie-throwing match, but it seems that > > you want it... > > i keep hearing from you "we can ignore currently-deployed IPv6 > > codebase" which is total nonsense (or total ignorance > > of the current > > situation) to me. IPv6 is not a toy in your lab any > > more. we have > > people depend on it, we have serious IPv6 commercial > > network operation. > > > > i suggest to leave the SHOULD/MUST decision to jari, > > the main editor. > > > > itojun > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 18:14:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05962 for ; Tue, 23 Jul 2002 18:14:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05792; Tue, 23 Jul 2002 15:12:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10475; Tue, 23 Jul 2002 15:12:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMBqoN017968 for ; Tue, 23 Jul 2002 15:11:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NMBqmX017967 for mobile-ip-dist; Tue, 23 Jul 2002 15:11:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMBnoN017960 for ; Tue, 23 Jul 2002 15:11:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08425 for ; Tue, 23 Jul 2002 15:11:51 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06674 for ; Tue, 23 Jul 2002 16:11:50 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA03890; Tue, 23 Jul 2002 15:11:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NMBj519464; Tue, 23 Jul 2002 15:11:45 -0700 X-mProtect: <200207232211> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv61HWz; Tue, 23 Jul 2002 15:11:43 PDT Message-ID: <3D3DD49F.F36183A8@iprg.nokia.com> Date: Tue, 23 Jul 2002 15:11:43 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast handovers - proposal for moving forward References: <697DAA22C5004B4596E033803A7CEF44A1318C@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > >So, to this extent, I think that an FMIPv6 over > >802.11 doc is needed. But I definitely don't think we should > >do a different IP layer protocol standardised for each link > >layer. I believe it is unnecessary, let alone > >defeats the purpose of doing any fast handover scheme > >on the IP layer. > > I do not believe anyone is proposing doing that. > I agree that fmipv6 over 802.11 is a good exercise. What is not clear to me is why this necessarily needs to be done as a separate PS. The base spec can have a section describing this. In fact, tunnel establishment subsequent to link establishment is a proposed feature in v05: I agree better formatting is needed. > > > > >Does this make sense to anyone ? > >I wish we had a show of hands during the meeting but > >there was no time to discuss it, because I don't think > >the WG is very divided on this actually. > > I tend to agree. There are a few issues on which people have some > strong opinions, but the general consensus on the approach to fast HOs > is far greater. > I agree. -Rajeev > > > > >Hesham > > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 21:43:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09954 for ; Tue, 23 Jul 2002 21:43:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01912; Tue, 23 Jul 2002 19:41:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25922; Tue, 23 Jul 2002 18:41:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1dKoN018739 for ; Tue, 23 Jul 2002 18:39:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O1dKSn018738 for mobile-ip-dist; Tue, 23 Jul 2002 18:39:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1dGoN018731; Tue, 23 Jul 2002 18:39:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25450; Tue, 23 Jul 2002 18:39:18 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27863; Tue, 23 Jul 2002 19:39:17 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA02236; Wed, 24 Jul 2002 10:39:15 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA03239; Wed, 24 Jul 2002 10:39:14 +0900 (JST) Date: Wed, 24 Jul 2002 10:37:28 +0900 (JST) Message-Id: <20020724.103728.75347084.keiichi@iij.ad.jp> To: vijayd@iprg.nokia.com Cc: PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3DBF6E.B7E419D@iprg.nokia.com> References: <3D3DBF6E.B7E419D@iprg.nokia.com> X-Mailer: Mew version 3.0.56 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, From: Vijay Devarapalli > thanks Phil. this approach sounds good. I agree, too. We have had enough discussion and I am almost satisfied (though the discussion have not closed yet, but this is not a prpblem). Many people insist their opinion, almost all WG members hear them, and the chairmen and the editors have got enough information to go forward. Thoughout the discussion, it seems to me that the IPv6 WG will not accept the mip6 draft if the HAO/BE requirements are MUST. Even if we leave them with MUST (of course we can, the decision can be done in the mip WG inside), I think that the IESG never pass it. This creates another delay for the standard process of the mip6. I think we can leave the text for HAO/BE to the editors and wait for the new draft. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 23 22:00:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10741 for ; Tue, 23 Jul 2002 22:00:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13865; Tue, 23 Jul 2002 20:01:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00682; Tue, 23 Jul 2002 19:01:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1xuoN018959 for ; Tue, 23 Jul 2002 18:59:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O1xu7n018958 for mobile-ip-dist; Tue, 23 Jul 2002 18:59:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1xroN018951 for ; Tue, 23 Jul 2002 18:59:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18301 for ; Tue, 23 Jul 2002 18:59:40 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04512 for ; Tue, 23 Jul 2002 19:59:39 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g6O1xWAc022705 for ; Wed, 24 Jul 2002 10:59:32 +0900 (KST) Message-ID: <005f01c232b5$bfd87aa0$ad29024b@yhhan> From: "Youn-Hee Han" To: References: <23BDB0046F3ED51185CD0002A5608D240531CEFE@zrc2c009.us.nortel.com> Subject: [mobile-ip] Re: Implications of Route Optimization Date: Wed, 24 Jul 2002 10:59:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g6O1xroN018952 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Implications of Route OptimizationPekka Savola wrote: > Assuming CN is in ISP 1's network, MN is vising ISP 2's > network and HA is > in ISP 3's network. > > Your argument was, if I got it right, that route optimizations is bad > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > get revenue. > > This seems ridiculous. > Good Indication!. However, the route optimization MUST be supported in MIPv6 in order to reduce traffic amount within global Internet and alleviate the HA's loads. The abovementioned problem can be solved by serveral methods. I suggest one simple method. ISP3 has HA, which manages binding infomation about the MN. Whether the MN setups route optimization with a CN or not, the MN sends BU to the HA. Therefore, ISP3 checks the period of binding management, and can get revenue from the checking list. Youn-Hee Han Sansung AIT From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 00:19:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13916 for ; Wed, 24 Jul 2002 00:19:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18194; Tue, 23 Jul 2002 21:18:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11798; Tue, 23 Jul 2002 21:18:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O4H2oN019213 for ; Tue, 23 Jul 2002 21:17:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O4H2Lo019212 for mobile-ip-dist; Tue, 23 Jul 2002 21:17:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O4GqoN019197; Tue, 23 Jul 2002 21:16:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17857; Tue, 23 Jul 2002 21:16:54 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26383; Tue, 23 Jul 2002 22:16:53 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6O4GeA58843; Wed, 24 Jul 2002 13:16:40 +0900 (JST) Date: Wed, 24 Jul 2002 13:16:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Cc: vijayd@iprg.nokia.com, PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020724.103728.75347084.keiichi@iij.ad.jp> References: <3D3DBF6E.B7E419D@iprg.nokia.com> <20020724.103728.75347084.keiichi@iij.ad.jp> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >>>>> On Wed, 24 Jul 2002 10:37:28 +0900 (JST), >>>>> Keiichi SHIMA said: >> thanks Phil. this approach sounds good. > I agree, too. I basically agree, too. A few points: >> When MIP sends the spec up to the IESG for approval, we'll let the NG >> working >> group know the summary of the requirements that the MIP working group has >> recommended. The ipv6 wg members will check the next draft and will make comments on it when it is out , not only at the point of the IESG approval. The ipv6 wg members will also make comments at the mip wg last call (since the last call will be announced to the members as well), and at the IETF last call, especially if they have objections to the draft. > Thoughout the discussion, it seems to me that the IPv6 WG will not > accept the mip6 draft if the HAO/BE requirements are MUST. Even if we > leave them with MUST (of course we can, the decision can be done in > the mip WG inside), I think that the IESG never pass it. This creates > another delay for the standard process of the mip6. I'm not sure if this is really the case (because we cannot tell all about the future), but I'm 99% sure that many ipv6 wg members will make objections to the MUST. And, the objections will surely introduce additional delay to standardize mip6. (I'm not talking about my own position about the MUST vs SHOULD, but talking about a story that will be very likely to happen, by observing the discussions so far.) So, I hope the next draft will consider the various tradeoffs among ideal solutions to MNs, effects to CNs (both existing and future ones), and the standardization/deployment schedule. Again, I agree the ball is now in the mip wg and we should wait for the next draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 02:11:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25796 for ; Wed, 24 Jul 2002 02:11:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26470; Wed, 24 Jul 2002 00:11:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05748; Tue, 23 Jul 2002 23:11:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O6AUoN019487 for ; Tue, 23 Jul 2002 23:10:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O6AUfa019486 for mobile-ip-dist; Tue, 23 Jul 2002 23:10:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O6ANoN019471; Tue, 23 Jul 2002 23:10:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07771; Tue, 23 Jul 2002 23:10:26 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08793; Wed, 24 Jul 2002 00:10:25 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6O69eZ06155; Wed, 24 Jul 2002 09:09:41 +0300 Date: Wed, 24 Jul 2002 09:09:40 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: Re: [mobile-ip] Implications of Route Optimization In-Reply-To: <23BDB0046F3ED51185CD0002A5608D240531CEFE@zrc2c009.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 23 Jul 2002, Kuntal Chowdhury wrote: > Pekka Savola wrote: > > Assuming CN is in ISP 1's network, MN is vising ISP 2's > > network and HA is > > in ISP 3's network. > > > > Your argument was, if I got it right, that route optimizations is bad > > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > > get revenue. > > > > This seems ridiculous. > > Consider the scenario where ISP 3 (Home domain of the user) does volume > based accounting i.e. byte counts. The visited domain (ISP 2) does > not support volume based accounting. Therefore the home domain assigns > an AAA client in a router (which may well be the HA) which is guaranteed to > be in the data path. Reverse tunneling is enforced by the home domain to > ensure that the all the data to/from the user pass through the home > domain. Now the user performs RO with the CN. The CN starts sending data > directly to the MN bypassing the home domain. Therefore the byte counts > in the AAA client in the home domain will not be accurate. What is the purpose of byte counts? Most often to see how many bytes have been transferred to the node in the specified network. In Route Optimization case, such byte counts are close to zero. I see no reason to artificially try to create these byte counts. Only the node and the networks it visit know how much traffic is used. > > What makes you think that the TEed route between the CN and the MN > > (i.e. Chicago -> Miami -> Dallas) will be a slow path? > > > The speed of light is a constant. > > It seems the assumption is that the link between CN and the MN is an optical > link. Similar restrictios apply to non-optical links too. The main factor is the length of the link. [...] > Say CN is in site A, MN in site B and HA in site C. Say the link between > site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the > A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs > between A -> B is more than the number of 3Rs for the link A -> C -> B. > Therefore the link speed, quality and available bandwidth will be far better > > for A -> C -> B than A -> B. > Now if the MN performs RO, then it will end up shifting the traffic from > a better link (A -> C -> B) to a worse link (A -> B). This will be the case > when the link A -> B is not congested. > When the link between A -> B is congested, and TE is implemented, the > traffic may be shifted back to the original link A- > C -> B. That will have > the opposite effect of RO. > I hope it is clear now that the speed of light is not the limiting factor > for a > light path. If the sites choose to prefer A -> B path instead of A -> C -> B (and they can easily do so, if they want), it's their choice. > Moreover performing RO w/o knowledge of the network topology > and constraints does not guarantee good results. I agree that RO is sometimes not worth the effort, but where optimized path would be worse seem to be just corner cases to me. > The shortest path may not be the best/fastest path even in stable scenarios. > It depends on the factors listed above for the light paths. By 'shortest path' I mean the path that the network admins have chosen to be the best path to other site X. It does not necessarily have to physically the shortest one, of course. But it does not usually go through third parties either, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 08:28:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08217 for ; Wed, 24 Jul 2002 08:28:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02961; Wed, 24 Jul 2002 06:28:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16547; Wed, 24 Jul 2002 05:28:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OCRZoN020162 for ; Wed, 24 Jul 2002 05:27:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OCRZTT020161 for mobile-ip-dist; Wed, 24 Jul 2002 05:27:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OCRWoN020154 for ; Wed, 24 Jul 2002 05:27:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16391 for ; Wed, 24 Jul 2002 05:27:34 -0700 (PDT) From: Leelavathy.S@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01774 for ; Wed, 24 Jul 2002 06:27:32 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002072418141733:18854 ; Wed, 24 Jul 2002 18:14:17 +0530 Subject: [mobile-ip] Agent solicitation To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Sat, 27 Jul 2002 17:54:10 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 07/24/2002 05:54:14 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/24/2002 06:14:17 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/24/2002 06:14:22 PM, Serialize complete at 07/24/2002 06:14:22 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I need some clarification regarding sending of Agent solicitation message. Let us consider a mobile node moving from a home link to foreign link. The home link and foreign link are two different access networks. The Mobile node till the time it hasnt received any agent advertisement message from the Foreign agent. So when the Mobile node knows that it has come to foreign link(by link-layer mobility management) has to obtain either Care -of -address or Co-located address,in either case the Mobile node cannot initiate a Agent solicitation because if the mobile node sends any packet with its home ip address in the IP source addres field,other mobile nodes in the foreign link might be confused updating the IP address of the new mobile node in their ARP table.. So does this mean that this mobile node has no other way other than waiting for Agent advertisement from the foreign agent? Thanks Leelavathy From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 10:12:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18116 for ; Wed, 24 Jul 2002 10:12:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20532; Wed, 24 Jul 2002 08:13:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29183; Wed, 24 Jul 2002 07:13:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEBuoN020500 for ; Wed, 24 Jul 2002 07:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OEBuiv020499 for mobile-ip-dist; Wed, 24 Jul 2002 07:11:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEBqoN020492 for ; Wed, 24 Jul 2002 07:11:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01627 for ; Wed, 24 Jul 2002 07:11:53 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA07559; Wed, 24 Jul 2002 07:11:48 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm43d3ee10e; Wed, 24 Jul 2002 14:11:38 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmff3d3a2d5a; Sat, 20 Jul 2002 20:09:06 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11872; Sat, 20 Jul 2002 03:54:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11770; Sat, 20 Jul 2002 02:54:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9qxoN025157 for ; Sat, 20 Jul 2002 02:52:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6K9qxx4025156 for mobile-ip-dist; Sat, 20 Jul 2002 02:52:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K9qsoN025142 for ; Sat, 20 Jul 2002 02:52:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20324 for ; Sat, 20 Jul 2002 02:52:56 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08674 for ; Sat, 20 Jul 2002 03:52:55 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <3098H082>; Sat, 20 Jul 2002 05:52:53 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46012031CD@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue 63: Multicast Date: Sat, 20 Jul 2002 05:52:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks Eric, The mist is clearing... -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: 17 July 2002 20:09 To: Alan O'Neill Cc: 'Erik Nordmark'; 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Issue 63: Multicast > However, it is not clear at the moment whether foreign network multicast > should ultimately use the the CoA or the HoA as the source address, so we > should do that work before giving the MN the option of origination into the > foreign system because of forwards compatibility. The current archiecture requires that the CoA is used as a source when sending multicast packets on the foreign link and the HoA when reverse tunneling them through the HA. An example of this architecture is this statement in draft-ietf-ipv6-default-addr-select: For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. (And, as an aside, the precense of ingress filtering routers apply the same restriction to unicast packets from mobile nodes that are away from home). AWO> Sure - I fully appreciate that the present barriers to using the HoA as a foreign multicast source address are significant and hence why I am not suggesting adding that to the spec. These barriers additionally include the RPF check of course. Note though that hybrid multicast does not break either requirement, but again I also have some concerns with adding that to the spec. My only concern is whether the use of the CoA in MIPv6 should be allowed in the base spec given the thrashing risk which you comment on below. The current architecture of IPv6 allows the CoA address and is fine because their is no mobility. My concern is limited to MIPv6 which has its own additional architecture given that mobility, and I believe the draft 18 architecture has problems that are of concern. IPv6 also has a routing header but in the case of mobility a special type header was needed instead..mobility changes things.. So all I am requesting here is that draft 18 be amended if there is a problem, and as has happened before, IPv6 architecture should not just be accepted within MIPv6 without consideration of new mobility specific problems...In addition, IPv6 architecture will change as we learn more..I should also mention that given this issue also exists for MIPv4, there is less of an 'architectural' barrier there because the MN is not prohibited in IPv4 from using the HoA as a source address on a foreign link. Perhaps there are possible future architectures that do not have these constraints, and perhaps it makes sense exploring them to provide different performance for multicast for MNs. But I suspect this would result in added total complexity to the system. The point is that the draft is about the current architecture. AWO> And I certainly do not want to add additional complexity unless it is necessary..But I would rather have some additional complexity than a useless or unstable feature, in the same way that RR complexity had to be added to RO for different but important reasons. > I don't understand how a potential thrashing problem can be allowed to > progress through the base spec. Maybe you don't believe this exists, or is > that you believe we can trust vendors and operators to do the right thing ? I don't understand why mobility creates a unique problem here. IP traffic is known to be bursty, thus the multicast routing system needs to be able to deal with bursty sources on widely varying time scales. A mobile node moving around and using the CoA as the source just looks like multiple (bursty) sources that are not moving. AWO> Ok - so lets concentrate on this point, so that the wg can agree if there is, or is not, a problem. We can then come back to discuss / address the barriers wrt solving it. I have a couple of other jobs I have to get done first (other MIPwg stuff) and then I'll send some e-mails explaining where this is similar yet very different from the bursty source problem in conjunction with different multicast protocols. I'll also copy in some multicast experts so we can ensure we isolate the correct issues and get best advice on progression. I hope that is ok. > Clarifying this would help...Maybe this could alternatively be addressed > with some applicability words that specifically does not rule out hybrid or > otheruses of the HoA as a foreign multicast source address ? Using the HoA as source on the visited link doesn't work due to RPF checks in the current archiecture as you already pointed out. AWO> Absolutely..no disagreement here. The hybrid approach might though give us a working feature..and if none of these work then we have to either restrict the base spec, add applicability stuff and/or fix the architecture(s).. Regards, Alan. **************************************************************************** ************************************ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ************************************* From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 18:18:04 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04133 for ; Wed, 24 Jul 2002 18:18:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02643; Wed, 24 Jul 2002 15:14:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21574; Wed, 24 Jul 2002 15:14:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMDNoN022372 for ; Wed, 24 Jul 2002 15:13:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OMDM1A022371 for mobile-ip-dist; Wed, 24 Jul 2002 15:13:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMDJoN022363 for ; Wed, 24 Jul 2002 15:13:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21120 for ; Wed, 24 Jul 2002 15:13:20 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23785 for ; Wed, 24 Jul 2002 16:13:19 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OMCwM2012962; Wed, 24 Jul 2002 15:12:58 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACF53157; Wed, 24 Jul 2002 15:08:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA03782; Wed, 24 Jul 2002 15:12:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15679.9833.749904.318028@thomasm-u1.cisco.com> Date: Wed, 24 Jul 2002 15:12:57 -0700 (PDT) To: Jari Arkko Cc: Francis Dupont , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-Reply-To: <3D325097.5000406@kolumbus.fi> References: <200207150133.g6F1XSGF060243@givry.rennes.enst-bretagne.fr> <3D325097.5000406@kolumbus.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry to take so long to get around to this... Jari Arkko writes: > The question is: do we first encapsulate in an IPv6 tunnel due to > normal MIPv6 tunneling principles and then apply IPsec, or do we > first apply IPsec and only then check if MIPv6 tunneling is > necessary? IMO, it should be IP6+MIP+ESP since MIP is essentially a routing layer construct. Also: there's no need to ever protect the MIP IP-IP tunnel header itself. > If we do the former, I'm not sure how we can make the SPD > entries specific enough so that they would match only the MH > messages, but leave rest of traffic in the clear. Can IPsec > SPD entries see through the tunnel header? Do we actually care? What are the chances that somebody would go through the motions of setting up a tunnel *only* for MIP BU traffic? It seems pretty clear to me that VPN+HA is going to be a very popular combination for road warriors trying to get past the corporate edge. Or am I misreading this? Also: IMO the longer term solution here is to allow IPsec tunnels to be used instead of IP-IP tunnels to get rid of the redundant tunnel layer. (backward compatible, yadda yadda). Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 24 23:39:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12356 for ; Wed, 24 Jul 2002 23:39:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07831; Wed, 24 Jul 2002 21:39:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17327; Wed, 24 Jul 2002 20:39:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P3ceoN023243 for ; Wed, 24 Jul 2002 20:38:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P3cexa023242 for mobile-ip-dist; Wed, 24 Jul 2002 20:38:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P3caoN023233 for ; Wed, 24 Jul 2002 20:38:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26586 for ; Wed, 24 Jul 2002 20:38:40 -0700 (PDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27825 for ; Wed, 24 Jul 2002 21:38:36 -0600 (MDT) Received: from GALADRIEL (merlion-ckm.cwc.nus.edu.sg [172.16.2.73]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id LAA04947; Thu, 25 Jul 2002 11:34:39 +0800 (SGT) Message-ID: <00b801c2338c$718efef0$490210ac@GALADRIEL> Reply-To: "Raymond Jayaraj" From: "Raymond Jayaraj" To: "Rajeev Koodli" , , "Phil Roberts" , "'Hesham Soliman \(EAB\)'" , "James Kempf" Cc: References: <697DAA22C5004B4596E033803A7CEF44A1318C@daebe007.NOE.Nokia.com> <3D3DD49F.F36183A8@iprg.nokia.com> Subject: Re: [mobile-ip] Fast handovers - proposal for moving forward Date: Thu, 25 Jul 2002 11:36:19 +0800 Organization: ICR, A-STAR MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01C233CF.7E777500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01C233CF.7E777500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, Sorry to barge in like this, being a nobody in this field. But I'd like to voice my opinion on this issue, as I have some GSM protocol=20 stack development background, and my current field of work involves=20 developing an optimised tunnel-based, contextful handover protocol for research purposes. Setting aside political constraints, I think the FMIPv6 draft can=20 benefit from specifying a framework for a very generic Layer-3=20 Wireless Link Management (WLM) protocol between the MN and AR that can operate over most cellular access technologies. I had submitted a draft that introduces the WLM framework (specified as Handover Management there) for seamless, anticipative and=20 contextful handover using the tunnel-based FMIPv6 approach. Although=20 this draft is geared towards 802.11 type network, I think it can be=20 applied to most cases. Details on the draft as follows - Abstract: This document describes how the use of MN originated cell-search list=20 indications, which carry signal level and signal quality measurements=20 of access points in the immediate vicinity of the mobile node, can=20 assist in a handover scheme that factors in seamlessness, target=20 router selection, context transfer and resource usage information. URL: http://search.ietf.org/internet-drafts/draft-rjaya-seamoby-cslist-ind-00.= txt I would be glad to hear any comments on this proposal from you guys. Cheers, Raymond Jayaraj ----- Original Message -----=20 From: "Rajeev Koodli" To: Cc: ; Sent: Wednesday, July 24, 2002 6:11 AM Subject: Re: [mobile-ip] Fast handovers - proposal for moving forward > > > > >So, to this extent, I think that an FMIPv6 over > > >802.11 doc is needed. But I definitely don't think we should > > >do a different IP layer protocol standardised for each link > > >layer. I believe it is unnecessary, let alone > > >defeats the purpose of doing any fast handover scheme > > >on the IP layer. > > > > I do not believe anyone is proposing doing that. > > >=20 > I agree that fmipv6 over 802.11 is a good exercise. What > is not clear to me is why this necessarily needs to be done > as a separate PS. The base spec can have a section describing > this. In fact, tunnel establishment subsequent to link establishment > is a proposed feature in v05: I agree better formatting is needed. >=20 > > > > > > > >Does this make sense to anyone ? > > >I wish we had a show of hands during the meeting but > > >there was no time to discuss it, because I don't think > > >the WG is very divided on this actually. > > > > I tend to agree. There are a few issues on which people have some > > strong opinions, but the general consensus on the approach to fast = HOs > > is far greater. > > >=20 > I agree. >=20 > -Rajeev >=20 >=20 > > > > > > > >Hesham > > > > > -Basavaraj >=20 ------=_NextPart_000_00B5_01C233CF.7E777500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi guys,
 
Sorry to barge in like this, = being a nobody=20 in this field. But I'd
like to voice my opinion on this issue, as I have some GSM = protocol=20
stack development background, and my current field of = work involves=20
developing an optimised = tunnel-based,=20 contextful handover protocol for
research purposes.
 
Setting aside political = constraints, I=20 think the FMIPv6 draft can
benefit from specifying a = framework=20 for a very generic Layer-3 =
Wireless Link Management (WLM) protocol between the MN and AR that can
operate over most cellular = access=20 technologies.
 
I had submitted a=20 draft that introduces the WLM framework = (specified
as Handover Management there) = for seamless,=20 anticipative and =
contextful handover using the tunnel-based FMIPv6 approach. Although
this draft is geared towards 802.11 type network, = I think it can be
applied to most cases. Details on the draft as = follows -
 
Abstract:
This document describes how the = use of MN=20 originated cell-search list
indications, which carry signal = level=20 and signal quality = measurements=20
of access points in the = immediate=20 vicinity of the mobile = node, can=20
assist in a handover scheme = that=20 factors in seamlessness, = target=20
router selection, context transfer and resource usage=20 information.
URL:
http://search.ietf.org/internet-drafts/draft-rjaya-seamoby-c= slist-ind-00.txt
 
I would be glad to hear any = comments on=20 this proposal from you guys.
 
Cheers,
Raymond Jayaraj
 
 
 
----- Original Message ----- =
From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
To: <Basavaraj.Patil@nokia.com>
Cc: <hesham.soliman@era.ericsson.se>; <mobile-ip@sunroof.eng.sun.com>
Sent: Wednesday, July 24, 2002 = 6:11=20 AM
Subject: Re: [mobile-ip] Fast = handovers -=20 proposal for moving forward

> >
> = > >So, to=20 this extent, I think that an FMIPv6 over
> > >802.11 doc is = needed.=20 But I definitely don't think we should
> > >do a different = IP layer=20 protocol standardised for each link
> > >layer. I believe it = is=20 unnecessary, let alone
> > >defeats the purpose of doing any = fast=20 handover scheme
> > >on the IP layer.
> >
> = > I do=20 not believe anyone is proposing doing that.
> >
> =
> I=20 agree that fmipv6 over 802.11 is a good exercise. What
> is not = clear to=20 me is why this necessarily needs to be done
> as a separate PS. = The base=20 spec can have a section describing
> this. In fact, tunnel = establishment=20 subsequent to link establishment
> is a proposed feature in v05: I = agree=20 better formatting is needed.
>
> >
> > = >
>=20 > >Does this make sense to anyone ?
> > >I wish we had = a show=20 of hands during the meeting but
> > >there was no time to = discuss=20 it, because I don't think
> > >the WG is very divided on = this=20 actually.
> >
> > I tend to agree. There are a few = issues on=20 which people have some
> > strong opinions, but the general = consensus=20 on the approach to fast HOs
> > is far greater.
> = >
>=20
> I agree.
>
> -Rajeev
>
>
>=20 >
> > >
> > >Hesham
> > >
> = >=20 -Basavaraj
> ------=_NextPart_000_00B5_01C233CF.7E777500-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 11:20:14 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07983 for ; Thu, 25 Jul 2002 11:20:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25504; Thu, 25 Jul 2002 08:17:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05315; Thu, 25 Jul 2002 08:17:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PFFcoN024868 for ; Thu, 25 Jul 2002 08:15:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PFFcYq024867 for mobile-ip-dist; Thu, 25 Jul 2002 08:15:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PFFZoN024860 for ; Thu, 25 Jul 2002 08:15:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21950 for ; Thu, 25 Jul 2002 08:15:36 -0700 (PDT) Received: from amber.ccs.neu.edu (amber.ccs.neu.edu [129.10.116.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22773 for ; Thu, 25 Jul 2002 09:15:36 -0600 (MDT) Received: from CASABLANCA.ccs.neu.edu (crypt.ccs.neu.edu [129.10.115.162]) by amber.ccs.neu.edu (Postfix) with ESMTP id E48A51AAC5; Thu, 25 Jul 2002 11:15:34 -0400 (EDT) Message-Id: <5.0.2.1.0.20020725104935.027c0198@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 25 Jul 2002 10:59:54 -0400 To: (Recipient list suppressed) From: "G. Noubir" Subject: [mobile-ip] ACM Workshop of Wireless Security (WiSE) [in conjuntion with ACM MobiCom'02] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this Announcement ----------------------------------------------------------------------- Call for Participation ACM Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by ACM SIGMOBILE A workshop on wireless security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. For registration information, please visit http://www.crhc.uiuc.edu/~nhv/wise Preliminary Program -------------------------------------------------------------------------------- Paper Session 1 (8:30 - 10:00 a.m.) Securing Ad-Hoc Routing Protocols, M. Guerrero Zapata and N. Asokan (Nokia Research Center, Finland) Self-Organized Network Layer Security in Mobile Ad Hoc Networks, H. Yang, X. Meng and S. Lu (University of California at Los Angeles) An On-Demand Secure Routing Protocol Resilent to Byzantine Failures, B. Awerbuch, D. Holmer, C. Nita-Rotaru and H. Rubens (Johns Hopkins University) -------------------------------------------------------------------------------- Paper Session 2 (10:30 a.m. - 12:00 noon) Survivable Mobile Wireless Networks: Issues, Challenges, and Research Directions, R. Krishnan, R. Rosales Hain, A. W. Jackson, D. Levin, R. Ramanathan, J. Zao and J. P. G. Sterbenz (BBN Technologies) Secure Wireless Gateway, A. Godber and P. Dasgupta (Arizona State University) DoS and Authentication in Wireless Public Access Networks, D. B. Faria and D. R. Cheriton (Stanford University) -------------------------------------------------------------------------------- Poster session (1:00 - 2:15 p.m.) -------------------------------------------------------------------------------- Perspectives from Funding Agencies (2:15 - 3:00) Information Assurance and Research Opportunities, D. Maughan, Defence Advanced Research Projects Agency Title to be announced T. Znati, National Science Foundation and University of Pittsburgh -------------------------------------------------------------------------------- Paper Session 3 (3:30 - 5:30) A Distributed Monitoring Mechanism in Wireless Sensor Networks, C.-F. Hsin and M. Liu (University of Michigan at Ann Arbor) Using Signal Processing to Analyze Wireless Data Traffic, C. Partridge, D. Cousins, A. W. Jackson, R. Krishnan, T. Saxena, and W. T. Strayer (BBN Technologies) Securing IPv6 Neighor Discovery, J. Arkko (Ericsson Research NomadicLab), T. Aura (DoCoMoLabs U.S.A.), J. Kempf (Microsoft Research Cambridge), V.-M. Mantyla, P. Nikander (Ericsson Research NomadicLab) and M. Roe (DoCoMoLabs USA.) Performance Analysis of Elliptic Curve Cryptography for SSL, V. Gupta, S. Gupta, Sh. Chang and D. Stebila (Sun Microsystems) -------------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 17:38:36 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22292 for ; Thu, 25 Jul 2002 17:38:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26731; Thu, 25 Jul 2002 15:39:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13694; Thu, 25 Jul 2002 14:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PLbkoN025771 for ; Thu, 25 Jul 2002 14:37:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PLbjV2025770 for mobile-ip-dist; Thu, 25 Jul 2002 14:37:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PLbfoN025763 for ; Thu, 25 Jul 2002 14:37:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25835 for ; Thu, 25 Jul 2002 14:37:43 -0700 (PDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00936 for ; Thu, 25 Jul 2002 14:37:42 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 3CE4F1C0 for ; Thu, 25 Jul 2002 14:37:33 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 28C7518E2 for ; Thu, 25 Jul 2002 17:37:42 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id RAA0001995910; Thu, 25 Jul 2002 17:37:41 -0400 (EDT) Message-ID: <3D406FA5.6680BE72@hp.com> Date: Thu, 25 Jul 2002 17:37:41 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: [mobile-ip] MH type field Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was wondering why the MH type field (Section 6.1.1, draft 18) was 16 bits and not 8 bits. I couldn't find any other IPv6 header that had a type larger than 8 bits, and I don't think we'll ever have 65535 types. Should this be changed to 8 bits for type and 8 bits reserved? This also saves a nthos() for those of us on certain-endian machines, not that 3 assembly instructions is buying me anything :) -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 20:37:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25623 for ; Thu, 25 Jul 2002 20:37:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18524; Thu, 25 Jul 2002 17:36:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12238; Thu, 25 Jul 2002 17:36:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q0YooN026244 for ; Thu, 25 Jul 2002 17:34:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q0YomK026243 for mobile-ip-dist; Thu, 25 Jul 2002 17:34:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q0YkoN026236 for ; Thu, 25 Jul 2002 17:34:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25167 for ; Thu, 25 Jul 2002 17:34:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14238 for ; Thu, 25 Jul 2002 18:34:46 -0600 (MDT) Message-ID: <022b01c2343b$932efc40$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "'James Kempf'" , "Rajeev Koodli" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 25 Jul 2002 17:29:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ajoy, > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > then applying to "anticipated FMIPv6" without experimenting is not a > good idea. Protocols are sufficiently different to make considerable > performance differences. > > Ajoy-> I think claiming something works without proper data and > argument is also not a good idea. BTW, do you agree that due to higher > RTT of cellular link, FMIPv6 will require higher anticipation > time ? Yes of course. > As you increase anticipation time, the likelihood > of handover failure will increase. This statement by itself also make sense... But, the question is how much difference does it make? Experimentation can help answer this question, and this is why I was asking if your statements were based on FMIPv6 experiments... Also, how much heads up can the mobile terminal or the network get before the link is broken without any anticipation? I presume link down doesn't happen instantly, at least L2 has to exchange some messages. Is there a window in which L3 can exchange packets? > I do not think this has > anything to do with FMIPv6 or FMIPv4. You will observe > similar behavior in either case. But there is more... A fundamental difference between FMIPv6 and pre-reg FMIPv4 is that with the latter the registration request has to go all the way to home agent. This not only effects the latency, but also prevents taking advantage of L2 triggers on the oFA/oAR to precisely determine when the routing should change.. And this should make a difference in the observed performance.. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 21:40:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26392 for ; Thu, 25 Jul 2002 21:40:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11684; Thu, 25 Jul 2002 18:39:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13044; Thu, 25 Jul 2002 18:39:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q1bfoN026443 for ; Thu, 25 Jul 2002 18:37:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q1bfrA026442 for mobile-ip-dist; Thu, 25 Jul 2002 18:37:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q1bcoN026435 for ; Thu, 25 Jul 2002 18:37:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12512 for ; Thu, 25 Jul 2002 18:37:36 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07977 for ; Thu, 25 Jul 2002 19:37:35 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA27147; Thu, 25 Jul 2002 18:37:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6Q1bWY05553; Thu, 25 Jul 2002 18:37:32 -0700 X-mProtect: <200207260137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFqfw9k; Thu, 25 Jul 2002 18:37:30 PDT Message-ID: <3D40A7DA.85A2A1D8@iprg.nokia.com> Date: Thu, 25 Jul 2002 18:37:30 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ajoy, Alper, I have few questions for you. 1. How does the MN get the L2 address and IP address of the new AR ? I see the following possibilities a) PrRtAdv provides this b) upon establishing a new link, the MN does RS and gets an RA How can you avoid PrRtAdv ? Can we assume that L2 trigger provides the necessary information ? Which L2 trigger today provides such information? Isn't this at best a recommendation to future L2 designers ? In any case, can we specify that the protocol operates based on this assumption on _all_ links ? 2. When does the previous AR actually start forwarding packets on the tunnel ? Should it do so even when it has not received a FBU ? I think use of L2 triggers to more precisely time forwarding is useful when the router has received FBU. Doing forwarding in the absence of FBU is redirecting traffic without proper authorization, and as we have seen inMIPv6 security exercise, involves security considerations. Can we say here that L2 trigger will have the necessary authorization to redirect traffic ? Even so, how can a base spec generalize it to all possible link layers ? These are the crucial questions that determine the trade-off. I would like to know what you and others think. Regards, -Rajeev "Alper E. YEGIN" wrote: > Hello Ajoy, > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > then applying to "anticipated FMIPv6" without experimenting is not a > > good idea. Protocols are sufficiently different to make considerable > > performance differences. > > > > Ajoy-> I think claiming something works without proper data and > > argument is also not a good idea. BTW, do you agree that due to higher > > RTT of cellular link, FMIPv6 will require higher anticipation > > time ? > > Yes of course. > > > As you increase anticipation time, the likelihood > > of handover failure will increase. > > This statement by itself also make sense... > > But, the question is how much difference does it make? > Experimentation can help answer this question, and this is > why I was asking if your statements were based on > FMIPv6 experiments... > > Also, how much heads up can the mobile terminal or the network > get before the link is broken without any anticipation? > I presume link down doesn't happen instantly, at least L2 has to > exchange some messages. Is there a window > in which L3 can exchange packets? > > > I do not think this has > > anything to do with FMIPv6 or FMIPv4. You will observe > > similar behavior in either case. > > But there is more... A fundamental difference between > FMIPv6 and pre-reg FMIPv4 is that with the latter the > registration request has to go all the way to home agent. > This not only effects the latency, but also prevents taking > advantage of L2 triggers on the oFA/oAR to precisely > determine when the routing should change.. And this > should make a difference in the observed performance.. > > alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 21:47:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26704 for ; Thu, 25 Jul 2002 21:47:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11532; Thu, 25 Jul 2002 19:48:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15703; Thu, 25 Jul 2002 18:48:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q1lVoN026593 for ; Thu, 25 Jul 2002 18:47:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q1lULo026592 for mobile-ip-dist; Thu, 25 Jul 2002 18:47:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q1lRoN026585 for ; Thu, 25 Jul 2002 18:47:27 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.4+Sun/8.12.4) with SMTP id g6Q1lTuP990718; Thu, 25 Jul 2002 18:47:29 -0700 (PDT) Message-Id: <200207260147.g6Q1lTuP990718@jurassic.eng.sun.com> Date: Thu, 25 Jul 2002 18:50:08 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: [mobile-ip] Re: closing issue 48, identifying link changes and prev-coa To: jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Cc: Srinivasan.Damodaran@lntinfotech.com, kempf@docomolabs-usa.com, vijayd@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XIiIopev2UUkGR57gu7WBg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari, I am catching up with emails after a long vacation, sorry for the delay in replying. Has this issue been closed already ? Here is what I think: > We also discussed whether it makes sense to keep the previous coa functionality in the > draft at all, and the application of SEND techniques in this space. We also noted that > we don't enough experience to say exactly how security policies can be configured for the > prev coa forwarding to work, and we are not sure it is practical to configure per MN SAs > on the routers on the places you might be moving in. > I agree with this. In terms of initial deployment, I believe, it's not very practical idea considering the security association aspects of MN and the temporary HAs on the previously visited link. In order to simplify the base MIPv6 protocol, could we move this item to the appendix section ? When we gain more experience, we can either drop this item or develop a separate draft on this mechanism. Your proposal to deal with default router change in the link sounds fine to me. But, the whole thing can move to the appendix section for simplicity, IMHO. Thanks, -Samita > I have a primary proposal on how to go forward. This is based on the observation that > the original situation isn't very typical, so we shouldn't try to optimize it. It is > sufficient to ensure that nothing horrible happens. So, we don't care even if the forwarding > from previous coa would fail in this situation, or if some unnessary tunneling would take > place. As long as the current coa works well and nothing breaks in the old coa, we are happy. > Forwarding from previous coa should of course work in the usual case when you actually move to > another link. > > The proposal is that we allow MNs to request forwarding from previous CoA. > We do not require them to be aware that they might possibly be on the same > link due to one of the routers no longer being a default router. What happens > then is that forwarding-from-previous-coa is requested. We require the 'D' > and 'L' bits to be set in such BUs. This leads the HA to run DAD, which should > fail as the link local address is still in use on the same physical link. > Then, no forwarding will be done. (But this is fine, as the packets will > normally come to the link anyway.) > > Does this work for everyone? (A possible backup proposal: > drop this functionality and deal with it in another spec.) > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 22:46:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28173 for ; Thu, 25 Jul 2002 22:46:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22069; Thu, 25 Jul 2002 20:46:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00483; Thu, 25 Jul 2002 19:46:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q2jhoN026820 for ; Thu, 25 Jul 2002 19:45:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q2jhQt026819 for mobile-ip-dist; Thu, 25 Jul 2002 19:45:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q2jeoN026812 for ; Thu, 25 Jul 2002 19:45:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22889 for ; Thu, 25 Jul 2002 19:45:42 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01260 for ; Thu, 25 Jul 2002 20:45:41 -0600 (MDT) Message-ID: <02b201c2344d$de137b20$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" , "'James Kempf'" , References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Thu, 25 Jul 2002 19:40:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Rajeev, Let me make an attempt to answer your questions. > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Please see CARID in draft-gwon-mobileip-efwd-fmipv6-00.txt. While MN is still connected to the oAR, it can request a table that maps L2 id of access points to L2/L3 ids of access routers. Than, after the movement MN learns the L2 id of the AP, and performs a table lookup for AR information. The difference between PrRtAdv and CARID is that the latter can happen any time before handover, not necessarily right before handover or upon anticipation. > Can we assume that L2 trigger > provides the necessary information ? Nope. > Which L2 trigger today > provides such information? I'm not aware of any... > Isn't this at best a recommendation > to future L2 designers ? I personally wouldn't recommend providing this L3 information via L2 signaling. > In any case, can we specify that > the protocol operates based on this assumption on _all_ links ? > > 2. When does the previous AR actually start forwarding packets > on the tunnel ? Should it do so even when it has not received a > FBU ? I think use of L2 triggers to more precisely time > forwarding is useful when the router has received FBU. I agree. > Doing > forwarding in the absence of FBU is redirecting traffic without > proper authorization, and as we have seen inMIPv6 security > exercise, involves security considerations. Can we say here that > L2 trigger will have the necessary authorization to redirect > traffic ? Even so, how can a base spec generalize it to all possible > link layers ? IMO, we should stay in the boundaries of Mobile IP model and only allow explicite BUs change routing state... IP can receive help from L2 though, in the form of L2 suggesting a BU be sent, or L2 suggesting precise time of routing change once AR/MN decided to do so. alper > > These are the crucial questions that determine the trade-off. I > would like to know what you and others think. > > Regards, > > -Rajeev > > > > > "Alper E. YEGIN" wrote: > > > Hello Ajoy, > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > good idea. Protocols are sufficiently different to make considerable > > > performance differences. > > > > > > Ajoy-> I think claiming something works without proper data and > > > argument is also not a good idea. BTW, do you agree that due to higher > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > time ? > > > > Yes of course. > > > > > As you increase anticipation time, the likelihood > > > of handover failure will increase. > > > > This statement by itself also make sense... > > > > But, the question is how much difference does it make? > > Experimentation can help answer this question, and this is > > why I was asking if your statements were based on > > FMIPv6 experiments... > > > > Also, how much heads up can the mobile terminal or the network > > get before the link is broken without any anticipation? > > I presume link down doesn't happen instantly, at least L2 has to > > exchange some messages. Is there a window > > in which L3 can exchange packets? > > > > > I do not think this has > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > similar behavior in either case. > > > > But there is more... A fundamental difference between > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > registration request has to go all the way to home agent. > > This not only effects the latency, but also prevents taking > > advantage of L2 triggers on the oFA/oAR to precisely > > determine when the routing should change.. And this > > should make a difference in the observed performance.. > > > > alper > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jul 25 22:56:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28249 for ; Thu, 25 Jul 2002 22:56:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03776; Thu, 25 Jul 2002 20:56:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24902; Thu, 25 Jul 2002 19:56:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q2tkoN026979 for ; Thu, 25 Jul 2002 19:55:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q2tkxT026978 for mobile-ip-dist; Thu, 25 Jul 2002 19:55:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q2thoN026971 for ; Thu, 25 Jul 2002 19:55:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12363 for ; Thu, 25 Jul 2002 19:55:45 -0700 (PDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05174 for ; Thu, 25 Jul 2002 19:55:43 -0700 (PDT) Received: from GALADRIEL (merlion-ckm.cwc.nus.edu.sg [172.16.2.73]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA05140; Fri, 26 Jul 2002 10:53:09 +0800 (SGT) Message-ID: <009f01c2344f$ce8af870$490210ac@GALADRIEL> Reply-To: "Raymond Jayaraj" From: "Raymond Jayaraj" To: "Rajeev Koodli" , "Alper E. YEGIN" Cc: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" , "'James Kempf'" , , "Charlie Perkins" References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 26 Jul 2002 10:54:48 +0800 Organization: ICR, A-STAR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a 2 cents worth from ppl other than you guys discussing this issue: > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? Isn't this at best a recommendation > to future L2 designers ? In any case, can we specify that > the protocol operates based on this assumption on _all_ links ? a) PrRtAdv is a L3 element. It should not be carried over L2 messaging. b) L2 designers should not have to know what L3 is. c) Whenever a handoff involves L3, messaging should be done at L3. d) We need L3 handoff messaging to carry L2 information. Regards, Raymond From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 00:01:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29112 for ; Fri, 26 Jul 2002 00:01:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24822; Thu, 25 Jul 2002 22:01:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA23258; Thu, 25 Jul 2002 21:01:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q40UoN027308 for ; Thu, 25 Jul 2002 21:00:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q40UWC027307 for mobile-ip-dist; Thu, 25 Jul 2002 21:00:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q40RoN027300 for ; Thu, 25 Jul 2002 21:00:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16208 for ; Thu, 25 Jul 2002 21:00:30 -0700 (PDT) From: Leelavathy.S@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24894 for ; Thu, 25 Jul 2002 21:00:25 -0700 (PDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002072609234449:31513 ; Fri, 26 Jul 2002 09:23:44 +0530 Subject: [mobile-ip] MIP-Agent solicitation To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 26 Jul 2002 09:03:17 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 07/26/2002 09:03:18 AM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/26/2002 09:23:44 AM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/26/2002 09:46:50 AM, Serialize complete at 07/26/2002 09:46:50 AM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear all, I had posted a message 2 days back. I havent got any clarification on the same so far. Someone Please do help me on the following issue. I need some clarification regarding sending of Agent solicitation message. Let us consider a mobile node moving from a home link to foreign link. The home link and foreign link are two different access networks. The Mobile node till the time it hasnt received any agent advertisement message from the Foreign agent. So when the Mobile node knows that it has come to foreign link(by link-layer mobility management) has to obtain either Care -of -address or Co-located address,in either case the Mobile node cannot initiate a Agent solicitation because if the mobile node sends any packet with its home ip address in the IP source addres field,other mobile nodes in the foreign link might be confused updating the IP address of the new mobile node in their ARP table.. So does this mean that this mobile node has no other way other than waiting for Agent advertisement from the foreign agent? Thanks Leelavathy From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 00:59:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29688 for ; Fri, 26 Jul 2002 00:59:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14800; Thu, 25 Jul 2002 23:00:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14741; Thu, 25 Jul 2002 21:59:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q4x2oN027514 for ; Thu, 25 Jul 2002 21:59:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q4x2Zg027513 for mobile-ip-dist; Thu, 25 Jul 2002 21:59:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q4wxoN027506 for ; Thu, 25 Jul 2002 21:58:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28105 for ; Thu, 25 Jul 2002 21:59:00 -0700 (PDT) Received: from cwc.ucsd.edu (cwc.ucsd.edu [132.239.228.42]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14342 for ; Thu, 25 Jul 2002 22:59:00 -0600 (MDT) Received: from cts2.ucsd.edu (cts2.ucsd.edu [132.239.134.123]) by cwc.ucsd.edu (8.12.1/8.11.3) with ESMTP id g6Q4w7Vl003039 for ; Thu, 25 Jul 2002 21:58:07 -0700 (PDT) Date: Thu, 25 Jul 2002 21:58:59 -0700 (PDT) From: Joseph Soma Reddy X-X-Sender: To: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions In-Reply-To: <022b01c2343b$932efc40$a66015ac@AlperVAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello all, I would like to point out that mobility protocol should not only ensure routing to mobile hosts, it should be able to support macrodiversity(i.e. soft handoff) which is very important in cdma systems. Macrodiversity is already being incorporated in systems like HDR(High Data Rate system from Qualcomm) where the mobile can move between different cell sectors before receiving each packet. With a good mobility scheme, it is possible to extend this and enable the mobile to handoff quickly between BS, which can result in coverage and capacity increase. I have addressed this issue in a recent draft ("macrodiversity in IP based cellular networks" available at http://cwc.ucsd.edu/~soma ). The main conclusions were that the mobile should be able to handoff as soon as channel conditions changes(i.e. post-reg handoff) and that it should be possible to handoff without requiring any over-the-air signalling. I am concerned that the v5 draft provides for these mechanisms only as error conditions. Another concern I have with respect to anticipated handoffs is that it seems to place requirements on the physical/link layers with respect to how channel conditions change(i.e. it assumes that they change gradually enough to be anticipated). This is not necessarily true even in current systems. For example, the so called "street corner effect" occurs in dense urban areas where the base stations are mounted on poletops. The coverage of these BS extends linearly(along a block) rather than omnidirectionally. A mobile user who turns a street corner in such an environment will lose line-of-sight with current BS and enter line-of-sight of another BS. This causes a sudden handoff which can only be handled by post-reg type of mobility. These type of situations are common in micro-cellular networks which will become more common in future as increased demand for capacity is met by reducing cell size. Comments are appreciated. Regards, Joseph From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 02:34:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09994 for ; Fri, 26 Jul 2002 02:34:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12286; Thu, 25 Jul 2002 23:32:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18925; Thu, 25 Jul 2002 23:32:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q6VxoN027749 for ; Thu, 25 Jul 2002 23:31:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q6VxRv027748 for mobile-ip-dist; Thu, 25 Jul 2002 23:31:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q6VtoN027740; Thu, 25 Jul 2002 23:31:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01577; Thu, 25 Jul 2002 23:31:57 -0700 (PDT) From: Gaurav.Puri@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10841; Fri, 26 Jul 2002 00:31:55 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002072612181413:1325 ; Fri, 26 Jul 2002 12:18:14 +0530 Subject: [mobile-ip] draft 18 and "S" bit funda To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 26 Jul 2002 11:58:37 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 07/26/2002 11:58:37 AM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/26/2002 12:18:14 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 07/26/2002 12:18:18 PM, Serialize complete at 07/26/2002 12:18:18 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hi, MN will set the 'L' bit in the binding update when it knows that its home address has been formed using its own interface id which implies that its interface id is unique in its home subnet. So if 'L' bit is set, doing DAD for its link local address only is enough.Why do DAD for all possible MN's addresses? cheers gaurav From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 03:02:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10654 for ; Fri, 26 Jul 2002 03:02:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11827; Fri, 26 Jul 2002 01:03:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06529; Fri, 26 Jul 2002 00:03:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q72EoN027911 for ; Fri, 26 Jul 2002 00:02:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q72Dd9027910 for mobile-ip-dist; Fri, 26 Jul 2002 00:02:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q729oN027903 for ; Fri, 26 Jul 2002 00:02:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25229 for ; Fri, 26 Jul 2002 00:02:11 -0700 (PDT) Received: from muminmamman.lifix.fi ([213.15.142.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07112 for ; Fri, 26 Jul 2002 01:02:08 -0600 (MDT) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 17Xz6r-00016m-00; Fri, 26 Jul 2002 10:01:57 +0300 Date: Fri, 26 Jul 2002 10:01:57 +0300 From: Bjorn Andersson To: Leelavathy.S@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIP-Agent solicitation Message-ID: <20020726070157.GB3282@lifix.fi> Mail-Followup-To: Bjorn Andersson , Leelavathy.S@lntinfotech.com, mobile-ip@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, Jul 26 2002, at 09:03:17 +0530, Leelavathy.S@lntinfotech.com wrote: > Let us consider a mobile node moving from a home link to foreign link. > The home link and foreign link are two different access networks. > The Mobile node till the time it hasnt received any agent advertisement > message from the Foreign agent. > So when the Mobile node knows that it has come to foreign link(by > link-layer mobility management) > has to obtain either Care -of -address or Co-located address,in either case > the Mobile node cannot initiate > a Agent solicitation because if the mobile node sends any packet with its > home ip address in the IP source addres > field,other mobile nodes in the foreign link might be confused updating the > IP address of the new mobile node in their > ARP table.. The Agent soliciation message should have the MN's home address as source address. Since sending the solicitation does not involve sending any ARP messages, no ARP tables will be updated. Even if the ARP table was modified for another MN it must not modify the routing table of that MN. The MNs should route all their packets via the FA. > So does this mean that this mobile node has no other way other than waiting > for Agent advertisement from > the foreign agent? No, the MN can send a broadcast/multicast solicitation message at any time and this will not confuse any standards compliant mobile node. Hope this helps. Regards, Bjorn -- Bjorn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Innopoli 2, Tekniikantie 14, FIN-02150 Espoo From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 04:45:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12038 for ; Fri, 26 Jul 2002 04:45:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09173; Fri, 26 Jul 2002 02:45:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07349; Fri, 26 Jul 2002 01:45:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q8iXoN028210 for ; Fri, 26 Jul 2002 01:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q8iXDS028209 for mobile-ip-dist; Fri, 26 Jul 2002 01:44:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q8iUoN028202 for ; Fri, 26 Jul 2002 01:44:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07053 for ; Fri, 26 Jul 2002 01:44:33 -0700 (PDT) Received: from lkn.e-technik.tu-muenchen.de (aperol.LKN.E-Technik.TU-Muenchen.DE [129.187.222.163]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01674 for ; Fri, 26 Jul 2002 02:44:19 -0600 (MDT) Received: from lkn.e-technik.tu-muenchen.de (kufstein.LKN.E-Technik.TU-Muenchen.DE [129.187.222.111] (may be forged)) by lkn.e-technik.tu-muenchen.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g6Q8iEa02878 for ; Fri, 26 Jul 2002 10:44:14 +0200 Message-ID: <3D410BDE.4090403@lkn.e-technik.tu-muenchen.de> Date: Fri, 26 Jul 2002 10:44:14 +0200 From: Peng Gao User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: zh-TW, zh-CN, zh, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Moible IP and UDP tunneling problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, Content-Transfer-Encoding: 7bit I am a student at Technical University of Munich. I am doing my thesis named Mobile IP and NAPT Interaction. I plan to set up a new UDP data tunneling to go through the NAPT by Netfilter, but I meet a lot of problems now. Firstly, could you please give me some advice about how to distinguish Registration Reply from UDP data tunneling at Foreign Agent? Since both are UDP datagram, and have same IP Address and UDP Port. I know maybe I can check the payload of the datagram, but I am not sure which part I should check. Secondly, I plan to write a module for Home Agent, and the module stay outside of the normal Home Agent process. That means before the HA process send out the IP-in-IP data tunneling, my module works and inserts the UDP header and make it to UDP data tunneling. Now, I can not insert the UDP header correctly. So, if you already did the same thing. Could you please show me some source code about how to insert the UDP header? I will really appreciate your helping me! Best wishes! Peng Gao From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 06:02:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12987 for ; Fri, 26 Jul 2002 06:02:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17812; Fri, 26 Jul 2002 04:02:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04584; Fri, 26 Jul 2002 03:02:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QA1xoN028532 for ; Fri, 26 Jul 2002 03:01:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QA1xT9028531 for mobile-ip-dist; Fri, 26 Jul 2002 03:01:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QA1uoN028524 for ; Fri, 26 Jul 2002 03:01:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05954 for ; Fri, 26 Jul 2002 03:01:57 -0700 (PDT) Received: from chardonnay.levkowetz.com (h224n1fls32o89.telia.com [213.66.61.224]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06263 for ; Fri, 26 Jul 2002 04:01:53 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GZUP6W-00013W-00; Fri, 26 Jul 2002 12:01:44 +0200 From: "Henrik Levkowetz" To: "Peng Gao" , Subject: RE: [mobile-ip] Moible IP and UDP tunneling problem Date: Fri, 26 Jul 2002 12:01:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Importance: Normal In-Reply-To: <3D410BDE.4090403@lkn.e-technik.tu-muenchen.de> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peng Gao, This sounds as if you are trying to do basically the same thing which is described in the Mobile IP NAT traversal draft, but without having read that particular document. Would you have a look at http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-05.txt and see it that answers your questions? Regards, Henrik On Friday, 26 July 2002, Peng Gao wrote: > > I am a student at Technical University of Munich. I am doing my thesis > named Mobile IP and NAPT Interaction. I plan to set up a new UDP data > tunneling to go through the NAPT by Netfilter, but I meet a lot of > problems now. > > Firstly, could you please give me some advice about how to distinguish > Registration > Reply from UDP data tunneling at Foreign Agent? Since both are UDP > datagram, and have same IP Address and UDP Port. I know maybe I can > check the payload of the datagram, but I am not sure which part I should > check. > > Secondly, I plan to write a module for Home Agent, and the module stay > outside of the normal Home Agent process. That means before the HA > process send out the IP-in-IP data tunneling, my module works and > inserts the UDP header and make it to UDP data tunneling. Now, I can > not insert the UDP header correctly. So, if you already did the same > thing. Could you please show me some source code about how to insert > the UDP header? > > I will really appreciate your helping me! > > Best wishes! > > Peng Gao > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:12:03 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16088 for ; Fri, 26 Jul 2002 08:12:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18016; Fri, 26 Jul 2002 05:10:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24171; Fri, 26 Jul 2002 05:10:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QC9roN028873 for ; Fri, 26 Jul 2002 05:09:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QC9rQe028872 for mobile-ip-dist; Fri, 26 Jul 2002 05:09:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QC9noN028865 for ; Fri, 26 Jul 2002 05:09:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24053 for ; Fri, 26 Jul 2002 05:09:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27099 for ; Fri, 26 Jul 2002 06:09:47 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15598; Fri, 26 Jul 2002 08:08:40 -0400 (EDT) Message-Id: <200207261208.IAA15598@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-nat-traversal-05.txt Date: Fri, 26 Jul 2002 08:08:40 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP NAT/NAPT Traversal using UDP Tunnelling Author(s) : H. Levkowetz, S. Vaarala Filename : draft-ietf-mobileip-nat-traversal-05.txt Pages : 33 Date : 25-Jul-02 Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-nat-traversal-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020725150953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020725150953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:52:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17323 for ; Fri, 26 Jul 2002 08:52:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11825; Fri, 26 Jul 2002 06:52:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00831; Fri, 26 Jul 2002 05:52:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn0oN029650 for ; Fri, 26 Jul 2002 05:49:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCn0dj029649 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCmtoN029635 for ; Fri, 26 Jul 2002 05:48:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00335 for ; Fri, 26 Jul 2002 05:48:58 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11570 for ; Fri, 26 Jul 2002 06:48:57 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 4EF3B6A90B; Fri, 26 Jul 2002 15:48:55 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0A9276A906; Fri, 26 Jul 2002 15:48:51 +0300 (EEST) Message-ID: <3D4116C7.7030700@kolumbus.fi> Date: Fri, 26 Jul 2002 12:30:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (EAB)" Cc: Francis Dupont , "''mobile-ip@sunroof.eng.sun.com' '" Subject: Re: [mobile-ip] The link-local address issue References: <200207150752.g6F7qkGF061058@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Perhaps someone could tell me why the DAD vs. DIIDD question has relevance for this discussion? It seems to me that since the link local prefix is the same in all locations, DAD vs. DIIDD doesn't affect the behavior for link-local addresses. That is, if the mobile node waits for reconfiguration after a collision, it will do so for the address that is used both as a home and foreign link-local address. But maybe I'm missing something... If not, then I think the right thing to do would be to have the MIPv6 specification require "resetting" all ND information upon movement. That is, we'd forget the fact that we had collisions in a previous location. We'd also forget the fact that we did DAD for an address in the previous location, and would be forced to do a new DAD... I think this would make the protocols less vulnerable to local problems, whatever they might be. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:53:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17384 for ; Fri, 26 Jul 2002 08:53:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12639; Fri, 26 Jul 2002 06:53:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01170; Fri, 26 Jul 2002 05:53:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnkoN029752 for ; Fri, 26 Jul 2002 05:49:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnjEq029750 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn8oN029672 for ; Fri, 26 Jul 2002 05:49:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13279 for ; Fri, 26 Jul 2002 05:49:10 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10345 for ; Fri, 26 Jul 2002 06:49:09 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 928796A906; Fri, 26 Jul 2002 15:49:08 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4030F6A90E; Fri, 26 Jul 2002 15:48:58 +0300 (EEST) Message-ID: <3D4136E1.50709@kolumbus.fi> Date: Fri, 26 Jul 2002 14:47:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: James Kempf , Vijay Devarapalli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt References: <024c01c226d3$0488e2f0$4f6015ac@T23KEMPF> <3D2B7945.BBC13D09@iprg.nokia.com> <001301c22826$9b244930$4f6015ac@T23KEMPF> <3D2C6E2A.B1980D2C@iprg.nokia.com> <3D2F7058.2070406@kolumbus.fi> <3D2F7BD1.BCC68477@iprg.nokia.com> <00ed01c22a6d$66a47150$056015ac@T23KEMPF> <3D34EC10.6050006@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg Daley wrote: > Hi All, > > HMIPv6 uses Alt-coa extensively. > > IMHO, sending should be optional, but processing should be > mandated as part of MIPv6. > > The decision then becomes choice by the MN to advertise > a different CoA (which is what it really is for). I think we have reached a conclusion on when to send it. It appears that we can easily accommodate both MNs that know and MNs that don't know what kind of IPsec they are running on top of. Anyways, this translates to the Alt-CoA being optional in the packet, but mandatory to send in certain circumstances. And it will also be mandatory to be processed when received. We'll clarify this as well in the draft. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:53:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17416 for ; Fri, 26 Jul 2002 08:53:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12784; Fri, 26 Jul 2002 06:54:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11595; Fri, 26 Jul 2002 05:53:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnfoN029745 for ; Fri, 26 Jul 2002 05:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnf57029743 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn6oN029662 for ; Fri, 26 Jul 2002 05:49:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13272 for ; Fri, 26 Jul 2002 05:49:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10336 for ; Fri, 26 Jul 2002 06:49:08 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8298B6A912; Fri, 26 Jul 2002 15:49:01 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CA6736A908; Fri, 26 Jul 2002 15:48:52 +0300 (EEST) Message-ID: <3D4118B6.4040705@kolumbus.fi> Date: Fri, 26 Jul 2002 12:39:02 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Miles Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <013a01c22bef$86d920f0$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > Jari Arkko wrote: > >>Works for me too. Let's prohibit it. Also, we need to worry >>about the case where the prefixes change between S=0 reg & dereg. >>So, my proposal is to define an S=0 dereg as a deregistration of >>those addresses that were registered in the original S=0 reg. If no >>such original S=0 reg was done, the HA will return a new BA >>error code. Updated proposal: If the registration was a S=1 and the de-registration ues S=0, then this would be allowed and would mean de-registering the single address originally registered. This will avoid an extra error code. >>Finally, in a S=0 rereg we could implicitly dereg all address whose >>prefixes have disappeared between the reg & dereg. This appears >>unnecessary, though, as the HA would not allow the lifetime to exceed >>the prefix lifetimes. But this should be noted in the draft to make it >>clear. > > While you're there, you might also want to note the intended DAD behaviour upon > receipt of a S=0 rereg when new prefixes have appeared. Presumably, you DAD and > defend the new addresses when the rereg BU arrives, and not before. That is, you > do not do it immediately the applicable prefixes come into operation. Or do you? I think we should do only after the rereg arrives. Thanks, this also needs to be clarified. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:53:44 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17440 for ; Fri, 26 Jul 2002 08:53:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05020; Fri, 26 Jul 2002 05:52:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11247; Fri, 26 Jul 2002 05:52:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn3oN029660 for ; Fri, 26 Jul 2002 05:49:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCn2FJ029659 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCmvoN029642 for ; Fri, 26 Jul 2002 05:48:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10525 for ; Fri, 26 Jul 2002 05:49:00 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11576 for ; Fri, 26 Jul 2002 06:48:59 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 691846A905; Fri, 26 Jul 2002 15:48:53 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0BB256A904; Fri, 26 Jul 2002 15:48:48 +0300 (EEST) Message-ID: <3D40FF0E.8060900@kolumbus.fi> Date: Fri, 26 Jul 2002 10:49:34 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keiichi SHIMA Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments: draft-18 References: <20020715.003426.95886678.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi SHIMA / ??? wrote: > I have one more question about draft-18. > > There is no text which describes the relation between ND packets and > HAO. If a mobile node sends NS with HAO to a correpondent node's > global address, the response (NA) will be sent to the home agent of > the mobile node (if the CN doesn't have a BCE for the MN) or be sent > to the mobile node's HoA with RTHDR2 (if the CN has a BCE for the MN). > > In section 11.2.1, the spec says that the MN MAY ommit HAO for short > term communication. But I think it is not enough. HAO MUST NOT be > inserted to NS packets because NAs never reach to the MN. I agree. However, I have a worry that this is just one example of a more general problem. Are there any other cases where a similar rule must be applied? Perhaps we could cover all potential problems by stating the following: While not at its home link, the mobile node MUST NOT use its home address (or the home address destination option) in Neighbor Discovery communications on the visited link. The mobile node also MUST NOT use its home address when communicating with link-local or site-local peers on the visited link. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:54:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17459 for ; Fri, 26 Jul 2002 08:54:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14235; Fri, 26 Jul 2002 06:54:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11721; Fri, 26 Jul 2002 05:54:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnsoN029765 for ; Fri, 26 Jul 2002 05:49:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnrtO029762 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnBoN029699 for ; Fri, 26 Jul 2002 05:49:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13298 for ; Fri, 26 Jul 2002 05:49:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11662 for ; Fri, 26 Jul 2002 06:49:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 559A56A910; Fri, 26 Jul 2002 15:49:12 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 333BB6A90A; Fri, 26 Jul 2002 15:49:02 +0300 (EEST) Message-ID: <3D413F89.3060102@kolumbus.fi> Date: Fri, 26 Jul 2002 15:24:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Haley Cc: mobile ip Subject: Re: [mobile-ip] MH type field References: <3D406FA5.6680BE72@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > I was wondering why the MH type field (Section 6.1.1, draft 18) was 16 bits > and not 8 bits. I couldn't find any other IPv6 header that had a type larger > than 8 bits, and I don't think we'll ever have 65535 types. Should this be > changed to 8 bits for type and 8 bits reserved? This also saves a nthos() > for those of us on certain-endian machines, not that 3 assembly instructions > is buying me anything :) 8 bits looks sufficient now. OTOH I don't think the 8 bit reserved field buys very much either. And there are some protocols in the Internet where 8 bits looked initially sufficient but proved later to be insufficient. Mobility is an interesting subject to many folks. Will 256 values cover all the xMIP extensions that we might need in the future? Yeah, you could also say that it's a terrible thought that we'd need so much complexity that 10-15 values wouldn't do... By the way, if you switch statements in the code are in network byte order, you'll save the 3 instructions ;-) My gut feeling is that we should keep the current format, unless someone has strong arguments otherwise. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:54:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17523 for ; Fri, 26 Jul 2002 08:54:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14519; Fri, 26 Jul 2002 06:54:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11881; Fri, 26 Jul 2002 05:54:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnpoN029759 for ; Fri, 26 Jul 2002 05:49:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnoOc029757 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnBoN029698; Fri, 26 Jul 2002 05:49:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13303; Fri, 26 Jul 2002 05:49:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15470; Fri, 26 Jul 2002 05:49:13 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 379746A905; Fri, 26 Jul 2002 15:49:12 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8770A6A905; Fri, 26 Jul 2002 15:49:03 +0300 (EEST) Message-ID: <3D41409F.6040407@kolumbus.fi> Date: Fri, 26 Jul 2002 15:29:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Gaurav.Puri@lntinfotech.com Cc: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft 18 and "S" bit funda References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Gaurav.Puri@lntinfotech.com wrote: > hi, > MN will set the 'L' bit in the binding update when it knows that its > home address has been > formed using its own interface id which implies that its interface id is > unique in its home subnet. > So if 'L' bit is set, doing DAD for its link local address only is > enough.Why do DAD for > all possible MN's addresses? It's the DAD vs. DIIDD discussion. But my opinion is that DAD is right. And regardless of what IPv6 does, we should be conservative in MIPv6 and do DAD for all addresses just to avoid problems with implementations that might not be doing DIIDD. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:54:32 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17551 for ; Fri, 26 Jul 2002 08:54:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05279; Fri, 26 Jul 2002 05:53:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13979; Fri, 26 Jul 2002 05:53:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn7oN029664 for ; Fri, 26 Jul 2002 05:49:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCn68O029663 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn1oN029652 for ; Fri, 26 Jul 2002 05:49:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10524 for ; Fri, 26 Jul 2002 05:49:00 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11575 for ; Fri, 26 Jul 2002 06:48:59 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 476346A909; Fri, 26 Jul 2002 15:48:53 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D7C5A6A905; Fri, 26 Jul 2002 15:48:49 +0300 (EEST) Message-ID: <3D41116C.2050806@kolumbus.fi> Date: Fri, 26 Jul 2002 12:07:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Francis Dupont , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection References: <200207150133.g6F1XSGF060243@givry.rennes.enst-bretagne.fr> <3D325097.5000406@kolumbus.fi> <15679.9833.749904.318028@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > If we do the former, I'm not sure how we can make the SPD > > entries specific enough so that they would match only the MH > > messages, but leave rest of traffic in the clear. Can IPsec > > SPD entries see through the tunnel header? > > Do we actually care? What are the chances that somebody > would go through the motions of setting up a tunnel *only* > for MIP BU traffic? It seems pretty clear to me that > VPN+HA is going to be a very popular combination for > road warriors trying to get past the corporate > edge. Or am I misreading this? It's probably going to be popular, yes. But there also seems to be quite many folks who don't want to be forced into doing IPsec for all of their traffic just because they wanted to protect (a) BUs to HAs and (b) HOTIs/HOTs routed through the HA. So, we need to have a way to be selective about the traffic. HA is easy, because there is unlikely to be any other traffic between the HA and the MN besides the BUs. The HOTI/HOT case is tougher, because we need to be selective and not e.g. encrypt all the web browsing traffic that the MN is doing. So I think it is a requirement that the HOTs/HOTIs be protected separately from the rest of the payload traffic. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:55:06 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17613 for ; Fri, 26 Jul 2002 08:55:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05783; Fri, 26 Jul 2002 05:53:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14151; Fri, 26 Jul 2002 05:53:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnhoN029747 for ; Fri, 26 Jul 2002 05:49:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCngf7029744 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn7oN029671 for ; Fri, 26 Jul 2002 05:49:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13281 for ; Fri, 26 Jul 2002 05:49:10 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15446 for ; Fri, 26 Jul 2002 05:49:09 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 01B126A90D; Fri, 26 Jul 2002 15:49:08 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A42126A906; Fri, 26 Jul 2002 15:48:55 +0300 (EEST) Message-ID: <3D413141.2000400@kolumbus.fi> Date: Fri, 26 Jul 2002 14:23:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Haley Cc: mobile ip Subject: Re: [mobile-ip] draft 18 comments References: <3D334824.906BE97C@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > 4.5. Conceptual Data Structures > > "... The contents of all of a node's Binding Cache entries are > cleared when it reboots. ..." > > This isn't necessarily the case if we use nonvolatile storage as > Section 10.2 suggests. Yes. I propose to remove the text in 4.5. > 6.1.1. Format > > The Mobility Header is identified by a Next Header value of TBD in > the immediately preceding header, and has the following format: > > Can we assign an interim "Next Header" value so we'll be able to test > interoperability at ETSI, even if we don't put it in the draft right now? > IANA has 55 for "IP Mobility", but I didn't think Mipv4 used a protocol number? I'm fine with this, but I don't know the history behind 55. Anyone? If we can confirm this value can be used, we can take it immediately to the draft as well. > 6.1.8. Binding Acknowledgement (BA) Message > > The Binding Acknowledgement is sent to the source address of the > Binding Update message, regardless of whether the Binding Update > succeeded or failed. No Routing Headers are added to the message. > > Section 9.4.4 describes when and how to send a BAck to a MN, this > paragraph should probably be removed. Right. This has already been noted in issue #65. > 6.1.9. Binding Error (BE) Message > > What should the Home Address field be set to if the error status is 2, > the unspecified address? Maybe section 9.4.6 should clarify this, instead > of putting it in both 9.2.1 and 9.2.2. Yes. I propose to add the following paragraph to 9.4.6: The Home Address field in the Binding Error message MUST be copied from the Home Address field in the Home Address destination option of the offending packet, or set to the unspecified address if no such option appeared in the packet. Also, there seems to be overlap between sections 9.4.6 and 9.2.2. on detecting the HAO error and on using rate limitation. > Section 9.2.1 applies to all Mipv6 nodes, not just CNs, so it should > probably be moved elsewhere. It also doesn't say what to do if the > checksum is invalid, I'm assuming you drop the packet. There was > also a typo (Next Header -> Payload Proto) and some duplicated > text (Subsequent checks...). Here's a possible rewrite: Agree about the problems. We should probably have a section in the draft that deals with general rules that apply to all nodes. This could go in there. > 9.2.1. Processing Mobility Header (MH) Messages > > All IPv6 nodes MUST observe the following rules when processing > Mobility Header messages: > > 1. The "MH type" field MUST be a known type (Section 6.1), else the > node SHOULD issue a Binding Error message to the packet's Source > Address with Status field set to 2, subject to rate limiting in > the same manner as is done for ICMPv6 messages [14]. > > 2. The "Payload Proto" field MUST be NO_NXTHDR (59 decimal). > > 3. The checksum MUST be verified as per Section 6.1.1. > > Any Mobility Header packet which fails to satisfy all of these rules > MUST be silently discarded. > > Subsequent checks depend on the particular Mobility Header message, > as specified in Sections 9.3 and 9.4. > > (I also shortened this last paragraph since it seemed redundant) Looks good. We may treat BE rate limitation in 9.4.6. > And maybe the rate limiting piece I added should be in the Binding > Error section since there is more than one place that talks about > sending BEs. Ah, you noticed this too... > And what do we do if the length isn't even enough to cover the type > or checksum fields? We need an additional check: 0. The "Header Len" field MUST be non-zero. > 4. The "Header Len" field MUST meet the minimum length requirements > of a Mobility Header (which unfortunately doesn't end on an 8-octet > boundary), which is one (1)? I.E. if "Header Len" is zero what > do we do, ICMP message? > > > 9.3.1. Receiving Home Test Init Messages > > - The Header Extension Length field MUST be greater than or equal > to the length specified in Section 6.1.3. > > should be: > > - The MH "Header Len" field MUST be greater than or equal to the > length specified in Section 6.1.3. > > Section 9.3.2 needs a similar change. Right. > 9.4.1. Receiving Binding Updates > > - The Header Len field in the Binding Update option is greater than > or equal to the length specified in Section 6.1.7. > > There is no "Header Len" field in the BU any more, it's in the MH: > > - The MH "Header Len" field MUST be greater than or equal to the > length specified in Section 6.1.7. Yes. Thanks again for your feedback. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:55:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17666 for ; Fri, 26 Jul 2002 08:55:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06101; Fri, 26 Jul 2002 05:54:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11825; Fri, 26 Jul 2002 05:54:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCo3oN029782 for ; Fri, 26 Jul 2002 05:50:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCo37g029781 for mobile-ip-dist; Fri, 26 Jul 2002 05:50:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnCoN029703; Fri, 26 Jul 2002 05:49:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13299; Fri, 26 Jul 2002 05:49:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15460; Fri, 26 Jul 2002 06:49:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2260E6A90F; Fri, 26 Jul 2002 15:49:12 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C69266A911; Fri, 26 Jul 2002 15:49:00 +0300 (EEST) Message-ID: <3D413DCB.7000801@kolumbus.fi> Date: Fri, 26 Jul 2002 15:17:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Mohan Parthasarathy Cc: shima , mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: summary of HAO, BE processing discussion References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF221@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > > > In addition, the current draft requires not only HAO but > > also BE. This > > > means all IPv6 nodes must implement a new extention header > > (mobility > > > header). > > > > > > Correct. > > > If you read section 9.4.6, "Sending Binding Errors", yes it is > correct. But reading section 6.3 "Home Address option", it says > that if a node does not understand this option, it should return > ICMP parameter problem. Are these in conflict ? No, ICMP is used if you don't recognize the option. This is standard behaviour in IPv6. BE is used if you understand the option but don't like the contents. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:58:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17842 for ; Fri, 26 Jul 2002 08:58:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12547; Fri, 26 Jul 2002 06:53:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11530; Fri, 26 Jul 2002 05:53:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnkoN029751 for ; Fri, 26 Jul 2002 05:49:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnjG8029749 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCn7oN029666 for ; Fri, 26 Jul 2002 05:49:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00361 for ; Fri, 26 Jul 2002 05:49:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15436 for ; Fri, 26 Jul 2002 06:49:08 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 4234E6A913; Fri, 26 Jul 2002 15:49:02 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BCC7D6A904; Fri, 26 Jul 2002 15:48:53 +0300 (EEST) Message-ID: <3D412115.5000609@kolumbus.fi> Date: Fri, 26 Jul 2002 13:14:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont , Vijay Devarapalli , Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207180044.g6I0iAGF070487@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm looking at this issue and trying to understand what we should do. At the moment it looks like most folks who have expressed their opinion are OK with putting the R bit back to the base spec. However, I have some doubts about this still. But let me first describe the alternatives we have: 1. No R-bit in base spec. 2. R-Bit in an draft-kniveton-mobrtr-02.txt 3. No R-bit, ever. I think no one is arguing for #3 so we can only consider #1 and #2. But what is their difference? One concern is that if the base spec does not define this, then it becomes impossible to extend this functionality later. This is obviously not an issue, as there is reserved space in the BUs that can be used. Another possible concern is that when base-only HA implementations are deployed, it becomes impossible to deploy mobile routers as the existing HAs do not support them. However, it seems that we need more than the R bit for the mobile routers to work fully (see draft-kniveton for the prefix option). So, it appears that whatever we do, we can't have this functionality without also upgrading HAs. Finally, Francis raised the concern that the router-with-a-host-function is a separate issue from nemo-mobile-router, and that the R bit belongs to the first one. I agree that the issues are separate, but I'm not sure I understand why the R bit belongs to the former category. Presumably, we are talking a case where a mobile host is a router at the same time. That is, node M is a router on the foreign link with address F, and is a mobile host with the address H at the same time. When at home, M can even act both as a router and as a host using the same address H. Even without the R bit, will something break? Obviously, without extensions the MIPv6 protocol can't handle full router functionality. So, when M is away from home, the HA will advertise H with the NA R bit set to 0. So everyone on the home link will see that the router turned to a host. If M is acting as a router on the foreign link, its router and host addresses are going to be different, so I don't see a problem here either. Other concerns? I can't think of any... In conclusion, my suggestion is that we should define the R bit in draft-kniveton and keep the base spec from increasing in length once more... This is a small matter, however, and I have no special interest in this so I can live with the R bit as well. Let me know if I missed something above. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:58:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17875 for ; Fri, 26 Jul 2002 08:58:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12905; Fri, 26 Jul 2002 06:54:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01213; Fri, 26 Jul 2002 05:54:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnvoN029776 for ; Fri, 26 Jul 2002 05:49:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnuMv029772 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnDoN029707 for ; Fri, 26 Jul 2002 05:49:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13313 for ; Fri, 26 Jul 2002 05:49:15 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03633 for ; Fri, 26 Jul 2002 05:49:14 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id BEE236A907; Fri, 26 Jul 2002 15:49:07 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 821A56A90D; Fri, 26 Jul 2002 15:48:57 +0300 (EEST) Message-ID: <3D4135F2.8070108@kolumbus.fi> Date: Fri, 26 Jul 2002 14:43:46 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU AltSec BAR BOF Report References: <002201c22d15$387378d0$516015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: >>>We also discussed a couple simple optimizations of Return Routability, like >>>substituting for the Home Address Cookie, that would improve the performance >>>but still maintain the basic algorithm. >>> >>I think a word is missing above. Substituting what for the HA cookie? I can't remember exactly the specific comment. But I think this is related to the ability of e.g. CGA to skip home address tests at least for the majority of movements. It seems some form of care-of address tests will be necessary always, even if some optimizations might perhaps be possible even there. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 08:58:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17898 for ; Fri, 26 Jul 2002 08:58:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14196; Fri, 26 Jul 2002 06:54:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11711; Fri, 26 Jul 2002 05:54:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnnoN029756 for ; Fri, 26 Jul 2002 05:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnmOg029754 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnAoN029686 for ; Fri, 26 Jul 2002 05:49:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13291 for ; Fri, 26 Jul 2002 05:49:12 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11531 for ; Fri, 26 Jul 2002 06:49:10 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 065436A90E; Fri, 26 Jul 2002 15:49:09 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4701C6A90F; Fri, 26 Jul 2002 15:48:59 +0300 (EEST) Message-ID: <3D4136EB.8020008@kolumbus.fi> Date: Fri, 26 Jul 2002 14:47:55 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Miles , "'T.J. Kniveton'" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comment on Issue 56 (Optimizations in DHAD) References: <018001c22cc5$fa738790$0401010a@emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit TJ posted rules that prevent a collision of the optimizations. Kevin complained about the amount of effort we spend on this small feature and the already existing Reserved field. I'm more or less in agreement with both of you... My suggestion is that we remove 8 bytes from the Reserved field as we don't need to align at 16 byte boundaries in IPv6 (only 8). And then we apply TJ's rule. Are we done? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 09:03:19 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18088 for ; Fri, 26 Jul 2002 09:03:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17852; Fri, 26 Jul 2002 05:54:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14451; Fri, 26 Jul 2002 05:54:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnwoN029779 for ; Fri, 26 Jul 2002 05:49:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnwXA029777 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnGoN029724 for ; Fri, 26 Jul 2002 05:49:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00389 for ; Fri, 26 Jul 2002 05:49:18 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11664 for ; Fri, 26 Jul 2002 06:49:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 704FF6A90A; Fri, 26 Jul 2002 15:49:12 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C18436A904; Fri, 26 Jul 2002 15:49:02 +0300 (EEST) Message-ID: <3D413FEA.1070605@kolumbus.fi> Date: Fri, 26 Jul 2002 15:26:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com, Srinivasan.Damodaran@lntinfotech.com, kempf@docomolabs-usa.com, vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Re: closing issue 48, identifying link changes and prev-coa References: <200207260147.g6Q1lTuP990718@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > Hi Jari, > > I am catching up with emails after a long vacation, sorry for the > delay in replying. Has this issue been closed already ? I'm not really sure. There's been many people who want the prev-coa functionality moved elsewhere. In Yokohama we decided to move this discussion to the list... Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 09:49:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17524 for ; Fri, 26 Jul 2002 08:54:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13513; Fri, 26 Jul 2002 06:54:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01516; Fri, 26 Jul 2002 05:54:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCntoN029768 for ; Fri, 26 Jul 2002 05:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnsBW029764 for mobile-ip-dist; Fri, 26 Jul 2002 05:49:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnAoN029688 for ; Fri, 26 Jul 2002 05:49:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10588 for ; Fri, 26 Jul 2002 05:49:12 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11532 for ; Fri, 26 Jul 2002 06:49:10 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id DAC0E6A90C; Fri, 26 Jul 2002 15:49:09 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 323446A910; Fri, 26 Jul 2002 15:49:00 +0300 (EEST) Message-ID: <3D413CBE.6070405@kolumbus.fi> Date: Fri, 26 Jul 2002 15:12:46 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Brett Pentland Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Clarification sought on role of MIN_DELAY_BETWEEN_RAS References: <125608d1254b64.1254b64125608d@mail1.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brett Pentland wrote: > Hi folks, > > I was just wondering if anyone can confirm that the protocol > constant "MIN_DELAY_BETWEEN_RAS" defined in RFC2461 as 3 seconds only > relates to multicast RAs sent in response to an RS and thus is > unrelated to the configuration variable "MinRtrAdvInterval" for > unsolicited multicast RAs which is redefined in the Mobile IPv6 I-D. MIN_DELAY_BETWEEN_RAS concerns any RA sent to the all nodes multicast address, solicited or unsolicited. MinRtrAdvInterval concerns unsolicited RAs. These would also be sent to the all nodes multicast address. We redefine MinRtrAdvInterval in the MIPv6 I-D. It would seem that MIN_DELAY_BETWEEN_RAS must also be redefined for it to have any effect. Was that your concern? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 10:36:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22255 for ; Fri, 26 Jul 2002 10:36:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04195; Fri, 26 Jul 2002 08:36:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10368; Fri, 26 Jul 2002 07:36:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QEZvoN001830 for ; Fri, 26 Jul 2002 07:35:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QEZvJG001828 for mobile-ip-dist; Fri, 26 Jul 2002 07:35:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QEZroN001821 for ; Fri, 26 Jul 2002 07:35:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23575 for ; Fri, 26 Jul 2002 07:35:55 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24363 for ; Fri, 26 Jul 2002 08:35:54 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 339892918 for ; Fri, 26 Jul 2002 07:44:20 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 3D30AEF7 for ; Fri, 26 Jul 2002 07:35:54 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0001531513; Fri, 26 Jul 2002 10:35:52 -0400 (EDT) Message-ID: <3D415E47.97D5A2ED@hp.com> Date: Fri, 26 Jul 2002 10:35:52 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: [mobile-ip] MH Checksum calculation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Seems like Jari must be back from vacation with all the recent emails :) Anyways, I think the Checksum calculation paragraph in Section 6.1.1 needs some clarification. The pseudo IPv6 header used does not specify which source address is used if there is a Home Address Option in the packet. Some MH types do not require HAO (HoTI,CoTI, etc.), one might have one (BRR, if MN->MN), and others must have one (BU). I'm assuming that if there's a HAO, that it must be used as the IPv6 source address for the checksum calculation? If so, in addition to 6.1.1 changes, it might be good to add some text (in 11.2.1?) that says what a MN should do if sending a MH message with a HAO. Section 11.2.1 does do a good job of saying how a MN should send a "direct delivery" packet, swapping addresses and such, but doesn't mention checksum. -Brian From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 11:10:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24250 for ; Fri, 26 Jul 2002 11:10:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21925; Fri, 26 Jul 2002 09:10:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02773; Fri, 26 Jul 2002 08:10:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QF9qoN002054 for ; Fri, 26 Jul 2002 08:09:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QF9qcq002053 for mobile-ip-dist; Fri, 26 Jul 2002 08:09:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QF9noN002046 for ; Fri, 26 Jul 2002 08:09:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20921 for ; Fri, 26 Jul 2002 08:09:50 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09718 for ; Fri, 26 Jul 2002 09:09:48 -0600 (MDT) Received: from kmilesw2k (ams-clip-vpn-dhcp4253.cisco.com [10.50.16.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA24452; Fri, 26 Jul 2002 16:09:39 +0100 (BST) From: "Kevin Miles" To: "'Jari Arkko'" Cc: Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Fri, 26 Jul 2002 16:09:37 +0100 Message-ID: <005301c234b6$75ca4e40$596cfe90@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D4118B6.4040705@kolumbus.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Kevin Miles wrote: > > > Jari Arkko wrote: > > > >>Works for me too. Let's prohibit it. Also, we need to worry > >>about the case where the prefixes change between S=0 reg & dereg. > >>So, my proposal is to define an S=0 dereg as a deregistration of > >>those addresses that were registered in the original S=0 reg. If no > >>such original S=0 reg was done, the HA will return a new BA > >>error code. > > > Updated proposal: If the registration was a S=1 and the > de-registration > ues S=0, then this would be allowed and would mean de-registering the > single address originally registered. This will avoid an extra > error code. > Okay. What about the rereg case? Can you 'upgrade' from S=1 to S=0 in successive registration BUs? It doesn't sound, to me, like a useful thing to be able to do. But if it's illegal, either we need a suitable error code, or we need to say that the S bit is ignored in a BU for which there is an existing BCE and treated as if it had the value of the originating BU. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 11:11:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24399 for ; Fri, 26 Jul 2002 11:11:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25037; Fri, 26 Jul 2002 09:12:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03185; Fri, 26 Jul 2002 08:12:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QFBdoN002107 for ; Fri, 26 Jul 2002 08:11:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QFBdla002106 for mobile-ip-dist; Fri, 26 Jul 2002 08:11:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QFBZoN002093 for ; Fri, 26 Jul 2002 08:11:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21497 for ; Fri, 26 Jul 2002 08:11:37 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11025 for ; Fri, 26 Jul 2002 08:11:36 -0700 (PDT) Received: from kmilesw2k (ams-clip-vpn-dhcp4253.cisco.com [10.50.16.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA24531; Fri, 26 Jul 2002 16:11:27 +0100 (BST) From: "Kevin Miles" To: "'Jari Arkko'" , "'T.J. Kniveton'" Cc: Subject: RE: [mobile-ip] Comment on Issue 56 (Optimizations in DHAD) Date: Fri, 26 Jul 2002 16:11:24 +0100 Message-ID: <005401c234b6$b6002430$596cfe90@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D4136EB.8020008@kolumbus.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > TJ posted rules that prevent a collision of the optimizations. Kevin > complained about the amount of effort we spend on this small feature > and the already existing Reserved field. I'm more or less in agreement > with both of you... > > My suggestion is that we remove 8 bytes from the Reserved field as we > don't need to align at 16 byte boundaries in IPv6 (only 8). And then > we apply TJ's rule. Are we done? > Sure. Kevin. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 13:12:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00550 for ; Fri, 26 Jul 2002 13:12:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08090; Fri, 26 Jul 2002 11:12:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09975; Fri, 26 Jul 2002 10:12:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHBRoN002563 for ; Fri, 26 Jul 2002 10:11:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QHBQeo002562 for mobile-ip-dist; Fri, 26 Jul 2002 10:11:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHBNoN002555 for ; Fri, 26 Jul 2002 10:11:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23763 for ; Fri, 26 Jul 2002 10:11:26 -0700 (PDT) Received: from lark.cc.ku.edu (lark.cc.ku.edu [129.237.34.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07289 for ; Fri, 26 Jul 2002 11:11:25 -0600 (MDT) Received: from webmail.ku.edu by lark.cc.ku.edu (8.8.8/1.1.8.2/12Jan95-0207PM) id MAA0000023364; Fri, 26 Jul 2002 12:07:38 -0500 (CDT) X-WebMail-UserID: pradeep@mail.ukans.edu Date: Fri, 26 Jul 2002 12:07:38 -0500 From: pradeep To: mobile-ip , Peng Gao X-EXP32-SerialNo: 00002424 Subject: RE: [mobile-ip] Moible IP and UDP tunneling problem Message-ID: <3D4500E4@webmail.ku.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.62 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've implemented (to some extent) the NAT traversal draft. In my implementation I've developed a IP-UDP tunnel device driver. Since the implementation is still in its development stage, there may be some bugs to be fixed! But anyway you can have a look at http://people.eecs.ku.edu/~pnataraj/eecs801 The source code is also available in the same page. Good luck. -Pradeep Natarajan. >===== Original Message From Peng Gao ===== >I am a student at Technical University of Munich. I am doing my thesis >named Mobile IP and NAPT Interaction. I plan to set up a new UDP data >tunneling to go through the NAPT by Netfilter, but I meet a lot of >problems now. > >Firstly, could you please give me some advice about how to distinguish >Registration >Reply from UDP data tunneling at Foreign Agent? Since both are UDP >datagram, and have same IP Address and UDP Port. I know maybe I can >check the payload of the datagram, but I am not sure which part I should >check. > >Secondly, I plan to write a module for Home Agent, and the module stay >outside of the normal Home Agent process. That means before the HA >process send out the IP-in-IP data tunneling, my module works and >inserts the UDP header and make it to UDP data tunneling. Now, I can >not insert the UDP header correctly. So, if you already did the same >thing. Could you please show me some source code about how to insert >the UDP header? > >I will really appreciate your helping me! > >Best wishes! > >Peng Gao From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 13:49:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01972 for ; Fri, 26 Jul 2002 13:49:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29012; Fri, 26 Jul 2002 11:50:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23187; Fri, 26 Jul 2002 10:50:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHnNoN002829 for ; Fri, 26 Jul 2002 10:49:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QHnN6o002828 for mobile-ip-dist; Fri, 26 Jul 2002 10:49:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHnKoN002821 for ; Fri, 26 Jul 2002 10:49:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06569 for ; Fri, 26 Jul 2002 10:49:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24042 for ; Fri, 26 Jul 2002 10:49:22 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04478; Fri, 26 Jul 2002 10:49:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6QHnKe03299; Fri, 26 Jul 2002 10:49:20 -0700 X-mProtect: <200207261749> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9ug5aL; Fri, 26 Jul 2002 10:49:18 PDT Message-ID: <3D418B9F.58FCC8AA@iprg.nokia.com> Date: Fri, 26 Jul 2002 10:49:19 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Joseph Soma Reddy CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Joseph, thanks for your input. I have some general comments first. An IP-based protocol has to work on all link types, while allowing individual links to customize the protocol for improving performance. If the protocol is based on the chatacteristics of a single link type, then the chances are the protocol won't work at all or won't work the way it should on all the link types. Did you see my earlier posting in which I had asked few questions ? Those questions directly relate to your comment regarding over-the-air signaling. Specifically, - how do you inform the new AR's L2 and IP address to the MN ? - should we assume that L2 specific information is sufficient to redirect traffic without explicit authorization (in the form of FBU) from the MN ? These are broader questions, and are not specific to a particular link technology. I would be interested in hearing how your proposal would address these two key questions. I would also appreciate if you could take a look at my previous posting and respond to the questions there. Now, some comments below.. Joseph Soma Reddy wrote: > Hello all, > I would like to point out that mobility protocol should not > only ensure routing to mobile hosts, it should be able to > support macrodiversity(i.e. soft handoff) which is very > important in cdma systems. Macrodiversity is already being > incorporated in systems like HDR(High Data Rate system from > Qualcomm) where the mobile can move between different > cell sectors before receiving each packet. With a good > mobility scheme, it is possible to extend this and enable > the mobile to handoff quickly between BS, which can result > in coverage and capacity increase. > Role of IP in dealing with macrodiversity is an interesting topic and I am sure will spur lot of discussion. However, increasing capacity, or more generally, the topic of macrodiversity itself is not an objective of fast handover. If there is sufficient interest, I think this should be explored separately in the WG. > > I have addressed this issue in a recent draft > ("macrodiversity in IP based cellular networks" > available at http://cwc.ucsd.edu/~soma ). > The main conclusions were that the mobile should be able to > handoff as soon as channel conditions changes(i.e. post-reg > handoff) and that it should be possible to handoff without > requiring any over-the-air signalling. > I am concerned that the v5 draft provides for these > mechanisms only as error conditions. > Well, if the AR does not change during such a handover, there is not anything for the protocol to do. One could argue that this is a matter of how you roll out the network. The v05 version allows tunnel establishment subsequent to the MN attaching to the new link. I don't know if you have followed the previous versions of the draft or not, but the reason for this is that the protocol begins on the old link and the FBU is anticipated to be sent from the old link. In any case, I have received comments that it would be better to explain this under a separate section, and I will do that. > > Another concern I have with respect to anticipated handoffs > is that it seems to place requirements on the physical/link > layers with respect to how channel conditions change(i.e. it > assumes that they change gradually enough to be anticipated). > Actually, there is no such assumption. If the MN does not receive PrRtAdv, it triggers tunnel establishment after attaching to the new link. If PrRtAdv can be delivered to the MN on the previous link, then, also providing the new router's prefix information facilitates faster new IP address configuration (aka anticipation). So, consider the following network-controlled handover scenario. - the previous AR sends PrRtAdv to the MN providing - new AR's L2 address, IP address and network prefix info. Note: PrRtAdv is needed independent of "anticipation" in order to provide the new AR's L2 address and IP address. - the MN moves and starts sending packets using previous CoA immediately. It also sends FNA to confirm if it can use a new CoA. [This FNA can be an option in a Router Solicitation which a MN needs anyway in order to obtain a Router Advertisement.] - depending on when the FBU is received, the previous AR starts forwarding the packets to the MN. If the FBU is received on the old link itself, the packets will be delivered as soon as the new AR detects that MN is attached to it. If the FBU is received from the new link, they will start arriving from the previous AR. So, in order for the protocol to work on all link types without making specific assumptions about what _a_ link type "might be able to provide", and more importantly, to keep following the principle of specifying IP protocols for IETF standardization, we need to specify PrRtAdv and FBU. At the same time, the draft should be able to allow L2-specific customizations. > This is not necessarily true even in current systems. For > example, the so called "street corner effect" occurs in dense > urban areas where the base stations are mounted on poletops. > The coverage of these BS extends linearly(along a block) rather > than omnidirectionally. A mobile user who turns a street corner > in such an environment will lose line-of-sight with current BS > and enter line-of-sight of another BS. This causes a sudden handoff > which can only be handled by post-reg type of mobility. > These type of situations are common in micro-cellular > networks which will become more common in future > as increased demand for capacity is met by reducing cell > size. I agree that the protocol should support the case when the MN simply attaches to a link without any forewarning. This is why the draft allows sending FBU from the new link even when the MN has not received a PrRtAdv, and the previous router should engage in HI/HACK when it receives a FBU and it has not seen a PrRtSol or not sent a PrRtAdv. You might also observe that base Mobile IP draft recognized this long ago (by allowing forwarding from previous CoA). Thanks for your interest. -Rajeev ps. terms like "post-reg handover" "pre-reg handover" are not used the fmipv6 draft. I think I know what you mean by them, but I would rather stick to terms which have been used since v00. The draft makes a distinction between protocol operations "prior to" or "subsequent to" new link establishment. > > > Comments are appreciated. > > Regards, > Joseph From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 13:57:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02313 for ; Fri, 26 Jul 2002 13:57:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28363; Fri, 26 Jul 2002 11:58:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09180; Fri, 26 Jul 2002 10:57:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHv5oN002990 for ; Fri, 26 Jul 2002 10:57:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QHv5bG002989 for mobile-ip-dist; Fri, 26 Jul 2002 10:57:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QHv2oN002982 for ; Fri, 26 Jul 2002 10:57:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26893 for ; Fri, 26 Jul 2002 10:57:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26668 for ; Fri, 26 Jul 2002 11:57:01 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04929; Fri, 26 Jul 2002 10:57:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6QHuvi14642; Fri, 26 Jul 2002 10:56:57 -0700 X-mProtect: <200207261756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6skl2a; Fri, 26 Jul 2002 10:56:45 PDT Message-ID: <3D418D5E.CAA839D7@iprg.nokia.com> Date: Fri, 26 Jul 2002 10:56:46 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> <02b201c2344d$de137b20$a66015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Alper, "Alper E. YEGIN" wrote: > Hi Rajeev, > > Let me make an attempt to answer your questions. > > > 1. How does the MN get the L2 address and IP address of the > > new AR ? I see the following possibilities > > a) PrRtAdv provides this > > b) upon establishing a new link, the MN does RS and gets an RA > > > > How can you avoid PrRtAdv ? > > Please see CARID in draft-gwon-mobileip-efwd-fmipv6-00.txt. > While MN is still connected to the oAR, it can request > a table that maps L2 id of access points to L2/L3 ids of > access routers. Than, after the movement MN learns > the L2 id of the AP, and performs a table lookup for AR > information. > > The difference between PrRtAdv and CARID is that the > latter can happen any time before handover, not necessarily > right before handover or upon anticipation. > I agree that your proposal, after looking at the description above, allows a MN to send packets on the new link when it has not received PrRtAdv. I think others are also possible. For instance, the MN can send a RS as soon as it detects a new link and force the router to send an RA. There are pros and cons associated with these mechanisms, of course. However, the question I have is, can we NOT specify PrRtAdv ? Seems to me that we need it for the base spec, and when additional methods are available, the protocol can work well even when the MN does not receive it. I am not sure if we can specify each of those additional methods in the base spec..Do you agree ? -Rajeev > > > Can we assume that L2 trigger > > provides the necessary information ? > > Nope. > > > Which L2 trigger today > > provides such information? > > I'm not aware of any... > > > Isn't this at best a recommendation > > to future L2 designers ? > > I personally wouldn't recommend > providing this L3 information via L2 signaling. > > > In any case, can we specify that > > the protocol operates based on this assumption on _all_ links ? > > > > 2. When does the previous AR actually start forwarding packets > > on the tunnel ? Should it do so even when it has not received a > > FBU ? I think use of L2 triggers to more precisely time > > forwarding is useful when the router has received FBU. > > I agree. > > > Doing > > forwarding in the absence of FBU is redirecting traffic without > > proper authorization, and as we have seen inMIPv6 security > > exercise, involves security considerations. Can we say here that > > L2 trigger will have the necessary authorization to redirect > > traffic ? Even so, how can a base spec generalize it to all possible > > link layers ? > > IMO, we should stay in the boundaries of Mobile IP model > and only allow explicite BUs change routing state... > IP can receive help from L2 though, in the form of L2 > suggesting a BU be sent, or L2 suggesting precise time > of routing change once AR/MN decided to do so. > > alper > > > > > These are the crucial questions that determine the trade-off. I > > would like to know what you and others think. > > > > Regards, > > > > -Rajeev > > > > > > > > > > "Alper E. YEGIN" wrote: > > > > > Hello Ajoy, > > > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > > good idea. Protocols are sufficiently different to make considerable > > > > performance differences. > > > > > > > > Ajoy-> I think claiming something works without proper data and > > > > argument is also not a good idea. BTW, do you agree that due to higher > > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > > time ? > > > > > > Yes of course. > > > > > > > As you increase anticipation time, the likelihood > > > > of handover failure will increase. > > > > > > This statement by itself also make sense... > > > > > > But, the question is how much difference does it make? > > > Experimentation can help answer this question, and this is > > > why I was asking if your statements were based on > > > FMIPv6 experiments... > > > > > > Also, how much heads up can the mobile terminal or the network > > > get before the link is broken without any anticipation? > > > I presume link down doesn't happen instantly, at least L2 has to > > > exchange some messages. Is there a window > > > in which L3 can exchange packets? > > > > > > > I do not think this has > > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > > similar behavior in either case. > > > > > > But there is more... A fundamental difference between > > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > > registration request has to go all the way to home agent. > > > This not only effects the latency, but also prevents taking > > > advantage of L2 triggers on the oFA/oAR to precisely > > > determine when the routing should change.. And this > > > should make a difference in the observed performance.. > > > > > > alper > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 14:02:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02500 for ; Fri, 26 Jul 2002 14:02:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00504; Fri, 26 Jul 2002 12:01:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28380; Fri, 26 Jul 2002 11:01:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QI0WoN003130 for ; Fri, 26 Jul 2002 11:00:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QI0Wp5003129 for mobile-ip-dist; Fri, 26 Jul 2002 11:00:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QI0ToN003120 for ; Fri, 26 Jul 2002 11:00:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10399 for ; Fri, 26 Jul 2002 11:00:31 -0700 (PDT) Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00113 for ; Fri, 26 Jul 2002 11:00:30 -0700 (PDT) Received: from [134.102.101.207] (helo=IPonAir) by smtp.web.de with smtp (WEB.DE(Exim) 4.75 #2) id 17Y9O9-0008VL-00 for mobile-ip@sunroof.eng.sun.com; Fri, 26 Jul 2002 20:00:29 +0200 Message-ID: <002801c234ce$74aa9980$cf656686@IPonAir> From: "Michael Sessinghaus" To: "mobile ip" Subject: [mobile-ip] internet connectivity for aodv with mobile ip Date: Fri, 26 Jul 2002 20:01:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C234DF.37F4D9E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C234DF.37F4D9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, did anybody simulated internet connectivity for aodv with mobile ip? The = paper of E.M.Royer=20 "Internet connectivity for Ad Hoc mobile networks" describes such a = scenario. Does someone know about investigations and references = regarding to simulation with ns-2 and tcl scripts. I want your help because i want to investigate aodv and mobile ip for = internet connectivity. The scenario should describe the movement and handover from/in a MANET = with permanent internet connection. Thanks and best regards, Michael. ------=_NextPart_000_0025_01C234DF.37F4D9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
did anybody simulated internet = connectivity=20 for aodv with mobile ip? The paper of E.M.Royer
"Internet connectivity for Ad Hoc = mobile networks"=20 describes such a scenario. Does = someone know=20 about investigations and references regarding to simulation with = ns-2 and=20 tcl scripts.
 
I want your help because i want to = investigate=20 aodv and mobile ip for internet connectivity.
The scenario should describe the = movement and=20 handover from/in a MANET with permanent internet = connection.
Thanks and best regards, = Michael.
 
------=_NextPart_000_0025_01C234DF.37F4D9E0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 14:06:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02642 for ; Fri, 26 Jul 2002 14:06:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19374; Fri, 26 Jul 2002 11:05:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29821; Fri, 26 Jul 2002 11:05:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QI4koN003267 for ; Fri, 26 Jul 2002 11:04:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QI4knm003266 for mobile-ip-dist; Fri, 26 Jul 2002 11:04:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QI4goN003256 for ; Fri, 26 Jul 2002 11:04:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11886 for ; Fri, 26 Jul 2002 11:04:44 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18824 for ; Fri, 26 Jul 2002 11:04:44 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA26564 for ; Fri, 26 Jul 2002 11:03:33 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA25779 for ; Fri, 26 Jul 2002 11:05:00 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 26 Jul 2002 13:04:43 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 26 Jul 2002 13:04:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Alper, Please find my inline reply. Regards, ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Thursday, July 25, 2002 7:30 PM To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Hello Ajoy, > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > then applying to "anticipated FMIPv6" without experimenting is not a > good idea. Protocols are sufficiently different to make considerable > performance differences. > > Ajoy-> I think claiming something works without proper data and > argument is also not a good idea. BTW, do you agree that due to higher > RTT of cellular link, FMIPv6 will require higher anticipation > time ? Yes of course. > As you increase anticipation time, the likelihood > of handover failure will increase. This statement by itself also make sense... Ajoy-> Good But, the question is how much difference does it make? Experimentation can help answer this question, and this is why I was asking if your statements were based on FMIPv6 experiments... Also, how much heads up can the mobile terminal or the network get before the link is broken without any anticipation? I presume link down doesn't happen instantly, at least L2 has to exchange some messages. Is there a window in which L3 can exchange packets? > I do not think this has > anything to do with FMIPv6 or FMIPv4. You will observe > similar behavior in either case. But there is more... A fundamental difference between FMIPv6 and pre-reg FMIPv4 is that with the latter the registration request has to go all the way to home agent. This not only effects the latency, but also prevents taking advantage of L2 triggers on the oFA/oAR to precisely determine when the routing should change.. And this should make a difference in the observed performance.. Ajoy-> BTW, in our implementation there were a few hops between FA and HA. So, probably this distinction of FMIPv4 is not relavent in this discussion. I do agree the FMIPv4 problem will be even worse when FA and HA are located at the two end of the Internet. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 14:45:23 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03909 for ; Fri, 26 Jul 2002 14:45:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09101; Fri, 26 Jul 2002 11:43:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15597; Fri, 26 Jul 2002 11:43:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIguoN003530 for ; Fri, 26 Jul 2002 11:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QIguIB003529 for mobile-ip-dist; Fri, 26 Jul 2002 11:42:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIgroN003522 for ; Fri, 26 Jul 2002 11:42:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15315 for ; Fri, 26 Jul 2002 11:42:55 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19164 for ; Fri, 26 Jul 2002 12:42:54 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2E37D6A906; Fri, 26 Jul 2002 21:42:54 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 011606A905; Fri, 26 Jul 2002 21:42:52 +0300 (EEST) Message-ID: <3D41989A.9050705@kolumbus.fi> Date: Fri, 26 Jul 2002 21:44:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Miles Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <005301c234b6$75ca4e40$596cfe90@emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > Okay. What about the rereg case? Can you 'upgrade' from S=1 to S=0 in successive > registration BUs? It doesn't sound, to me, like a useful thing to be able to do. > But if it's illegal, either we need a suitable error code, or we need to say > that the S bit is ignored in a BU for which there is an existing BCE and treated > as if it had the value of the originating BU. Good point. Why don't we simply allow this behaviour? The rereg will set up entries for every current prefix, and will override the entry for the original single address. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 14:49:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04059 for ; Fri, 26 Jul 2002 14:49:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26030; Fri, 26 Jul 2002 11:48:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17505; Fri, 26 Jul 2002 11:48:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIlBoN003648 for ; Fri, 26 Jul 2002 11:47:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QIlBaf003647 for mobile-ip-dist; Fri, 26 Jul 2002 11:47:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIl7oN003640 for ; Fri, 26 Jul 2002 11:47:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28766 for ; Fri, 26 Jul 2002 11:47:10 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10910 for ; Fri, 26 Jul 2002 11:47:09 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA03676 for ; Fri, 26 Jul 2002 11:47:09 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA13730 for ; Fri, 26 Jul 2002 11:47:09 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 26 Jul 2002 13:47:09 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , "Alper E. YEGIN" Cc: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 26 Jul 2002 13:47:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev, Please find my inline reply. regards, ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, July 25, 2002 8:38 PM To: Alper E. YEGIN Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; 'James Kempf'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, Alper, I have few questions for you. 1. How does the MN get the L2 address and IP address of the new AR ? I see the following possibilities a) PrRtAdv provides this b) upon establishing a new link, the MN does RS and gets an RA AJOY-> In case of network controlled handoff, why MN is required to get the IP address of the new AR ? Could you clarify this? How can you avoid PrRtAdv ? Can we assume that L2 trigger provides the necessary information ? Which L2 trigger today provides such information? AJOY-> As I said, in case of network controlled handoff, both ARs can communicate to create visitor list entry for the Mobile node at the nAR. Why we need PrRtAdv in critical path in this case? As far as I know, BETH can be implemented in any wireless technology capable of supporting network controlled handover. Even this can be extended for Mobile controlled handover. Please let me know in case you know of something where this can not be implemented. Isn't this at best a recommendation to future L2 designers ? Ajoy-> To make something useful, we need to consider the need of present network. I will be skeptical to standardize something in the hope of being used in remote (?) future. In any case, can we specify that the protocol operates based on this assumption on _all_ links ? 2. When does the previous AR actually start forwarding packets on the tunnel ? Should it do so even when it has not received a FBU ? AJOY-> In BETH, as far as I remember, oAR will start forwarding packets after receiving link down event. I think use of L2 triggers to more precisely time forwarding is useful when the router has received FBU. Doing forwarding in the absence of FBU is redirecting traffic without proper authorization, and as we have seen inMIPv6 security exercise, involves security considerations. Can we say here that L2 trigger will have the necessary authorization to redirect traffic ? Even so, how can a base spec generalize it to all possible link layers ? AJOY-> Base protocol will just have to state that link layer must be secure. Since, we are not defining link layer triggers in base draft, we do not need to be concerned about how L2 trigger will be secured. These are the crucial questions that determine the trade-off. I would like to know what you and others think. AJOY-> We are talking about fast handoff. So, we need a solution that can provide reliable fast handoff. Regards, -Rajeev "Alper E. YEGIN" wrote: > Hello Ajoy, > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > then applying to "anticipated FMIPv6" without experimenting is not a > > good idea. Protocols are sufficiently different to make considerable > > performance differences. > > > > Ajoy-> I think claiming something works without proper data and > > argument is also not a good idea. BTW, do you agree that due to higher > > RTT of cellular link, FMIPv6 will require higher anticipation > > time ? > > Yes of course. > > > As you increase anticipation time, the likelihood > > of handover failure will increase. > > This statement by itself also make sense... > > But, the question is how much difference does it make? > Experimentation can help answer this question, and this is > why I was asking if your statements were based on > FMIPv6 experiments... > > Also, how much heads up can the mobile terminal or the network > get before the link is broken without any anticipation? > I presume link down doesn't happen instantly, at least L2 has to > exchange some messages. Is there a window > in which L3 can exchange packets? > > > I do not think this has > > anything to do with FMIPv6 or FMIPv4. You will observe > > similar behavior in either case. > > But there is more... A fundamental difference between > FMIPv6 and pre-reg FMIPv4 is that with the latter the > registration request has to go all the way to home agent. > This not only effects the latency, but also prevents taking > advantage of L2 triggers on the oFA/oAR to precisely > determine when the routing should change.. And this > should make a difference in the observed performance.. > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 17:37:05 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09997 for ; Fri, 26 Jul 2002 17:37:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04526; Fri, 26 Jul 2002 14:35:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07444; Fri, 26 Jul 2002 14:35:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QLYnoN004139 for ; Fri, 26 Jul 2002 14:34:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QLYn3W004138 for mobile-ip-dist; Fri, 26 Jul 2002 14:34:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QLYjoN004131 for ; Fri, 26 Jul 2002 14:34:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18175 for ; Fri, 26 Jul 2002 14:34:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04103 for ; Fri, 26 Jul 2002 14:34:47 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19232; Fri, 26 Jul 2002 14:34:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6QLYjo09098; Fri, 26 Jul 2002 14:34:45 -0700 X-mProtect: <200207262134> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxBOarh; Fri, 26 Jul 2002 14:34:43 PDT Message-ID: <3D41C073.52649877@iprg.nokia.com> Date: Fri, 26 Jul 2002 14:34:43 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "Alper E. YEGIN" , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > > Ajoy, Alper, > > I have few questions for you. > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > AJOY-> In case of network controlled handoff, why MN is required > to get the IP address of the new AR ? Could you clarify > this? > The MN needs an IP address of the gateway for a default destination. If you have a unix system, "netstat -rn" should produce the route table entries that includes the Gateway address for default destination. The L2 address is needed for encapsulating the IP packet in a L2 frame. > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > AJOY-> As I said, in case of network controlled handoff, both ARs > can communicate to create visitor list entry for the Mobile > node at the nAR. Why we need PrRtAdv in critical path in this > Visitor list entry ? Do you mean host route entry ? > case? As far as I know, BETH can be implemented in any wireless > technology capable of supporting network controlled handover. > Even this can be extended for Mobile controlled handover. > Please let me know in case you know of something where this can > not be implemented. > The routers communicate to establish a host route entry for the MN on the new AR. But, that does not help the MN in _sending_ packets unless it has the new AR's addresses. The purpose of PrRtAdv is to provide this information. As I asked in my questions, who provides this information ? Are we assuming that L2 trigger will be able to provide this ? If yes, then I am asking can we specify that in the base draft which ought to work on all link types ? I also don't know which L2 type provides such information today.. > > Isn't this at best a recommendation > to future L2 designers ? > > Ajoy-> To make something useful, we need to consider the > need of present network. I will be skeptical to > standardize something in the hope of being used in > remote (?) future. > Good. I didn't say we should standardize this. I am saying to expect something from link layers should be part of a wish list. > > In any case, can we specify that > the protocol operates based on this assumption on _all_ links ? > > 2. When does the previous AR actually start forwarding packets > on the tunnel ? Should it do so even when it has not received a > FBU ? > > AJOY-> In BETH, as far as I remember, oAR will start forwarding packets > after receiving link down event. But, my question is should we allow that even in the absence of receiving an FBU ? See the questions below (in my previous e-mail).. > > > I think use of L2 triggers to more precisely time > forwarding is useful when the router has received FBU. Doing > forwarding in the absence of FBU is redirecting traffic without > proper authorization, and as we have seen inMIPv6 security > exercise, involves security considerations. Can we say here that > L2 trigger will have the necessary authorization to redirect > traffic ? Even so, how can a base spec generalize it to all possible > link layers ? > > AJOY-> Base protocol will just have to state that link layer must be > secure. Since, we are not defining link layer triggers in > base draft, we do not need to be concerned about how > L2 trigger will be secured. > Well, how can we enforce that a particular L2 be secure in the base draft ? In an IP protocol, we can certainly state that FBU must be protected before traffic can be redirected. > > These are the crucial questions that determine the trade-off. I > would like to know what you and others think. > > AJOY-> We are talking about fast handoff. So, we need a solution > that can provide reliable fast handoff. > I agree we are talking about fast handover :-) In what way is the protocol not robust ? It should work in the presence of lost messages and should provide the desired performance. I would be happy to address those considerations. Also, could you comment specifically on how we can avoid PrRtAdv and FBU ? That would be more useful. Thanks, -Rajeev > > Regards, > > -Rajeev > > "Alper E. YEGIN" wrote: > > > Hello Ajoy, > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > good idea. Protocols are sufficiently different to make considerable > > > performance differences. > > > > > > Ajoy-> I think claiming something works without proper data and > > > argument is also not a good idea. BTW, do you agree that due to higher > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > time ? > > > > Yes of course. > > > > > As you increase anticipation time, the likelihood > > > of handover failure will increase. > > > > This statement by itself also make sense... > > > > But, the question is how much difference does it make? > > Experimentation can help answer this question, and this is > > why I was asking if your statements were based on > > FMIPv6 experiments... > > > > Also, how much heads up can the mobile terminal or the network > > get before the link is broken without any anticipation? > > I presume link down doesn't happen instantly, at least L2 has to > > exchange some messages. Is there a window > > in which L3 can exchange packets? > > > > > I do not think this has > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > similar behavior in either case. > > > > But there is more... A fundamental difference between > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > registration request has to go all the way to home agent. > > This not only effects the latency, but also prevents taking > > advantage of L2 triggers on the oFA/oAR to precisely > > determine when the routing should change.. And this > > should make a difference in the observed performance.. > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 18:05:59 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10666 for ; Fri, 26 Jul 2002 18:05:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22350; Fri, 26 Jul 2002 16:05:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27931; Fri, 26 Jul 2002 15:05:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QM4PoN004464 for ; Fri, 26 Jul 2002 15:04:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QM4PXD004463 for mobile-ip-dist; Fri, 26 Jul 2002 15:04:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QM4MoN004456 for ; Fri, 26 Jul 2002 15:04:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15992 for ; Fri, 26 Jul 2002 15:04:24 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00441 for ; Fri, 26 Jul 2002 15:04:23 -0700 (PDT) Received: from kmilesw2k (ams-clip-vpn-dhcp4253.cisco.com [10.50.16.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id XAA07767; Fri, 26 Jul 2002 23:04:21 +0100 (BST) From: "Kevin Miles" To: "'Jari Arkko'" Cc: Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments Date: Fri, 26 Jul 2002 23:04:18 +0100 Message-ID: <006b01c234f0$64799440$596cfe90@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D41989A.9050705@kolumbus.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Kevin Miles wrote: > > > > Okay. What about the rereg case? Can you 'upgrade' from S=1 > to S=0 in successive > > registration BUs? It doesn't sound, to me, like a useful > thing to be able to do. > > But if it's illegal, either we need a suitable error code, > or we need to say > > that the S bit is ignored in a BU for which there is an > existing BCE and treated > > as if it had the value of the originating BU. > > Good point. > > Why don't we simply allow this behaviour? The rereg will set > up entries for > every current prefix, and will override the entry for the > original single > address. > So at any time the mobile can choose to switch from S=1 to S=0? Which begs the question, can it also switch the other way and manage its set of BCEs individually? (Isn't this where we came in :-) I can't actually think why it would be useful for a mobile node to want to change the value of S in either direction during a single binding. Does anyone have a reason for allowing this? My preferred resolution is to declare that the value of S on all rereg and dereg BUs is ignored and treated as if it were the same as on the original BU. (If the mobile node really needs to change the value of S, it can always dereg and reg again.) Kevin. From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 20:04:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12593 for ; Fri, 26 Jul 2002 20:04:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23123; Fri, 26 Jul 2002 18:04:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02405; Fri, 26 Jul 2002 17:04:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R03PoN004785 for ; Fri, 26 Jul 2002 17:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R03Pxo004784 for mobile-ip-dist; Fri, 26 Jul 2002 17:03:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R03LoN004777 for ; Fri, 26 Jul 2002 17:03:21 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02171 for ; Fri, 26 Jul 2002 17:03:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03485 for ; Fri, 26 Jul 2002 18:03:24 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA28019; Fri, 26 Jul 2002 17:03:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6R03KJ31677; Fri, 26 Jul 2002 17:03:20 -0700 X-mProtect: <200207270003> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkUMY0O; Fri, 26 Jul 2002 17:03:18 PDT Message-ID: <3D41E346.83C63531@iprg.nokia.com> Date: Fri, 26 Jul 2002 17:03:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Miles CC: "'Jari Arkko'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <006b01c234f0$64799440$596cfe90@emea.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kevin Miles wrote: > > So at any time the mobile can choose to switch from S=1 to S=0? Which begs the > question, can it also switch the other way and manage its set of BCEs > individually? (Isn't this where we came in :-) > > I can't actually think why it would be useful for a mobile node to want to > change the value of S in either direction during a single binding. Does anyone > have a reason for allowing this? > > My preferred resolution is to declare that the value of S on all rereg and dereg > BUs is ignored and treated as if it were the same as on the original BU. (If the > mobile node really needs to change the value of S, it can always dereg and reg > again.) I agree with Kevin. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 21:17:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13816 for ; Fri, 26 Jul 2002 21:17:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13633; Fri, 26 Jul 2002 19:17:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18756; Fri, 26 Jul 2002 18:17:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R1EvoN005073 for ; Fri, 26 Jul 2002 18:14:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R1Evee005072 for mobile-ip-dist; Fri, 26 Jul 2002 18:14:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R1EsoN005065 for ; Fri, 26 Jul 2002 18:14:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11030 for ; Fri, 26 Jul 2002 18:14:56 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10149 for ; Fri, 26 Jul 2002 18:14:56 -0700 (PDT) Message-ID: <032401c2350a$5c486a70$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" , "'James Kempf'" , References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> <02b201c2344d$de137b20$a66015ac@AlperVAIO> <3D418D5E.CAA839D7@iprg.nokia.com> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 26 Jul 2002 18:10:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > > Let me make an attempt to answer your questions. > > > > > 1. How does the MN get the L2 address and IP address of the > > > new AR ? I see the following possibilities > > > a) PrRtAdv provides this > > > b) upon establishing a new link, the MN does RS and gets an RA > > > > > > How can you avoid PrRtAdv ? > > > > Please see CARID in draft-gwon-mobileip-efwd-fmipv6-00.txt. > > While MN is still connected to the oAR, it can request > > a table that maps L2 id of access points to L2/L3 ids of > > access routers. Than, after the movement MN learns > > the L2 id of the AP, and performs a table lookup for AR > > information. > > > > The difference between PrRtAdv and CARID is that the > > latter can happen any time before handover, not necessarily > > right before handover or upon anticipation. > > > > I agree that your proposal, after looking at the description > above, allows a MN to send packets on the new link when it > has not received PrRtAdv. I think others are also possible. > For instance, the MN can send a RS as soon as it detects a > new link and force the router to send an RA. There are > pros and cons associated with these mechanisms, of course. The advantage of CARID is that it saves one RTT on the new link. Latency associated with this can be significant especially in cellular networks. > > However, the question I have is, can we NOT specify PrRtAdv ? I'm not suggesting removal of PrRtAdv.. No problems there... > Seems to me that we need it for the base spec, and when additional > methods are available, the protocol can work well even when the MN > does not receive it. I am not sure if we can specify each of those > additional methods in the base spec..Do you agree ? Adapting CARID section of draft-gwon-mobileip-efwd-fmipv6-00.txt can be an option. This way, if MN cannot complete an anticipated handover, it can fall back to using information provided in CARID to create a tunnel between oAR and nAR after L2 handover, and preserve its oCoA. alper > > -Rajeev > > > > > > > Can we assume that L2 trigger > > > provides the necessary information ? > > > > Nope. > > > > > Which L2 trigger today > > > provides such information? > > > > I'm not aware of any... > > > > > Isn't this at best a recommendation > > > to future L2 designers ? > > > > I personally wouldn't recommend > > providing this L3 information via L2 signaling. > > > > > In any case, can we specify that > > > the protocol operates based on this assumption on _all_ links ? > > > > > > 2. When does the previous AR actually start forwarding packets > > > on the tunnel ? Should it do so even when it has not received a > > > FBU ? I think use of L2 triggers to more precisely time > > > forwarding is useful when the router has received FBU. > > > > I agree. > > > > > Doing > > > forwarding in the absence of FBU is redirecting traffic without > > > proper authorization, and as we have seen inMIPv6 security > > > exercise, involves security considerations. Can we say here that > > > L2 trigger will have the necessary authorization to redirect > > > traffic ? Even so, how can a base spec generalize it to all possible > > > link layers ? > > > > IMO, we should stay in the boundaries of Mobile IP model > > and only allow explicite BUs change routing state... > > IP can receive help from L2 though, in the form of L2 > > suggesting a BU be sent, or L2 suggesting precise time > > of routing change once AR/MN decided to do so. > > > > alper > > > > > > > > These are the crucial questions that determine the trade-off. I > > > would like to know what you and others think. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > "Alper E. YEGIN" wrote: > > > > > > > Hello Ajoy, > > > > > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > > > good idea. Protocols are sufficiently different to make considerable > > > > > performance differences. > > > > > > > > > > Ajoy-> I think claiming something works without proper data and > > > > > argument is also not a good idea. BTW, do you agree that due to higher > > > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > > > time ? > > > > > > > > Yes of course. > > > > > > > > > As you increase anticipation time, the likelihood > > > > > of handover failure will increase. > > > > > > > > This statement by itself also make sense... > > > > > > > > But, the question is how much difference does it make? > > > > Experimentation can help answer this question, and this is > > > > why I was asking if your statements were based on > > > > FMIPv6 experiments... > > > > > > > > Also, how much heads up can the mobile terminal or the network > > > > get before the link is broken without any anticipation? > > > > I presume link down doesn't happen instantly, at least L2 has to > > > > exchange some messages. Is there a window > > > > in which L3 can exchange packets? > > > > > > > > > I do not think this has > > > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > > > similar behavior in either case. > > > > > > > > But there is more... A fundamental difference between > > > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > > > registration request has to go all the way to home agent. > > > > This not only effects the latency, but also prevents taking > > > > advantage of L2 triggers on the oFA/oAR to precisely > > > > determine when the routing should change.. And this > > > > should make a difference in the observed performance.. > > > > > > > > alper > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 21:27:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13957 for ; Fri, 26 Jul 2002 21:27:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09651; Fri, 26 Jul 2002 19:27:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10091; Fri, 26 Jul 2002 18:27:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R1QmoN005209 for ; Fri, 26 Jul 2002 18:26:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R1QlIb005208 for mobile-ip-dist; Fri, 26 Jul 2002 18:26:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R1QioN005201 for ; Fri, 26 Jul 2002 18:26:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20503 for ; Fri, 26 Jul 2002 18:26:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13115 for ; Fri, 26 Jul 2002 18:26:46 -0700 (PDT) Message-ID: <033401c2350c$036f4a20$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "'James Kempf'" , "Rajeev Koodli" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Fri, 26 Jul 2002 18:22:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ajoy, You missed my questions below.. Any data points on these areas? I'm asking these specific to your cellular links... > Also, how much heads up can the mobile terminal or the network > get before the link is broken without any anticipation? > I presume link down doesn't happen instantly, at least L2 has to > exchange some messages. Is there a window > in which L3 can exchange packets? alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jul 26 22:18:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15144 for ; Fri, 26 Jul 2002 22:18:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26960; Fri, 26 Jul 2002 20:18:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23178; Fri, 26 Jul 2002 19:18:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R2HmoN005411 for ; Fri, 26 Jul 2002 19:17:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R2HmgM005410 for mobile-ip-dist; Fri, 26 Jul 2002 19:17:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R2HjoN005403 for ; Fri, 26 Jul 2002 19:17:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22980 for ; Fri, 26 Jul 2002 19:17:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28128 for ; Fri, 26 Jul 2002 19:17:47 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA03604; Fri, 26 Jul 2002 19:17:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6R2Hiq26847; Fri, 26 Jul 2002 19:17:44 -0700 X-mProtect: <200207270217> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyqO5Ej; Fri, 26 Jul 2002 19:17:43 PDT Message-ID: <3D4202C7.5C001E05@iprg.nokia.com> Date: Fri, 26 Jul 2002 19:17:43 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> <02b201c2344d$de137b20$a66015ac@AlperVAIO> <3D418D5E.CAA839D7@iprg.nokia.com> <032401c2350a$5c486a70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Alper E. YEGIN" wrote: > > > > I agree that your proposal, after looking at the description > > above, allows a MN to send packets on the new link when it > > has not received PrRtAdv. I think others are also possible. > > For instance, the MN can send a RS as soon as it detects a > > new link and force the router to send an RA. There are > > pros and cons associated with these mechanisms, of course. > > The advantage of CARID is that it saves one RTT on the new > link. Latency associated with this can be significant especially > in cellular networks. > Ok. > > > > > However, the question I have is, can we NOT specify PrRtAdv ? > > I'm not suggesting removal of PrRtAdv.. No problems there... > Ok. > > > Seems to me that we need it for the base spec, and when additional > > methods are available, the protocol can work well even when the MN > > does not receive it. I am not sure if we can specify each of those > > additional methods in the base spec..Do you agree ? > > Adapting CARID section of draft-gwon-mobileip-efwd-fmipv6-00.txt > can be an option. This way, if MN cannot complete an anticipated > handover, it can fall back to using information provided in CARID > to create a tunnel between oAR and nAR after L2 handover, > and preserve its oCoA. > The draft certainly does not disallow using methods like yours if they are available. -Rajeev > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 27 09:29:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01740 for ; Sat, 27 Jul 2002 09:29:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03934; Sat, 27 Jul 2002 07:29:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13843; Sat, 27 Jul 2002 06:29:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RDSYoN006388 for ; Sat, 27 Jul 2002 06:28:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6RDSYQG006387 for mobile-ip-dist; Sat, 27 Jul 2002 06:28:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RDSUoN006380 for ; Sat, 27 Jul 2002 06:28:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16085 for ; Sat, 27 Jul 2002 06:28:35 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA17333 for ; Sat, 27 Jul 2002 06:28:28 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmd3d42fae9; Sat, 27 Jul 2002 13:28:23 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm8e3d3df8ae; Tue, 23 Jul 2002 19:27:26 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA08729 for ietf-123-outbound.01@ietf.org; Tue, 23 Jul 2002 09:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA08124 for ; Tue, 23 Jul 2002 08:07:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07197; Tue, 23 Jul 2002 08:06:32 -0400 (EDT) Message-Id: <200207231206.IAA07197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-satish-mobileip-inter-technology-00.txt Date: Tue, 23 Jul 2002 08:06:31 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP considerations for Inter-technology handovers Author(s) : S. Jamadagni, D. Satish Filename : draft-satish-mobileip-inter-technology-00.txt Pages : 8 Date : 22-Jul-02 Multi mode terminals are becoming pervasive. In a multi mode environment, Mobile Terminals (MTs) move from the coverage of one radio access network to another. There is a need to maintain ongoing network sessions to support seamless services. For example, a MT may roam between a 3G cellular network and a wireless LAN seamlessly with session continuity. It is possible for a single service provider to support multiple modes but it is expected that different modes will be supported by different service providers. For example WLAN support can be enterprise supported where as 3G services are supported by a wide area service provider. In this draft we discuss handover support between multiple domains (modes) where a MT can use different IP addresses or can use a global IP address. Handover between different modes will then require greater federation capabilities between the different IP domains. In this draft we discuss Home Agent federation capabilities over Mobile IP so that inter-technology, inter-domain handovers are better supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-satish-mobileip-inter-technology-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-satish-mobileip-inter-technology-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-satish-mobileip-inter-technology-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020722134439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-satish-mobileip-inter-technology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-satish-mobileip-inter-technology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020722134439.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 27 11:40:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03211 for ; Sat, 27 Jul 2002 11:40:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28823; Sat, 27 Jul 2002 09:41:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28304; Sat, 27 Jul 2002 08:41:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFeAoN006664 for ; Sat, 27 Jul 2002 08:40:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6RFeA03006663 for mobile-ip-dist; Sat, 27 Jul 2002 08:40:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFe7oN006656 for ; Sat, 27 Jul 2002 08:40:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09176 for ; Sat, 27 Jul 2002 08:40:11 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28722 for ; Sat, 27 Jul 2002 09:40:06 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6RFdtL07495; Sat, 27 Jul 2002 17:39:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08644; Sat, 27 Jul 2002 17:39:49 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6RFdm6o006101; Sat, 27 Jul 2002 17:39:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207271539.g6RFdm6o006101@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "Hesham Soliman (EAB)" , "''mobile-ip@sunroof.eng.sun.com' '" Subject: Re: [mobile-ip] The link-local address issue In-reply-to: Your message of Fri, 26 Jul 2002 12:30:47 +0300. <3D4116C7.7030700@kolumbus.fi> Date: Sat, 27 Jul 2002 17:39:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: If not, then I think the right thing to do would be to have the MIPv6 specification require "resetting" all ND information upon movement. => I agree but this should not be bound to MIPv6... Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 27 11:47:06 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03300 for ; Sat, 27 Jul 2002 11:47:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29867; Sat, 27 Jul 2002 09:47:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29134; Sat, 27 Jul 2002 08:47:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFkXoN006831 for ; Sat, 27 Jul 2002 08:46:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6RFkXae006830 for mobile-ip-dist; Sat, 27 Jul 2002 08:46:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFkUoN006823 for ; Sat, 27 Jul 2002 08:46:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10318 for ; Sat, 27 Jul 2002 08:46:34 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07300 for ; Sat, 27 Jul 2002 08:46:33 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6RFk9L07661; Sat, 27 Jul 2002 17:46:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08672; Sat, 27 Jul 2002 17:46:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6RFk96o006133; Sat, 27 Jul 2002 17:46:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207271546.g6RFk96o006133@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Vijay Devarapalli , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs In-reply-to: Your message of Fri, 26 Jul 2002 13:14:45 +0300. <3D412115.5000609@kolumbus.fi> Date: Sat, 27 Jul 2002 17:46:09 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: However, I have some doubts about this still. But let me first describe the alternatives we have: 1. No R-bit in base spec. => do you mean "R-bit in base spec". 2. R-Bit in an draft-kniveton-mobrtr-02.txt 3. No R-bit, ever. I think no one is arguing for #3 so we can only consider #1 and #2. But what is their difference? One concern is that if the base spec does not define this, then it becomes impossible to extend this functionality later. This is obviously not an issue, as there is reserved space in the BUs that can be used. => I can't see a real difference between a reversed dedicated space and #1. So #1 is simpler for the future. Another possible concern is that when base-only HA implementations are deployed, it becomes impossible to deploy mobile routers as the existing HAs do not support them. => don't forget that in IPv6 a node is either a host or a router (exclusive "or"). Presumably, we are talking a case where a mobile host is a router at the same time. => s/host/node/ ! In conclusion, my suggestion is that we should define the R bit in draft-kniveton and keep the base spec from increasing in length once more... => as you still have to reserve the bit I don't buy this argument. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Jul 27 11:53:23 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03662 for ; Sat, 27 Jul 2002 11:53:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13137; Sat, 27 Jul 2002 08:52:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11386; Sat, 27 Jul 2002 08:52:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFpKoN006983 for ; Sat, 27 Jul 2002 08:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6RFpKxR006982 for mobile-ip-dist; Sat, 27 Jul 2002 08:51:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6RFpHoN006975 for ; Sat, 27 Jul 2002 08:51:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01868 for ; Sat, 27 Jul 2002 08:51:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12977 for ; Sat, 27 Jul 2002 08:51:20 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6RFp9L07933; Sat, 27 Jul 2002 17:51:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08697; Sat, 27 Jul 2002 17:51:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6RFp96o006154; Sat, 27 Jul 2002 17:51:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207271551.g6RFp96o006154@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Michael Thomas , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] rules for using IPsec for MN-HA protection In-reply-to: Your message of Fri, 26 Jul 2002 12:07:56 +0300. <3D41116C.2050806@kolumbus.fi> Date: Sat, 27 Jul 2002 17:51:09 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: It's probably going to be popular, yes. But there also seems to be quite many folks who don't want to be forced into doing IPsec for all of their traffic just because they wanted to protect (a) BUs to HAs and (b) HOTIs/HOTs routed through the HA. => note that (a) is transport mode. So I think it is a requirement that the HOTs/HOTIs be protected separately from the rest of the payload traffic. => I disagree: you should stand HOTs/HOTIs must be protected and leave the "separately" to implementors' choice. In fact IMHO: - protection requirements should be "MUSTs" - standard/smart way to do it should be "SHOULDs" - there must be some "MAYs" for alternative less efficient but easier in some cases solutions. The protection of the whole traffic through the MN-HA tunnel is a good example of this. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jul 28 20:33:13 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04823 for ; Sun, 28 Jul 2002 20:33:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03127; Sun, 28 Jul 2002 17:31:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18543; Sun, 28 Jul 2002 17:31:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T0UooN008945 for ; Sun, 28 Jul 2002 17:30:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T0UoJL008944 for mobile-ip-dist; Sun, 28 Jul 2002 17:30:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T0UloN008937 for ; Sun, 28 Jul 2002 17:30:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00148 for ; Sun, 28 Jul 2002 17:30:51 -0700 (PDT) Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02934 for ; Sun, 28 Jul 2002 17:30:50 -0700 (PDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KKNWFGH0U89DCMIR@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 29 Jul 2002 10:18:32 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 75620130036; Mon, 29 Jul 2002 10:16:47 +1000 (EST) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by splat.its.monash.edu.au (Postfix) with ESMTP id 12E5C130008; Mon, 29 Jul 2002 10:16:45 +1000 (EST) Date: Mon, 29 Jul 2002 10:16:46 +1000 From: Brett Pentland Subject: Re: [mobile-ip] Clarification sought on role of MIN_DELAY_BETWEEN_RAS X-Sender: "Brett Pentland" To: Jari Arkko Cc: mobile-ip@sunroof.eng.sun.com Message-id: <3D44896E.97E99EF7@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en]C-CCK-MCD monwin/025 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <125608d1254b64.1254b64125608d@mail1.monash.edu.au> <3D413CBE.6070405@kolumbus.fi> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Yes, that was my concern. I just wasn't sure if it was valid since the only place MIN_DEALY_BETWEEN_RAS is mentioned in rfc2461 is in section 6.2.6, "Processing Router Solicitations". Regards, Brett. Jari Arkko wrote: > > Brett Pentland wrote: > > > Hi folks, > > > > I was just wondering if anyone can confirm that the protocol > > constant "MIN_DELAY_BETWEEN_RAS" defined in RFC2461 as 3 seconds only > > relates to multicast RAs sent in response to an RS and thus is > > unrelated to the configuration variable "MinRtrAdvInterval" for > > unsolicited multicast RAs which is redefined in the Mobile IPv6 I-D. > > MIN_DELAY_BETWEEN_RAS concerns any RA sent to the all nodes multicast > address, solicited or unsolicited. > > MinRtrAdvInterval concerns unsolicited RAs. These would also be sent > to the all nodes multicast address. > > We redefine MinRtrAdvInterval in the MIPv6 I-D. It would seem that > MIN_DELAY_BETWEEN_RAS must also be redefined for it to have any effect. > Was that your concern? > > Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 01:52:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09561 for ; Mon, 29 Jul 2002 01:52:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06559; Sun, 28 Jul 2002 23:52:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28904; Sun, 28 Jul 2002 22:52:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T5pioN009681 for ; Sun, 28 Jul 2002 22:51:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T5pio4009680 for mobile-ip-dist; Sun, 28 Jul 2002 22:51:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T5pfoN009673 for ; Sun, 28 Jul 2002 22:51:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14791 for ; Sun, 28 Jul 2002 22:51:46 -0700 (PDT) Received: from mtv01owa01.mindtree.com ([202.56.254.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05116 for ; Sun, 28 Jul 2002 23:51:43 -0600 (MDT) Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 29 Jul 2002 11:18:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Info regarding IP Header Compression Date: Mon, 29 Jul 2002 11:18:36 +0530 Message-ID: Thread-Topic: Info regarding IP Header Compression Thread-Index: AcI2w5UcIK9L+wImTbielClR6D30QQ== From: "Sridhar S" To: X-OriginalArrivalTime: 29 Jul 2002 05:48:37.0007 (UTC) FILETIME=[953C39F0:01C236C3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6T5pfoN009674 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, I am S.Sridhar working in MindTree Consulting, Bangalore , India as a Software Engineer. We are in the process of implementing the IP Header Compression Protocol. So In this regard I have a couple of doubts. So I request you to spare some time and answer my doubts or suggest some document which specifies the relevant information. Coming to the subject: According to RFC 2057 (IP Header Compression Algorithm), several headers such as IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers can be compressed. Every header should be compressed based on a context. In order to create a context we have to identify a packet stream. There may be several type of packets coming from the upper layer. So keeping this in view we have to group the packets into different packet streams where all the packets in the same stream have a similar header fields. In this regard,... 1.Firstly, I want to know whether we have to buffer all the packets coming from application and then group them into different packet streams, then create contexts according to those packet streams and then assign CID's to them. If this is the case what will be done for next packet that arrives. Will if be compared with all contexts to find out to which packet stream it belongs.....or else again buffer a set of packets and repeat the grouping procedure and then search different contexts... If we buffer the incoming packets ,then till what time should we buffer it. Here I am really confused about the grouping procedure when coming to implementation. Can u please explain it in detail to me.... 2. I want to know the storing database part of these contexts also. can u please reply to this mail at the earliest. Thanks and Regards, SRIDHAR S Software Engineer, MindTree Consulting Pvt Ltd , C/o.Brigade Software Park, #42,27th cross,Banashankari 2nd stage, Bangalore - 560 070 Ph (O): +91-80-6711777 / 12777 Ext: 1423 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 09:36:11 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29298 for ; Mon, 29 Jul 2002 09:36:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02300; Mon, 29 Jul 2002 06:34:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15048; Mon, 29 Jul 2002 06:34:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TDUboN010805 for ; Mon, 29 Jul 2002 06:30:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TDUbMt010804 for mobile-ip-dist; Mon, 29 Jul 2002 06:30:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TDUYoN010797 for ; Mon, 29 Jul 2002 06:30:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13919 for ; Mon, 29 Jul 2002 06:30:29 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08008 for ; Mon, 29 Jul 2002 07:30:28 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 5841F20A6; Mon, 29 Jul 2002 06:30:28 -0700 (PDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 65618FEB; Mon, 29 Jul 2002 08:30:29 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g6TDUOs0000782570; Mon, 29 Jul 2002 09:30:25 -0400 (EDT) Message-ID: <3D454370.9050802@hp.com> Date: Mon, 29 Jul 2002 09:30:24 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: "Hesham Soliman (EAB)" , Francis Dupont , "''mobile-ip@sunroof.eng.sun.com' '" Subject: Re: [mobile-ip] The link-local address issue References: <200207150752.g6F7qkGF061058@givry.rennes.enst-bretagne.fr> <3D4116C7.7030700@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, I agree. There was a thread a few months ago about what to do with NCE on the mobile, but that did not get any answeres. It looks like the "resetting" all ND state is the way to go. -vlad Jari Arkko wrote: > MIPv6 specification require "resetting" all ND information > upon movement. That is, we'd forget the fact that we had collisions > in a previous location. We'd also forget the fact that we did > DAD for an address in the previous location, and would be > forced to do a new DAD... I think this would make the protocols > less vulnerable to local problems, whatever they might be. > > > Jari +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 10:42:24 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01894 for ; Mon, 29 Jul 2002 10:42:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06747; Mon, 29 Jul 2002 08:42:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00790; Mon, 29 Jul 2002 07:42:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEfXoN011167 for ; Mon, 29 Jul 2002 07:41:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TEfXhb011166 for mobile-ip-dist; Mon, 29 Jul 2002 07:41:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEfUoN011159 for ; Mon, 29 Jul 2002 07:41:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28044 for ; Mon, 29 Jul 2002 07:41:34 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04029 for ; Mon, 29 Jul 2002 07:41:34 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA03332 for ; Mon, 29 Jul 2002 07:41:33 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA20425 for ; Mon, 29 Jul 2002 07:40:01 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 29 Jul 2002 09:41:32 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" Cc: "Alper E. YEGIN" , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Mon, 29 Jul 2002 09:41:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Rajeev, Please find my inline reply. Regards, ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, July 26, 2002 4:35 PM To: Singh Ajoy-ASINGH1 Cc: Alper E. YEGIN; 'Vijay Devarapalli'; 'James Kempf'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Singh Ajoy-ASINGH1 wrote: > > Ajoy, Alper, > > I have few questions for you. > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > AJOY-> In case of network-controlled handoff, why MN is required > to get the IP address of the new AR ? Could you clarify > this? > The MN needs an IP address of the gateway for a default Destination. If you have a unix system, "netstat -rn" should produce the route table entries that includes the Gateway address for default destination. AJOY-> BTW, when there is a serial pipe (link) between MN and AR, the MN should be able to route packet even without getting the actual IP address of the new AR. Suppose at some of point of time, MN is connected to oAR and using the IP address of oAR as the default gateway. Also, the routing table entry indicates that to reach the default gateway (oAR), the serial interface s0 should be used. In this case, an MN will be sending all the outgoing packets to a CN over the serial link s0. Now, even after MN moves from oAR to nAR, it will have the same routing table entries. The only difference will be that the serial link s0 will terminate to nAR instead of oAR. The relocation of termination point of the serial interface (s0) from oAR to nAR should be handled by the link layer handoff. So, in this case also, mobile node should be able to send any outgoing packets to a CN through the serial interface s0 as it was doing while connected with oAR. Moreover, the nAR should be able to route any MN originated outgoing packet to CN using standard IP routing. So, in case of serial link, we can probably afford to wait for default route update until standard Mobile/IP registration is performed. I do agree this approach may not work for the Ethernet type of MAC. BTW, as far as I know, most of today's bandwidth constraint links provide serial connection between MN and AR. So, I guess we should make PrRtAdv as an optional message rather than a mandatory one. I also see a possibility of CARD to obtain the IP address of nAR. Please let me know in case I missed something. The L2 address is needed for encapsulating the IP packet in a L2 frame. AJOY-> In case of serial link, L2 address is not required to be present in each and every L2 frame. Such information is only required during link setup. > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > AJOY-> As I said, in case of network controlled handoff, both ARs > can communicate to create visitor list entry for the Mobile > node at the nAR. Why we need PrRtAdv in critical path in this > Visitor list entry? Do you mean host route entry? Ajoy-> Yes, I used MIPv4 term. > case? As far as I know, BETH can be implemented in any wireless > technology capable of supporting network controlled handover. > Even this can be extended for Mobile controlled handover. > Please let me know in case you know of something where this can > not be implemented. > The routers communicate to establish a host route entry for the MN on the new AR. But, that does not help the MN in _sending_ packets unless it has the new AR's addresses. The purpose of PrRtAdv is to provide this information. AJOY-> Probably this is not an issue when we have serial link between MN and AR. In this case, even if we do not update the default route of MN with nAR, all the packets sent over serial link will reach to nAR. Mostly low bandwidth wireless links are serial link. I still think, we should keep PrRtAdv as an optional message that should be sent by the nAR to MN in case of Ethernet type of MAC. What you think? As I asked in my questions, who provides this information? Are we assuming that L2 trigger will be able to provide this? If yes, then I am asking can we specify that in the base draft which ought to work on all link types ? I also don't know which L2 type provides such information today.. AJOY-> I was not assuming that L2 trigger will provide the IP address of nAR. My assumption was that in serial link, we can get away by without updating the default route at MN in critical path of handover. > > Isn't this at best a recommendation > to future L2 designers ? > > Ajoy-> To make something useful, we need to consider the > need of present network. I will be skeptical to > standardize something in the hope of being used in > remote (?) future. > Good. I didn't say we should standardize this. I am saying to expect something from link layers should be part of a wish list. > > In any case, can we specify that > the protocol operates based on this assumption on _all_ links ? > > 2. When does the previous AR actually start forwarding packets > on the tunnel ? Should it do so even when it has not received a > FBU ? > > AJOY-> In BETH, as far as I remember, oAR will start forwarding packets > after receiving link down event. But, my question is should we allow that even in the absence of receiving an FBU? See the questions below (in my previous e-mail).. AJOY-> Yes. But we should state that this should be implemented in case of secure link layer. > > > I think use of L2 triggers to more precisely time > forwarding is useful when the router has received FBU. Doing > forwarding in the absence of FBU is redirecting traffic without > proper authorization, and as we have seen inMIPv6 security > exercise, involves security considerations. Can we say here that > L2 trigger will have the necessary authorization to redirect > traffic ? Even so, how can a base spec generalize it to all possible > link layers ? > > AJOY-> Base protocol will just have to state that link layer must be > secure. Since, we are not defining link layer triggers in > base draft, we do not need to be concerned about how > L2 trigger will be secured. > Well, how can we enforce that a particular L2 be secure in the base draft ? In an IP protocol, we can certainly state that FBU must be protected before traffic can be redirected. AJOY-> I am not sure if IP can enforce the security of link layer. I think we should state the implication of using in-secure link layer triggers in security section of the draft. > > These are the crucial questions that determine the trade-off. I > would like to know what you and others think. > > AJOY-> We are talking about fast handoff. So, we need a solution > that can provide reliable fast handoff. > I agree we are talking about fast handover :-) In what way is the protocol not robust ? It should work in the presence of lost messages and should provide the desired performance. I would be happy to address those considerations. Also, could you comment specifically on how we can avoid PrRtAdv and FBU ? That would be more useful. AJOY-> Hopefully, I have addressed these points in this email. Thanks, -Rajeev > > Regards, > > -Rajeev > > "Alper E. YEGIN" wrote: > > > Hello Ajoy, > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > good idea. Protocols are sufficiently different to make considerable > > > performance differences. > > > > > > Ajoy-> I think claiming something works without proper data and > > > argument is also not a good idea. BTW, do you agree that due to higher > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > time ? > > > > Yes of course. > > > > > As you increase anticipation time, the likelihood > > > of handover failure will increase. > > > > This statement by itself also make sense... > > > > But, the question is how much difference does it make? > > Experimentation can help answer this question, and this is > > why I was asking if your statements were based on > > FMIPv6 experiments... > > > > Also, how much heads up can the mobile terminal or the network > > get before the link is broken without any anticipation? > > I presume link down doesn't happen instantly, at least L2 has to > > exchange some messages. Is there a window > > in which L3 can exchange packets? > > > > > I do not think this has > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > similar behavior in either case. > > > > But there is more... A fundamental difference between > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > registration request has to go all the way to home agent. > > This not only effects the latency, but also prevents taking > > advantage of L2 triggers on the oFA/oAR to precisely > > determine when the routing should change.. And this > > should make a difference in the observed performance.. > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 10:45:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02093 for ; Mon, 29 Jul 2002 10:45:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13952; Mon, 29 Jul 2002 08:46:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28850; Mon, 29 Jul 2002 07:46:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEjOoN011307 for ; Mon, 29 Jul 2002 07:45:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TEjOMK011306 for mobile-ip-dist; Mon, 29 Jul 2002 07:45:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEjKoN011299 for ; Mon, 29 Jul 2002 07:45:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14785 for ; Mon, 29 Jul 2002 07:45:25 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17390 for ; Mon, 29 Jul 2002 07:45:24 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA19140 for ; Mon, 29 Jul 2002 07:45:24 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA22406 for ; Mon, 29 Jul 2002 07:43:51 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 29 Jul 2002 09:45:23 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Mon, 29 Jul 2002 09:45:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This depends upon the radio condition and RF planning. But anyway in case of cellular link only a few over the air messages are sent. Typically, it is difficult to overlap L3 signaling with L2 signaling in same time frame. regards, ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Friday, July 26, 2002 8:22 PM To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, You missed my questions below.. Any data points on these areas? I'm asking these specific to your cellular links... > Also, how much heads up can the mobile terminal or the network > get before the link is broken without any anticipation? > I presume link down doesn't happen instantly, at least L2 has to > exchange some messages. Is there a window > in which L3 can exchange packets? alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 12:58:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07362 for ; Mon, 29 Jul 2002 12:58:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28595; Mon, 29 Jul 2002 09:57:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21212; Mon, 29 Jul 2002 09:57:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TGtuoN011714 for ; Mon, 29 Jul 2002 09:55:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TGttDN011713 for mobile-ip-dist; Mon, 29 Jul 2002 09:55:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TGtqoN011706 for ; Mon, 29 Jul 2002 09:55:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20679 for ; Mon, 29 Jul 2002 09:55:52 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23784 for ; Mon, 29 Jul 2002 10:55:51 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 29 Jul 2002 09:55:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23720.CB2FAE23" Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 29 Jul 2002 09:55:50 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF228@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Re: summary of HAO, BE processing discussion Thread-Index: AcI0otlrA3+NdGveQiqGb3TGE9a77QCfU6xA From: "Mohan Parthasarathy" To: "Jari Arkko" Cc: "shima" , , , X-OriginalArrivalTime: 29 Jul 2002 16:55:50.0983 (UTC) FILETIME=[CB582D70:01C23720] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C23720.CB2FAE23 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 >=20 >=20 > > > > In addition, the current draft requires not only HAO=20 > but > also=20 > > BE. This > > means all IPv6 nodes must implement a new extention=20 > > header > (mobility > > > > header). > > > > > > > > > Correct. > > > > > If you read section 9.4.6, "Sending Binding Errors", yes it is > > correct. But reading section 6.3 "Home Address option", it says > > that if a node does not understand this option, it should return > > ICMP parameter problem. Are these in conflict ? >=20 > No, ICMP is used if you don't recognize the option. This is=20 > standard behaviour in IPv6. BE is used if you understand the=20 > option but don't like the contents. >=20 Agreed. But if you read section 8.1, "General requirements of all IPv6 Nodes", it reads that all nodes MUST process Home address option. But if you read section 6.3, it gives me an impression that all nodes can choose not to recognise the option and send an ICMP error back. This is a bit confusing to me. I hope all this will get cleared up when we decide on the SHOULD or MUST on the processing of home address option. -mohan P.S : I have removed ipng from the CC list. > Jari >=20 >=20 >=20 ------_=_NextPart_001_01C23720.CB2FAE23 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: summary of HAO, BE processing = discussion

 
>
>
> >  > > In addition, the current = draft requires not only HAO
> but  > also
> > BE. This  > > means all IPv6 = nodes must implement a new extention
> > header  > (mobility
> >  > > header).
> >  >
> >  >
> >  > Correct.
> >  >
> > If you read section 9.4.6, "Sending = Binding Errors", yes it is
> > correct. But reading section 6.3 "Home = Address option", it says
> > that if a node does not understand this = option, it should return
> > ICMP parameter problem. Are these in = conflict ?
>
> No, ICMP is used if you don't recognize the = option. This is
> standard behaviour in IPv6. BE is used if you = understand the
> option but don't like the contents.
>
Agreed. But if you read section 8.1, "General = requirements of all
IPv6 Nodes", it reads that all nodes MUST = process Home address
option. But if you read section 6.3, it gives me an = impression
that all nodes can choose not to recognise the option = and send
an ICMP error back. This is a bit confusing to me. I = hope all
this will get cleared up when we decide on the SHOULD = or MUST on
the processing of home address option.

-mohan

P.S : I have removed ipng from the CC list.
> Jari
>
>
>

------_=_NextPart_001_01C23720.CB2FAE23-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 14:34:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10052 for ; Mon, 29 Jul 2002 14:34:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20444; Mon, 29 Jul 2002 12:35:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26234; Mon, 29 Jul 2002 11:35:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIXnoN012154 for ; Mon, 29 Jul 2002 11:33:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TIXnTb012153 for mobile-ip-dist; Mon, 29 Jul 2002 11:33:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIXgoN012145 for ; Mon, 29 Jul 2002 11:33:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25709 for ; Mon, 29 Jul 2002 11:33:46 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11768 for ; Mon, 29 Jul 2002 11:33:45 -0700 (PDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 14:33:44 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166E8@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Joseph Soma Reddy'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Mon, 29 Jul 2002 14:33:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I guess OBAST was ahead of its time? > -----Original Message----- > From: Joseph Soma Reddy [mailto:soma@cwc.ucsd.edu] > Sent: Friday, July 26, 2002 12:59 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > Hello all, > I would like to point out that mobility protocol should not > only ensure routing to mobile hosts, it should be able to > support macrodiversity(i.e. soft handoff) which is very > important in cdma systems. Macrodiversity is already being > incorporated in systems like HDR(High Data Rate system from > Qualcomm) where the mobile can move between different > cell sectors before receiving each packet. With a good > mobility scheme, it is possible to extend this and enable > the mobile to handoff quickly between BS, which can result > in coverage and capacity increase. > > I have addressed this issue in a recent draft > ("macrodiversity in IP based cellular networks" > available at http://cwc.ucsd.edu/~soma ). > The main conclusions were that the mobile should be able to > handoff as soon as channel conditions changes(i.e. post-reg > handoff) and that it should be possible to handoff without > requiring any over-the-air signalling. > I am concerned that the v5 draft provides for these > mechanisms only as error conditions. > > Another concern I have with respect to anticipated handoffs > is that it seems to place requirements on the physical/link > layers with respect to how channel conditions change(i.e. it > assumes that they change gradually enough to be anticipated). > This is not necessarily true even in current systems. For > example, the so called "street corner effect" occurs in dense > urban areas where the base stations are mounted on poletops. > The coverage of these BS extends linearly(along a block) rather > than omnidirectionally. A mobile user who turns a street corner > in such an environment will lose line-of-sight with current BS > and enter line-of-sight of another BS. This causes a sudden handoff > which can only be handled by post-reg type of mobility. > These type of situations are common in micro-cellular > networks which will become more common in future > as increased demand for capacity is met by reducing cell > size. > > Comments are appreciated. > > Regards, > Joseph > > > > > **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 15:13:46 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11574 for ; Mon, 29 Jul 2002 15:13:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26850; Mon, 29 Jul 2002 13:14:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12266; Mon, 29 Jul 2002 12:14:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TJDBoN012728 for ; Mon, 29 Jul 2002 12:13:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TJDADW012727 for mobile-ip-dist; Mon, 29 Jul 2002 12:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TJD7oN012720 for ; Mon, 29 Jul 2002 12:13:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11965 for ; Mon, 29 Jul 2002 12:13:12 -0700 (PDT) Received: from cwc.ucsd.edu (cwc.ucsd.edu [132.239.228.42]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10903 for ; Mon, 29 Jul 2002 13:13:11 -0600 (MDT) Received: from cts4.ucsd.edu (cts4.ucsd.edu [132.239.134.16]) by cwc.ucsd.edu (8.12.1/8.11.3) with ESMTP id g6TJCAVl023478; Mon, 29 Jul 2002 12:12:10 -0700 (PDT) Date: Mon, 29 Jul 2002 12:13:04 -0700 (PDT) From: Joseph Soma Reddy X-X-Sender: To: Rajeev Koodli cc: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions In-Reply-To: <3D418B9F.58FCC8AA@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 26 Jul 2002, Rajeev Koodli wrote: > Hello Joseph, > > thanks for your input. I have some general comments first. > An IP-based protocol has to work on all link types, while > allowing individual links to customize the protocol for > improving performance. If the protocol is based on the > chatacteristics of a single link type, then the chances are the > protocol won't work at all or won't work the way it should > on all the link types. I agree. > > Did you see my earlier posting in which I had asked few > questions ? Those questions directly relate to your comment > regarding over-the-air signaling. Specifically, > > - how do you inform the new AR's L2 and IP address to the MN ? > - should we assume that L2 specific information is sufficient to > redirect traffic without explicit authorization (in the form of FBU) > from the MN ? > > These are broader questions, and are not specific to a particular > link technology. I would be interested in hearing how your proposal > would address these two key questions. I would also appreciate if you > could take a look at my previous posting and respond to the questions > there. Signalling on cellular link introduces high delay. So it may be useful to do away with it in some situations. I proposed one way in "microbility strategies in IPCN"(available at http://cwc.ucsd.edu/~soma ). Other mechansims have been suggested in recent mails. Of course, there is no need to include these mechanisms in the current draft. > > > I would like to point out that mobility protocol should not > > only ensure routing to mobile hosts, it should be able to > > support macrodiversity(i.e. soft handoff) which is very > > important in cdma systems. Macrodiversity is already being > > incorporated in systems like HDR(High Data Rate system from > > Qualcomm) where the mobile can move between different > > cell sectors before receiving each packet. With a good > > mobility scheme, it is possible to extend this and enable > > the mobile to handoff quickly between BS, which can result > > in coverage and capacity increase. > > > > Role of IP in dealing with macrodiversity is an interesting topic and > I am sure will spur lot of discussion. However, increasing capacity, or > more generally, the topic of macrodiversity itself is not an objective > of fast handover. If there is sufficient interest, I think this should > be > explored separately in the WG. I am not suggesting that macrodiversity be included in this draft. Rather, I was giving an example of a link layer consideration that would influence the choice of performing protocol operations "prior to" or "subsequent to" handoff. I think this choice will be dependent on particular L2 technology and there is no need for the current draft to propose a preferred("prior to") mode and an error condition("subsequent to"). > > > > > > I have addressed this issue in a recent draft > > ("macrodiversity in IP based cellular networks" > > available at http://cwc.ucsd.edu/~soma ). > > The main conclusions were that the mobile should be able to > > handoff as soon as channel conditions changes(i.e. post-reg > > handoff) and that it should be possible to handoff without > > requiring any over-the-air signalling. > > I am concerned that the v5 draft provides for these > > mechanisms only as error conditions. > > > > Well, if the AR does not change during such a handover, > there is not anything for the protocol to do. One could argue > that this is a matter of how you roll out the network. The AR does change during handoff. But that does not necessarily mean there should be over-the-air signalling, as explained above. > > The v05 version allows tunnel establishment subsequent > to the MN attaching to the new link. I don't know if you > have followed the previous versions of the draft or not, but > the reason for this is that the protocol begins on the old link > and the FBU is anticipated to be sent from the old link. > In any case, I have received comments that it would be better > to explain this under a separate section, and I will do that. > > > > > > Another concern I have with respect to anticipated handoffs > > is that it seems to place requirements on the physical/link > > layers with respect to how channel conditions change(i.e. it > > assumes that they change gradually enough to be anticipated). > > > > Actually, there is no such assumption. If the MN does not receive > PrRtAdv, it triggers tunnel establishment after attaching to the > new link. If PrRtAdv can be delivered to the MN on the previous > link, then, also providing the new router's prefix information > facilitates faster new IP address configuration (aka anticipation). > ............. > So, in order for the protocol to work on all link types without > making specific assumptions about what _a_ link type "might be able > to provide", and more importantly, to keep following the principle > of specifying IP protocols for IETF standardization, we need to > specify PrRtAdv and FBU. At the same time, the draft should be > able to allow L2-specific customizations. I have no problem with specifiing PrRtAdv. But, in order to work or all link layers, the protocol should also be able to operate without it, depending instead on L2-specific customizations. I understand the draft allows that. Regards, Joseph From owner-mobile-ip@sunroof.eng.sun.com Mon Jul 29 16:32:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14017 for ; Mon, 29 Jul 2002 16:32:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13694; Mon, 29 Jul 2002 13:31:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07467; Mon, 29 Jul 2002 13:31:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TKTsoN013002 for ; Mon, 29 Jul 2002 13:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TKTsjS013001 for mobile-ip-dist; Mon, 29 Jul 2002 13:29:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TKTpoN012994 for ; Mon, 29 Jul 2002 13:29:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07006 for ; Mon, 29 Jul 2002 13:29:56 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13063 for ; Mon, 29 Jul 2002 13:29:56 -0700 (PDT) Message-ID: <013101c2373e$0bed5b40$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" Cc: "'James Kempf'" , "Rajeev Koodli" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Mon, 29 Jul 2002 13:25:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ajoy, > This depends upon the radio condition and > RF planning. Sure. But I thought you could still answer this based on your experiments. > But anyway in case of cellular > link only a few over the air messages are sent. > Typically, it is difficult to overlap > L3 signaling with L2 signaling in same > time frame. These L3 signaling is just IP packets. Basically this says once L2 signaling starts going on, IP packets are not guaranteed to be delivered. This would create additional latency on top of actual L2 blackout time between link down and link up.. Right? alper > regards, > ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Friday, July 26, 2002 8:22 PM > To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > Ajoy, > > You missed my questions below.. Any data points on these areas? > I'm asking these specific to your cellular links... > > > Also, how much heads up can the mobile terminal or the network > > get before the link is broken without any anticipation? > > I presume link down doesn't happen instantly, at least L2 has to > > exchange some messages. Is there a window > > in which L3 can exchange packets? > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 30 13:15:35 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29861 for ; Tue, 30 Jul 2002 13:15:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10981; Tue, 30 Jul 2002 10:14:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13792; Tue, 30 Jul 2002 10:14:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UHDKoN015398 for ; Tue, 30 Jul 2002 10:13:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UHDKoA015397 for mobile-ip-dist; Tue, 30 Jul 2002 10:13:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UHDHoN015390 for ; Tue, 30 Jul 2002 10:13:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13448 for ; Tue, 30 Jul 2002 10:13:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20962 for ; Tue, 30 Jul 2002 11:13:21 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25446; Tue, 30 Jul 2002 10:13:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6UHDJ617345; Tue, 30 Jul 2002 10:13:19 -0700 X-mProtect: <200207301713> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSiSqEB; Tue, 30 Jul 2002 10:11:25 PDT Message-ID: <3D46C899.D3163CF@iprg.nokia.com> Date: Tue, 30 Jul 2002 10:10:50 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "Alper E. YEGIN" , "'Vijay Devarapalli'" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ajoy, thanks for your input. Some comments.. - I think PrRtAdv is needed in order to work on all link types. Note that the protocol does work when the MN moves without receiving it, i.e., the tunnel is established subsequent to new link establishment. I think the scenario you describe could be covered by this with the addition that HI/HAck exchange could occur in response to the network detecting imminent handover. Also note that there is L2 signaling exchange for handover and it could very well be possible for PrRtAdv message to get through during this time period. - I am still not convinced that we can avoid FBU by assuming a secure link layer. The issue is more of authorizing the network to redirect traffic. A secure link layer does not necessarily provide such a feature. Besides, shouldn't we be focussing on IP and Mobile-IP related protocol exchange, rather than speculating the availability and features of secure link layers ? Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > Hello Rajeev, > Please find my inline reply. > Regards, > ajoy > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, July 26, 2002 4:35 PM > To: Singh Ajoy-ASINGH1 > Cc: Alper E. YEGIN; 'Vijay Devarapalli'; 'James Kempf'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > Singh Ajoy-ASINGH1 wrote: > > > > > Ajoy, Alper, > > > > I have few questions for you. > > > > 1. How does the MN get the L2 address and IP address of the > > new AR ? I see the following possibilities > > a) PrRtAdv provides this > > b) upon establishing a new link, the MN does RS and gets an RA > > > > AJOY-> In case of network-controlled handoff, why MN is required > > to get the IP address of the new AR ? Could you clarify > > this? > > > > The MN needs an IP address of the gateway for a default > Destination. If you have a unix system, "netstat -rn" should > produce the route table entries that includes the Gateway > address for default destination. > > AJOY-> BTW, when there is a serial pipe (link) between MN and AR, the MN > should > be able to route packet even without getting the actual IP address of the > new > AR. Suppose at some of point of time, MN is connected to oAR and > using the IP address of oAR as the default gateway. Also, the routing table > entry > indicates that to reach the default gateway (oAR), the serial interface s0 > should > be used. In this case, an MN will be sending all the outgoing packets to a > CN over > the serial link s0. Now, even after MN moves from oAR to nAR, it will have > the > same routing table entries. The only difference will be that the serial link > s0 > will terminate to nAR instead of oAR. The relocation of termination point of > > the serial interface (s0) from oAR to nAR should be handled by the link > layer > handoff. So, in this case also, mobile node should be able to send any > outgoing > packets to a CN through the serial interface s0 as it was doing while > connected > with oAR. Moreover, the nAR should be able to route any MN originated > outgoing > packet to CN using standard IP routing. So, in case of serial link, we can > probably afford to wait for default route update until standard Mobile/IP > registration > is performed. I do agree this approach may not work for the Ethernet type of > MAC. > BTW, as far as I know, most of today's bandwidth constraint links provide > serial > connection between MN and AR. So, I guess we should make PrRtAdv as an > optional > message rather than a mandatory one. I also see a possibility of CARD to > obtain the > IP address of nAR. Please let me know in case I missed something. > > The L2 address is needed for encapsulating the IP packet > in a L2 frame. > > AJOY-> In case of serial link, L2 address is not required to be present > in each and every L2 frame. Such information is only required during link > setup. > > > > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > > provides the necessary information ? Which L2 trigger today > > provides such information? > > > > AJOY-> As I said, in case of network controlled handoff, both ARs > > can communicate to create visitor list entry for the Mobile > > node at the nAR. Why we need PrRtAdv in critical path in this > > > > Visitor list entry? Do you mean host route entry? > > Ajoy-> Yes, I used MIPv4 term. > > > case? As far as I know, BETH can be implemented in any wireless > > technology capable of supporting network controlled handover. > > Even this can be extended for Mobile controlled handover. > > Please let me know in case you know of something where this can > > not be implemented. > > > > The routers communicate to establish a host route entry for the MN > on the new AR. But, that does not help the MN in _sending_ packets > unless it has the new AR's addresses. The purpose of PrRtAdv is > to provide this information. > > AJOY-> Probably this is not an issue when we have serial > link between MN and AR. In this case, even if we > do not update the default route of MN with nAR, all > the packets sent over serial link will reach to nAR. > Mostly low bandwidth wireless links are serial > link. I still think, we should keep PrRtAdv as > an optional message that should be sent by the nAR to MN > in case of Ethernet type of MAC. What you think? > > As I asked in my questions, who provides this information? Are we > assuming that L2 trigger will be able to provide this? If yes, then I > am asking can we specify that in the base draft which ought to work > on all link types ? I also don't know which L2 type provides such > information today.. > > AJOY-> I was not assuming that L2 trigger will provide the > IP address of nAR. My assumption was that in serial > link, we can get away by without updating the default > route at MN in critical path of handover. > > > > > Isn't this at best a recommendation > > to future L2 designers ? > > > > Ajoy-> To make something useful, we need to consider the > > need of present network. I will be skeptical to > > standardize something in the hope of being used in > > remote (?) future. > > > > Good. I didn't say we should standardize this. I am saying to > expect something from link layers should be part of a wish list. > > > > > In any case, can we specify that > > the protocol operates based on this assumption on _all_ links ? > > > > 2. When does the previous AR actually start forwarding packets > > on the tunnel ? Should it do so even when it has not received a > > FBU ? > > > > AJOY-> In BETH, as far as I remember, oAR will start forwarding packets > > after receiving link down event. > > But, my question is should we allow that even in the absence of > receiving an FBU? See the questions below (in my previous e-mail).. > > AJOY-> Yes. But we should state that this should be implemented in > case of secure link layer. > > > > > > > I think use of L2 triggers to more precisely time > > forwarding is useful when the router has received FBU. Doing > > forwarding in the absence of FBU is redirecting traffic without > > proper authorization, and as we have seen inMIPv6 security > > exercise, involves security considerations. Can we say here that > > L2 trigger will have the necessary authorization to redirect > > traffic ? Even so, how can a base spec generalize it to all possible > > link layers ? > > > > AJOY-> Base protocol will just have to state that link layer must be > > secure. Since, we are not defining link layer triggers in > > base draft, we do not need to be concerned about how > > L2 trigger will be secured. > > > > Well, how can we enforce that a particular L2 be secure in the base > draft ? In an IP protocol, we can certainly state that FBU must be > protected before traffic can be redirected. > > AJOY-> I am not sure if IP can enforce the security of link layer. > I think we should state the implication of using in-secure link layer > triggers in security section of the draft. > > > > > These are the crucial questions that determine the trade-off. I > > would like to know what you and others think. > > > > AJOY-> We are talking about fast handoff. So, we need a solution > > that can provide reliable fast handoff. > > > > I agree we are talking about fast handover :-) > In what way is the protocol not robust ? It should work in > the presence of lost messages and should provide the desired > performance. I would be happy to address those considerations. > > Also, could you comment specifically on how we can > avoid PrRtAdv and FBU ? That would be more useful. > > AJOY-> Hopefully, I have addressed these points in > this email. > > Thanks, > > -Rajeev > > > > > Regards, > > > > -Rajeev > > > > "Alper E. YEGIN" wrote: > > > > > Hello Ajoy, > > > > > > > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and > > > > then applying to "anticipated FMIPv6" without experimenting is not a > > > > good idea. Protocols are sufficiently different to make considerable > > > > performance differences. > > > > > > > > Ajoy-> I think claiming something works without proper data and > > > > argument is also not a good idea. BTW, do you agree that due to higher > > > > RTT of cellular link, FMIPv6 will require higher anticipation > > > > time ? > > > > > > Yes of course. > > > > > > > As you increase anticipation time, the likelihood > > > > of handover failure will increase. > > > > > > This statement by itself also make sense... > > > > > > But, the question is how much difference does it make? > > > Experimentation can help answer this question, and this is > > > why I was asking if your statements were based on > > > FMIPv6 experiments... > > > > > > Also, how much heads up can the mobile terminal or the network > > > get before the link is broken without any anticipation? > > > I presume link down doesn't happen instantly, at least L2 has to > > > exchange some messages. Is there a window > > > in which L3 can exchange packets? > > > > > > > I do not think this has > > > > anything to do with FMIPv6 or FMIPv4. You will observe > > > > similar behavior in either case. > > > > > > But there is more... A fundamental difference between > > > FMIPv6 and pre-reg FMIPv4 is that with the latter the > > > registration request has to go all the way to home agent. > > > This not only effects the latency, but also prevents taking > > > advantage of L2 triggers on the oFA/oAR to precisely > > > determine when the routing should change.. And this > > > should make a difference in the observed performance.. > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 30 19:17:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12644 for ; Tue, 30 Jul 2002 19:17:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23836; Tue, 30 Jul 2002 17:18:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00627; Tue, 30 Jul 2002 16:18:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UNHDoN016576 for ; Tue, 30 Jul 2002 16:17:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UNHDYN016575 for mobile-ip-dist; Tue, 30 Jul 2002 16:17:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UNHAoN016568 for ; Tue, 30 Jul 2002 16:17:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00107 for ; Tue, 30 Jul 2002 16:17:14 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23313 for ; Tue, 30 Jul 2002 17:17:13 -0600 (MDT) Message-ID: <013b01c2381e$820a4280$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" , References: <022b01c2343b$932efc40$a66015ac@AlperVAIO> <3D40A7DA.85A2A1D8@iprg.nokia.com> <02b201c2344d$de137b20$a66015ac@AlperVAIO> <02ec01c2380b$cbf8c870$296015ac@T23KEMPF> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Tue, 30 Jul 2002 16:11:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think we need to include the complete question here: 1. How does the MN get the L2 address and IP address of the new AR ? I see the following possibilities a) PrRtAdv provides this b) upon establishing a new link, the MN does RS and gets an RA How can you avoid PrRtAdv ? Can we assume that L2 trigger provides the necessary information ? Which L2 trigger today provides such information? Does MN really get "L2 and IP address of the new AR"? I see MN is aware of the L2 id of the Base Stations, but note that this is not same as L2 id of AR(s) behind them. alper ----- Original Message ----- From: "James Kempf" To: "Alper E. YEGIN" ; "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" ; Sent: Tuesday, July 30, 2002 1:58 PM Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > Which L2 trigger today > > > provides such information? > > > > I'm not aware of any... > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", Section > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > Section 12.25.3.8, "Handoff Indication". This version is a little old but > probably not very far off from the current W-CDMA specification. > > In Section 11.7, the procedures for mobile controlled and network controlled > handover are described. In the mobile controlled case, the mobile sends a layer > 2 identifier to the current base station indicating the target base station to > which the mobile wants to hand over, and gets back a response indicating whether > handover is allowed or denied. In the network controlled case, the current base > station sends the same information to the mobile. (Note: "layer 3" in this > specification actually refers to what from the IP viewpoint would be the MAC > layer, or layer 2). The network controlled case is used to manage power and cell > load, the mobile controlled case is used when the power level on the mobile goes > below the specified handoff point. > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP layer, > what W-CDMA already does at the MAC layer. Also in either case, the layer 2 > information should be sufficient to allow the base station to perform a layer 3 > handover without any over the air layer 3 signaling, provided the base station > has a way to map the target base station id to an IP address, using GAARD or a > preconfigured table. > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under the NBAP > and RNSAP RAN protocols. > > I don't have access to an IS-2000 specification at the moment, but I'm working > on getting the same information. Other wireless link layers must provide this > information in some form, either before handover, as with the cellular > protocols, or afterwards, as with 802.11. Barring make before break, without > some information at layer 2 about where the mobile is going, it is simply > impossible for the link to get switched, and, without a link, it is not possible > to do IP. If the layer 2 protocol supports real make before break (not soft > handover), none of the fast handover protocols are necessary, since the mobile > can do RS/RA on the forward link while receiving its traffic on the backward > one. > > jak > > (fyi, Alper, the specification in question is in the DoCoMo library, if you care > to check it out.) > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jul 30 19:40:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13195 for ; Tue, 30 Jul 2002 19:40:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03275; Tue, 30 Jul 2002 17:40:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03642; Tue, 30 Jul 2002 16:40:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UNdOoN016709 for ; Tue, 30 Jul 2002 16:39:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UNdORE016708 for mobile-ip-dist; Tue, 30 Jul 2002 16:39:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UNdLoN016701 for ; Tue, 30 Jul 2002 16:39:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27188 for ; Tue, 30 Jul 2002 16:39:25 -0700 (PDT) Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02702 for ; Tue, 30 Jul 2002 17:39:25 -0600 (MDT) Received: from [134.102.101.207] (helo=IPonAir) by smtp.web.de with smtp (WEB.DE(Exim) 4.75 #2) id 17ZgaJ-0007XZ-00 for mobile-ip@sunroof.eng.sun.com; Wed, 31 Jul 2002 01:39:23 +0200 Message-ID: <002901c23822$79ba9630$cf656686@IPonAir> From: "Michael Sessinghaus" To: "mobile ip" Subject: [mobile-ip] Columbia IP Micro-Mobility Suite (CIMS) -ns-2 simulation- Date: Wed, 31 Jul 2002 01:40:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C23833.3CFE9500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C23833.3CFE9500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, has anyone to gather experiencein investigations about hierarchical = mobile ip with the Columbia IP Micro-Mobility Suite (CIMS)? Is that = right, that it is possible to simulate a scenario which a ad hoc network = and their nodes establish a internet connection over mobile ip? The = interaction between e.g. aodv and mobile ip on layer 3/2? Thanks. Best Regards, Michael.=20 ------=_NextPart_000_0026_01C23833.3CFE9500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
has anyone to gather experiencein = investigations about hierarchical mobile ip with the Columbia IP=20 Micro-Mobility Suite (CIMS)? Is that right, that it is possible to = simulate a=20 scenario which a ad hoc network and their nodes establish a = internet=20 connection over mobile ip? The interaction between e.g. aodv and mobile = ip on=20 layer 3/2?
 
Thanks. Best Regards,=20 Michael. 
------=_NextPart_000_0026_01C23833.3CFE9500-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 00:28:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19943 for ; Wed, 31 Jul 2002 00:28:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24093; Tue, 30 Jul 2002 21:27:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05149; Tue, 30 Jul 2002 21:27:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6V4QRoN017651 for ; Tue, 30 Jul 2002 21:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6V4QQVb017650 for mobile-ip-dist; Tue, 30 Jul 2002 21:26:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6V4QNoN017643 for ; Tue, 30 Jul 2002 21:26:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28313 for ; Tue, 30 Jul 2002 21:26:27 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19663 for ; Tue, 30 Jul 2002 22:26:26 -0600 (MDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id NAA03727 for ; Wed, 31 Jul 2002 13:26:24 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g6V4QORp002649 for ; Wed, 31 Jul 2002 13:26:24 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g6V4QNxH016436 for ; Wed, 31 Jul 2002 13:26:23 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA13019 for ; Wed, 31 Jul 2002 13:26:23 +0900 (JST) Received: from OHNISHI-GW.lab.ntt.co.jp by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA15615 for ; Wed, 31 Jul 2002 13:26:22 +0900 (JST) Message-Id: <4.3.2-J.20020731113855.06b6db88@imd.m.ecl.ntt.co.jp> X-Sender: ho005@imd.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Wed, 31 Jul 2002 13:32:04 +0900 To: mobile-ip@sunroof.eng.sun.com From: Hiroyuki OHNISHI Subject: [mobile-ip] Mobile IPv6 I-D 18:BA status value Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I have some comments about BA status value in I-D 18. 1. Typo: status value for insufficient resources *6.1.8. Binding Acknowledgement (BA) Message 130 Insufficient resources ~~~~ 131 Home registration not supported *9.5. Cache Replacement Policy When attempting to add a new "home registration" entry in response to a Binding Update with the Home Registration (H) bit set, if no sufficient space can be found, the node MUST reject the Binding Update and MUST return a Binding Acknowledgement to the sending mobile node, in which the Status field is set to 131 (insufficient ~~~~~~~~ resources). 2: Question: status value 136 (Route optimization unnecessary due to low traffic) I do not understand clearly how to use this status value. I am not sure that I missed some information about usage of this status value. The followings are my assumptions. *Case 1 HA measures the traffic that pass trough the HA. and if the amount of traffic is low, the HA notifies MN that route optimization is not needed. This status value is sent to the MN as BA for MN's home registration. (Receiving the BA with 136, the MN does not try to initiate RR.) *Case 2 Or is this value related to following description in 6.1.2? 6.1.2. Binding Refresh Request (BRR) Message [...] When a mobile node receives a packet containing a Binding Refresh Request message and there already exists a Binding Update List entry for the source of the Binding Refresh Request, it MAY start a return routability procedure (see Section 5.2) if it believes the amount of traffic with the ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ correspondent justifies the use of route optimization. This means MN judges whether the MN uses RO or not depends on the amount of traffic with CN when it receives BRR. And if the amount is low enough, it sends BA with 136 to the CN? --- Hiroyuki From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 03:49:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17547 for ; Wed, 31 Jul 2002 03:49:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00991; Wed, 31 Jul 2002 01:50:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14083; Wed, 31 Jul 2002 00:50:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6V7mmoN018022 for ; Wed, 31 Jul 2002 00:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6V7mmjG018021 for mobile-ip-dist; Wed, 31 Jul 2002 00:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6V7mjoN018014 for ; Wed, 31 Jul 2002 00:48:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06497 for ; Wed, 31 Jul 2002 00:48:49 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01454 for ; Wed, 31 Jul 2002 00:48:48 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id C4C486A906; Wed, 31 Jul 2002 10:48:39 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 30B546A905; Wed, 31 Jul 2002 10:48:37 +0300 (EEST) Message-ID: <3D4796D0.6000801@kolumbus.fi> Date: Wed, 31 Jul 2002 10:50:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Hiroyuki OHNISHI Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value References: <4.3.2-J.20020731113855.06b6db88@imd.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hiroyuki OHNISHI wrote: > *6.1.8. Binding Acknowledgement (BA) Message > > 130 Insufficient resources > ~~~~ > 131 Home registration not supported > > *9.5. Cache Replacement Policy > When attempting to add a new "home registration" entry in response > to a Binding Update with the Home Registration (H) bit set, if no > sufficient space can be found, the node MUST reject the Binding > Update and MUST return a Binding Acknowledgement to the sending > mobile node, in which the Status field is set to 131 (insufficient > > ~~~~~~~~ > resources). Right... > 2: Question: status value 136 > (Route optimization unnecessary due to low traffic) > > I do not understand clearly how to use this status value. > I am not sure that I missed some information about usage of this status > value. > The followings are my assumptions. > > *Case 1 > HA measures the traffic that pass trough the HA. and if the amount of > traffic is low, > the HA notifies MN that route optimization is not needed. > This status value is sent to the MN as BA for MN's home registration. > (Receiving the BA with 136, the MN does not try to initiate RR.) > > *Case 2 > Or is this value related to following description in 6.1.2? > > 6.1.2. Binding Refresh Request (BRR) Message > > [...] When a mobile node receives a > packet containing a Binding Refresh Request message and there > already exists a Binding Update List entry for the source of the > Binding Refresh Request, it MAY start a return routability procedure > (see Section 5.2) if it believes the amount of traffic with the > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > correspondent justifies the use of route optimization. > > This means MN judges whether the MN uses RO or not depends > on the amount of traffic with CN when it receives BRR. > And if the amount is low enough, it sends BA with 136 to the CN? Hmm... for sure this value is not for the home registrations. I don't think the HA should be involved in traffic measurements either. If the MN decides to not initiate RR and BU, it simply never sends any packets, so the BRR does not need an error answer. Where this error was meant to be used is when the CN supports RO, but for this particular MN it does not want to give the service as it believes there's too little traffic to benefit from RO. Text is missing on how to use this. However, I'm not really sure this is genuinely different from 130. 130 means "i don't have enough memory or signaling resources to establish RO with you". Does that mean hitting a hard limit on available BCE entries, or some value judgement on using a remaining BCE entry for this particular MN, given some assessment of how much traffic we are going to have with that MN? The trouble is, from the MN's point of view both of these look the same. My suggestion is that we clarify the rules for using 130 and remove 136. Issue #91. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 07:37:19 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21725 for ; Wed, 31 Jul 2002 07:37:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12246; Wed, 31 Jul 2002 05:37:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11055; Wed, 31 Jul 2002 04:37:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VBafoN018366 for ; Wed, 31 Jul 2002 04:36:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VBafDg018365 for mobile-ip-dist; Wed, 31 Jul 2002 04:36:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VBaboN018358 for ; Wed, 31 Jul 2002 04:36:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10901 for ; Wed, 31 Jul 2002 04:36:42 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26266 for ; Wed, 31 Jul 2002 05:36:41 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21410; Wed, 31 Jul 2002 07:35:32 -0400 (EDT) Message-Id: <200207311135.HAA21410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-qos-requirements-03.txt Date: Wed, 31 Jul 2002 07:35:32 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-mobileip-qos-requirements-03.txt Pages : 8 Date : 30-Jul-02 Mobile IP ensures correct routing of packets to mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-qos-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020730114353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-qos-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020730114353.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 09:57:45 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27406 for ; Wed, 31 Jul 2002 09:57:44 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27897; Wed, 31 Jul 2002 06:56:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09104; Wed, 31 Jul 2002 06:56:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VDsZoN018678 for ; Wed, 31 Jul 2002 06:54:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VDsZ0H018676 for mobile-ip-dist; Wed, 31 Jul 2002 06:54:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VDsWoN018669 for ; Wed, 31 Jul 2002 06:54:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08778 for ; Wed, 31 Jul 2002 06:54:36 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07559 for ; Wed, 31 Jul 2002 07:54:35 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA20158 for ; Wed, 31 Jul 2002 06:54:34 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA15285 for ; Wed, 31 Jul 2002 06:54:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Jul 2002 08:54:33 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" Cc: "'James Kempf'" , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 08:54:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Monday, July 29, 2002 3:25 PM To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, > This depends upon the radio condition and > RF planning. Sure. But I thought you could still answer this based on your experiments. AJOY-> In our setup, we had approx 220ms window to exchange all L2 and L3 messages. We found we were not able to complete the exchange of L2 and L2 exchange in the same time frame. > But anyway in case of cellular > link only a few over the air messages are sent. > Typically, it is difficult to overlap > L3 signaling with L2 signaling in same > time frame. These L3 signaling is just IP packets. Basically this says once L2 signaling starts going on, IP packets are not guaranteed to be delivered. AJOY-> Absoultely. This would create additional latency on top of actual L2 blackout time between link down and link up.. Right? AJOY-> Correct alper > regards, > ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Friday, July 26, 2002 8:22 PM > To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli' > Cc: 'James Kempf'; Rajeev Koodli; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > Ajoy, > > You missed my questions below.. Any data points on these areas? > I'm asking these specific to your cellular links... > > > Also, how much heads up can the mobile terminal or the network > > get before the link is broken without any anticipation? > > I presume link down doesn't happen instantly, at least L2 has to > > exchange some messages. Is there a window > > in which L3 can exchange packets? > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 10:00:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27560 for ; Wed, 31 Jul 2002 10:00:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23718; Wed, 31 Jul 2002 08:01:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10489; Wed, 31 Jul 2002 07:01:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VDxQoN018805 for ; Wed, 31 Jul 2002 06:59:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VDxQHX018804 for mobile-ip-dist; Wed, 31 Jul 2002 06:59:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VDxMoN018797 for ; Wed, 31 Jul 2002 06:59:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07380 for ; Wed, 31 Jul 2002 06:59:26 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22816 for ; Wed, 31 Jul 2002 07:59:26 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA03228 for ; Wed, 31 Jul 2002 06:59:26 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA07694 for ; Wed, 31 Jul 2002 06:59:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Jul 2002 08:59:21 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , James Kempf , Rajeev Koodli Cc: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 08:59:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, In my previous reply to Rajeev, I explained why MN is not required to know the L2 address of nAR in case of srial link. Why this question again? If you do not agree, please comment on my previous email. Regards, Ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, July 30, 2002 6:12 PM To: James Kempf; Rajeev Koodli Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions I think we need to include the complete question here: 1. How does the MN get the L2 address and IP address of the new AR ? I see the following possibilities a) PrRtAdv provides this b) upon establishing a new link, the MN does RS and gets an RA How can you avoid PrRtAdv ? Can we assume that L2 trigger provides the necessary information ? Which L2 trigger today provides such information? Does MN really get "L2 and IP address of the new AR"? I see MN is aware of the L2 id of the Base Stations, but note that this is not same as L2 id of AR(s) behind them. alper ----- Original Message ----- From: "James Kempf" To: "Alper E. YEGIN" ; "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" ; Sent: Tuesday, July 30, 2002 1:58 PM Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > Which L2 trigger today > > > provides such information? > > > > I'm not aware of any... > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", Section > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > Section 12.25.3.8, "Handoff Indication". This version is a little old but > probably not very far off from the current W-CDMA specification. > > In Section 11.7, the procedures for mobile controlled and network controlled > handover are described. In the mobile controlled case, the mobile sends a layer > 2 identifier to the current base station indicating the target base station to > which the mobile wants to hand over, and gets back a response indicating whether > handover is allowed or denied. In the network controlled case, the current base > station sends the same information to the mobile. (Note: "layer 3" in this > specification actually refers to what from the IP viewpoint would be the MAC > layer, or layer 2). The network controlled case is used to manage power and cell > load, the mobile controlled case is used when the power level on the mobile goes > below the specified handoff point. > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP layer, > what W-CDMA already does at the MAC layer. Also in either case, the layer 2 > information should be sufficient to allow the base station to perform a layer 3 > handover without any over the air layer 3 signaling, provided the base station > has a way to map the target base station id to an IP address, using GAARD or a > preconfigured table. > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under the NBAP > and RNSAP RAN protocols. > > I don't have access to an IS-2000 specification at the moment, but I'm working > on getting the same information. Other wireless link layers must provide this > information in some form, either before handover, as with the cellular > protocols, or afterwards, as with 802.11. Barring make before break, without > some information at layer 2 about where the mobile is going, it is simply > impossible for the link to get switched, and, without a link, it is not possible > to do IP. If the layer 2 protocol supports real make before break (not soft > handover), none of the fast handover protocols are necessary, since the mobile > can do RS/RA on the forward link while receiving its traffic on the backward > one. > > jak > > (fyi, Alper, the specification in question is in the DoCoMo library, if you care > to check it out.) > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 15:21:41 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14260 for ; Wed, 31 Jul 2002 15:21:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15559; Wed, 31 Jul 2002 12:19:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21112; Wed, 31 Jul 2002 12:19:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJGUoN019771 for ; Wed, 31 Jul 2002 12:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJGUXV019770 for mobile-ip-dist; Wed, 31 Jul 2002 12:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJGOoN019763 for ; Wed, 31 Jul 2002 12:16:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09012 for ; Wed, 31 Jul 2002 12:16:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10593 for ; Wed, 31 Jul 2002 13:16:27 -0600 (MDT) Message-ID: <00fa01c238c6$1b643fb0$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "James Kempf" , "Rajeev Koodli" Cc: "Singh Ajoy-ASINGH1" , "'Vijay Devarapalli'" , References: Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 12:10:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ajoy, > Alper, > In my previous reply to Rajeev, I explained why > MN is not required to know the L2 address of nAR > in case of srial link. Why this question again? The reason I cut-and-pasted the same question from an earlier message was to make sure that we were answering the same question with James.... > If you do > not agree, please comment on my previous > email. But now that you asked.... This is becoming more and more like a L2 handover mechanism, now that the IP stack of MN doesn't even know it changed its default router... Probably one can make this work, but making serial link assumptions is also limiting... alper > Regards, > Ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, July 30, 2002 6:12 PM > To: James Kempf; Rajeev Koodli > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > I think we need to include the complete question here: > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > Does MN really get "L2 and IP address of the new AR"? > I see MN is aware of the L2 id of the Base Stations, but note > that this is not same as L2 id of AR(s) behind them. > > alper > > > > ----- Original Message ----- > From: "James Kempf" > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > ; > Sent: Tuesday, July 30, 2002 1:58 PM > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > Which L2 trigger today > > > > provides such information? > > > > > > I'm not aware of any... > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > Section > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > > Section 12.25.3.8, "Handoff Indication". This version is a little old but > > probably not very far off from the current W-CDMA specification. > > > > In Section 11.7, the procedures for mobile controlled and network > controlled > > handover are described. In the mobile controlled case, the mobile sends a > layer > > 2 identifier to the current base station indicating the target base > station to > > which the mobile wants to hand over, and gets back a response indicating > whether > > handover is allowed or denied. In the network controlled case, the current > base > > station sends the same information to the mobile. (Note: "layer 3" in this > > specification actually refers to what from the IP viewpoint would be the > MAC > > layer, or layer 2). The network controlled case is used to manage power > and cell > > load, the mobile controlled case is used when the power level on the > mobile goes > > below the specified handoff point. > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP > layer, > > what W-CDMA already does at the MAC layer. Also in either case, the layer > 2 > > information should be sufficient to allow the base station to perform a > layer 3 > > handover without any over the air layer 3 signaling, provided the base > station > > has a way to map the target base station id to an IP address, using GAARD > or a > > preconfigured table. > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > the NBAP > > and RNSAP RAN protocols. > > > > I don't have access to an IS-2000 specification at the moment, but I'm > working > > on getting the same information. Other wireless link layers must provide > this > > information in some form, either before handover, as with the cellular > > protocols, or afterwards, as with 802.11. Barring make before break, > without > > some information at layer 2 about where the mobile is going, it is simply > > impossible for the link to get switched, and, without a link, it is not > possible > > to do IP. If the layer 2 protocol supports real make before break (not > soft > > handover), none of the fast handover protocols are necessary, since the > mobile > > can do RS/RA on the forward link while receiving its traffic on the > backward > > one. > > > > jak > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > you care > > to check it out.) > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 15:29:41 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14596 for ; Wed, 31 Jul 2002 15:29:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20648; Wed, 31 Jul 2002 12:28:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15919; Wed, 31 Jul 2002 12:28:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJR1oN019900 for ; Wed, 31 Jul 2002 12:27:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJR1fk019899 for mobile-ip-dist; Wed, 31 Jul 2002 12:27:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJQwoN019892 for ; Wed, 31 Jul 2002 12:26:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15306 for ; Wed, 31 Jul 2002 12:27:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19845 for ; Wed, 31 Jul 2002 12:27:02 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA08006; Wed, 31 Jul 2002 12:27:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6VJR1A21495; Wed, 31 Jul 2002 12:27:01 -0700 X-mProtect: <200207311927> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCyqAzC; Wed, 31 Jul 2002 12:26:59 PDT Message-ID: <3D483A04.81A6D06@iprg.nokia.com> Date: Wed, 31 Jul 2002 12:27:00 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Alper E. YEGIN'" , James Kempf , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ajoy, Singh Ajoy-ASINGH1 wrote: > Alper, > In my previous reply to Rajeev, I explained why > MN is not required to know the L2 address of nAR > in case of srial link. Why this question again? If you do > I also responded to your input. I guess you agree that an IP protocol has to supply this information in order for it work on all links ? At the same time, the protocol has to work if the MN moves without receiving the PrRtAdv, which should cover your scenario. So, my suggestion is that the base protocol defines the messages necessary to work on all links while it also allows for scenarios such as yours. This does not mean that you remove the message from the spec. Do you agree ? Regards, -Rajeev > not agree, please comment on my previous > email. > Regards, > Ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, July 30, 2002 6:12 PM > To: James Kempf; Rajeev Koodli > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > I think we need to include the complete question here: > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > Does MN really get "L2 and IP address of the new AR"? > I see MN is aware of the L2 id of the Base Stations, but note > that this is not same as L2 id of AR(s) behind them. > > alper > > ----- Original Message ----- > From: "James Kempf" > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > ; > Sent: Tuesday, July 30, 2002 1:58 PM > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > Which L2 trigger today > > > > provides such information? > > > > > > I'm not aware of any... > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > Section > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > > Section 12.25.3.8, "Handoff Indication". This version is a little old but > > probably not very far off from the current W-CDMA specification. > > > > In Section 11.7, the procedures for mobile controlled and network > controlled > > handover are described. In the mobile controlled case, the mobile sends a > layer > > 2 identifier to the current base station indicating the target base > station to > > which the mobile wants to hand over, and gets back a response indicating > whether > > handover is allowed or denied. In the network controlled case, the current > base > > station sends the same information to the mobile. (Note: "layer 3" in this > > specification actually refers to what from the IP viewpoint would be the > MAC > > layer, or layer 2). The network controlled case is used to manage power > and cell > > load, the mobile controlled case is used when the power level on the > mobile goes > > below the specified handoff point. > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP > layer, > > what W-CDMA already does at the MAC layer. Also in either case, the layer > 2 > > information should be sufficient to allow the base station to perform a > layer 3 > > handover without any over the air layer 3 signaling, provided the base > station > > has a way to map the target base station id to an IP address, using GAARD > or a > > preconfigured table. > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > the NBAP > > and RNSAP RAN protocols. > > > > I don't have access to an IS-2000 specification at the moment, but I'm > working > > on getting the same information. Other wireless link layers must provide > this > > information in some form, either before handover, as with the cellular > > protocols, or afterwards, as with 802.11. Barring make before break, > without > > some information at layer 2 about where the mobile is going, it is simply > > impossible for the link to get switched, and, without a link, it is not > possible > > to do IP. If the layer 2 protocol supports real make before break (not > soft > > handover), none of the fast handover protocols are necessary, since the > mobile > > can do RS/RA on the forward link while receiving its traffic on the > backward > > one. > > > > jak > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > you care > > to check it out.) > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 15:40:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15107 for ; Wed, 31 Jul 2002 15:40:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24648; Wed, 31 Jul 2002 13:40:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29756; Wed, 31 Jul 2002 12:40:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJdCoN020036 for ; Wed, 31 Jul 2002 12:39:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJdCsf020035 for mobile-ip-dist; Wed, 31 Jul 2002 12:39:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJd8oN020028 for ; Wed, 31 Jul 2002 12:39:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09979 for ; Wed, 31 Jul 2002 12:39:13 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27714 for ; Wed, 31 Jul 2002 13:39:13 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA03350 for ; Wed, 31 Jul 2002 12:39:12 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA13156 for ; Wed, 31 Jul 2002 12:39:30 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Jul 2002 14:39:11 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , Singh Ajoy-ASINGH1 Cc: "'Alper E. YEGIN'" , James Kempf , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 14:38:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So, my suggestion is that the base protocol defines the messages necessary to work on all links while it also allows for scenarios such as yours. This does not mean that you remove the message from the spec. Do you agree ? AJOY-> I agree with this if you make PrRTAdv as an optional message. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, July 31, 2002 2:27 PM To: Singh Ajoy-ASINGH1 Cc: 'Alper E. YEGIN'; James Kempf; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Ajoy, Singh Ajoy-ASINGH1 wrote: > Alper, > In my previous reply to Rajeev, I explained why > MN is not required to know the L2 address of nAR > in case of srial link. Why this question again? If you do > I also responded to your input. I guess you agree that an IP protocol has to supply this information in order for it work on all links ? At the same time, the protocol has to work if the MN moves without receiving the PrRtAdv, which should cover your scenario. So, my suggestion is that the base protocol defines the messages necessary to work on all links while it also allows for scenarios such as yours. This does not mean that you remove the message from the spec. Do you agree ? Regards, -Rajeev > not agree, please comment on my previous > email. > Regards, > Ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, July 30, 2002 6:12 PM > To: James Kempf; Rajeev Koodli > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > I think we need to include the complete question here: > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > Does MN really get "L2 and IP address of the new AR"? > I see MN is aware of the L2 id of the Base Stations, but note > that this is not same as L2 id of AR(s) behind them. > > alper > > ----- Original Message ----- > From: "James Kempf" > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > ; > Sent: Tuesday, July 30, 2002 1:58 PM > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > Which L2 trigger today > > > > provides such information? > > > > > > I'm not aware of any... > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > Section > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > > Section 12.25.3.8, "Handoff Indication". This version is a little old but > > probably not very far off from the current W-CDMA specification. > > > > In Section 11.7, the procedures for mobile controlled and network > controlled > > handover are described. In the mobile controlled case, the mobile sends a > layer > > 2 identifier to the current base station indicating the target base > station to > > which the mobile wants to hand over, and gets back a response indicating > whether > > handover is allowed or denied. In the network controlled case, the current > base > > station sends the same information to the mobile. (Note: "layer 3" in this > > specification actually refers to what from the IP viewpoint would be the > MAC > > layer, or layer 2). The network controlled case is used to manage power > and cell > > load, the mobile controlled case is used when the power level on the > mobile goes > > below the specified handoff point. > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP > layer, > > what W-CDMA already does at the MAC layer. Also in either case, the layer > 2 > > information should be sufficient to allow the base station to perform a > layer 3 > > handover without any over the air layer 3 signaling, provided the base > station > > has a way to map the target base station id to an IP address, using GAARD > or a > > preconfigured table. > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > the NBAP > > and RNSAP RAN protocols. > > > > I don't have access to an IS-2000 specification at the moment, but I'm > working > > on getting the same information. Other wireless link layers must provide > this > > information in some form, either before handover, as with the cellular > > protocols, or afterwards, as with 802.11. Barring make before break, > without > > some information at layer 2 about where the mobile is going, it is simply > > impossible for the link to get switched, and, without a link, it is not > possible > > to do IP. If the layer 2 protocol supports real make before break (not > soft > > handover), none of the fast handover protocols are necessary, since the > mobile > > can do RS/RA on the forward link while receiving its traffic on the > backward > > one. > > > > jak > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > you care > > to check it out.) > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 15:52:18 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15478 for ; Wed, 31 Jul 2002 15:52:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25927; Wed, 31 Jul 2002 12:51:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03325; Wed, 31 Jul 2002 12:51:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJnLoN020185 for ; Wed, 31 Jul 2002 12:49:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJnKV1020184 for mobile-ip-dist; Wed, 31 Jul 2002 12:49:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJnHoN020177 for ; Wed, 31 Jul 2002 12:49:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23087 for ; Wed, 31 Jul 2002 12:49:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28587 for ; Wed, 31 Jul 2002 13:49:21 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA08856; Wed, 31 Jul 2002 12:49:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6VJnKn11163; Wed, 31 Jul 2002 12:49:20 -0700 X-mProtect: <200207311949> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4G9euh; Wed, 31 Jul 2002 12:49:19 PDT Message-ID: <3D483F3F.318DE7D4@iprg.nokia.com> Date: Wed, 31 Jul 2002 12:49:19 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Alper E. YEGIN'" , James Kempf , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > So, my suggestion is that the base protocol > defines the messages necessary to work on all links > while it also allows for scenarios such as yours. This > does not mean that you remove the message from > the spec. Do you agree ? > > AJOY-> I agree with this if you make PrRTAdv as > an optional message. This question is for the WG to decide. What do others think ? Should we make PrRtAdv an optional message ? Interop implications ? -Rajeev > > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, July 31, 2002 2:27 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Alper E. YEGIN'; James Kempf; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > Ajoy, > > Singh Ajoy-ASINGH1 wrote: > > > Alper, > > In my previous reply to Rajeev, I explained why > > MN is not required to know the L2 address of nAR > > in case of srial link. Why this question again? If you do > > > > I also responded to your input. I guess you agree that > an IP protocol has to supply this information in > order for it work on all links ? At the same time, > the protocol has to work if the MN moves without > receiving the PrRtAdv, which should cover your > scenario. So, my suggestion is that the base protocol > defines the messages necessary to work on all links > while it also allows for scenarios such as yours. This > does not mean that you remove the message from > the spec. Do you agree ? > > Regards, > > -Rajeev > > > not agree, please comment on my previous > > email. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Tuesday, July 30, 2002 6:12 PM > > To: James Kempf; Rajeev Koodli > > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > > mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > I think we need to include the complete question here: > > > > 1. How does the MN get the L2 address and IP address of the > > new AR ? I see the following possibilities > > a) PrRtAdv provides this > > b) upon establishing a new link, the MN does RS and gets an RA > > > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > > provides the necessary information ? Which L2 trigger today > > provides such information? > > > > Does MN really get "L2 and IP address of the new AR"? > > I see MN is aware of the L2 id of the Base Stations, but note > > that this is not same as L2 id of AR(s) behind them. > > > > alper > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > > ; > > Sent: Tuesday, July 30, 2002 1:58 PM > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > > Which L2 trigger today > > > > > provides such information? > > > > > > > > I'm not aware of any... > > > > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division > Multiple > > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > > Section > > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", > and > > > Section 12.25.3.8, "Handoff Indication". This version is a little old > but > > > probably not very far off from the current W-CDMA specification. > > > > > > In Section 11.7, the procedures for mobile controlled and network > > controlled > > > handover are described. In the mobile controlled case, the mobile sends > a > > layer > > > 2 identifier to the current base station indicating the target base > > station to > > > which the mobile wants to hand over, and gets back a response indicating > > whether > > > handover is allowed or denied. In the network controlled case, the > current > > base > > > station sends the same information to the mobile. (Note: "layer 3" in > this > > > specification actually refers to what from the IP viewpoint would be the > > MAC > > > layer, or layer 2). The network controlled case is used to manage power > > and cell > > > load, the mobile controlled case is used when the power level on the > > mobile goes > > > below the specified handoff point. > > > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the > IP > > layer, > > > what W-CDMA already does at the MAC layer. Also in either case, the > layer > > 2 > > > information should be sufficient to allow the base station to perform a > > layer 3 > > > handover without any over the air layer 3 signaling, provided the base > > station > > > has a way to map the target base station id to an IP address, using > GAARD > > or a > > > preconfigured table. > > > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > > the NBAP > > > and RNSAP RAN protocols. > > > > > > I don't have access to an IS-2000 specification at the moment, but I'm > > working > > > on getting the same information. Other wireless link layers must provide > > this > > > information in some form, either before handover, as with the cellular > > > protocols, or afterwards, as with 802.11. Barring make before break, > > without > > > some information at layer 2 about where the mobile is going, it is > simply > > > impossible for the link to get switched, and, without a link, it is not > > possible > > > to do IP. If the layer 2 protocol supports real make before break (not > > soft > > > handover), none of the fast handover protocols are necessary, since the > > mobile > > > can do RS/RA on the forward link while receiving its traffic on the > > backward > > > one. > > > > > > jak > > > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > > you care > > > to check it out.) > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 16:20:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16653 for ; Wed, 31 Jul 2002 16:20:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19941; Wed, 31 Jul 2002 14:21:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03594; Wed, 31 Jul 2002 13:21:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VKJkoN020343 for ; Wed, 31 Jul 2002 13:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VKJkQN020342 for mobile-ip-dist; Wed, 31 Jul 2002 13:19:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VKJhoN020335 for ; Wed, 31 Jul 2002 13:19:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24342 for ; Wed, 31 Jul 2002 13:19:48 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19424 for ; Wed, 31 Jul 2002 13:19:48 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA12394 for ; Wed, 31 Jul 2002 13:19:47 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA17124 for ; Wed, 31 Jul 2002 13:19:47 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Jul 2002 15:19:46 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , James Kempf , Rajeev Koodli Cc: Singh Ajoy-ASINGH1 , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 15:19:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Alper, Please find my inline reply. Regards, Ajoy But now that you asked.... This is becoming more and more like a L2 handover mechanism, now that the IP stack of MN doesn't even know it changed its default router... Probably one can make this work, but making serial link assumptions is also limiting... AJOY-> I do not agree that this is becoming more or more like L2 handoff mechanism. MN always have option to perform Mobile/IP registration if required. The proposed solution only enables fast handoff to work more efficiently. -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, July 31, 2002 2:11 PM To: Singh Ajoy-ASINGH1; James Kempf; Rajeev Koodli Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions Hi Ajoy, > Alper, > In my previous reply to Rajeev, I explained why > MN is not required to know the L2 address of nAR > in case of srial link. Why this question again? The reason I cut-and-pasted the same question from an earlier message was to make sure that we were answering the same question with James.... > If you do > not agree, please comment on my previous > email. But now that you asked.... This is becoming more and more like a L2 handover mechanism, now that the IP stack of MN doesn't even know it changed its default router... Probably one can make this work, but making serial link assumptions is also limiting... alper > Regards, > Ajoy > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, July 30, 2002 6:12 PM > To: James Kempf; Rajeev Koodli > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > I think we need to include the complete question here: > > 1. How does the MN get the L2 address and IP address of the > new AR ? I see the following possibilities > a) PrRtAdv provides this > b) upon establishing a new link, the MN does RS and gets an RA > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > provides the necessary information ? Which L2 trigger today > provides such information? > > Does MN really get "L2 and IP address of the new AR"? > I see MN is aware of the L2 id of the Base Stations, but note > that this is not same as L2 id of AR(s) behind them. > > alper > > > > ----- Original Message ----- > From: "James Kempf" > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > ; > Sent: Tuesday, July 30, 2002 1:58 PM > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > Which L2 trigger today > > > > provides such information? > > > > > > I'm not aware of any... > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > Section > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and > > Section 12.25.3.8, "Handoff Indication". This version is a little old but > > probably not very far off from the current W-CDMA specification. > > > > In Section 11.7, the procedures for mobile controlled and network > controlled > > handover are described. In the mobile controlled case, the mobile sends a > layer > > 2 identifier to the current base station indicating the target base > station to > > which the mobile wants to hand over, and gets back a response indicating > whether > > handover is allowed or denied. In the network controlled case, the current > base > > station sends the same information to the mobile. (Note: "layer 3" in this > > specification actually refers to what from the IP viewpoint would be the > MAC > > layer, or layer 2). The network controlled case is used to manage power > and cell > > load, the mobile controlled case is used when the power level on the > mobile goes > > below the specified handoff point. > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP > layer, > > what W-CDMA already does at the MAC layer. Also in either case, the layer > 2 > > information should be sufficient to allow the base station to perform a > layer 3 > > handover without any over the air layer 3 signaling, provided the base > station > > has a way to map the target base station id to an IP address, using GAARD > or a > > preconfigured table. > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > the NBAP > > and RNSAP RAN protocols. > > > > I don't have access to an IS-2000 specification at the moment, but I'm > working > > on getting the same information. Other wireless link layers must provide > this > > information in some form, either before handover, as with the cellular > > protocols, or afterwards, as with 802.11. Barring make before break, > without > > some information at layer 2 about where the mobile is going, it is simply > > impossible for the link to get switched, and, without a link, it is not > possible > > to do IP. If the layer 2 protocol supports real make before break (not > soft > > handover), none of the fast handover protocols are necessary, since the > mobile > > can do RS/RA on the forward link while receiving its traffic on the > backward > > one. > > > > jak > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > you care > > to check it out.) > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 22:13:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24221 for ; Wed, 31 Jul 2002 22:13:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23717; Wed, 31 Jul 2002 20:13:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01897; Wed, 31 Jul 2002 19:13:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g712CUoN020995 for ; Wed, 31 Jul 2002 19:12:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g712CUi4020994 for mobile-ip-dist; Wed, 31 Jul 2002 19:12:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g712CRoN020987 for ; Wed, 31 Jul 2002 19:12:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01123 for ; Wed, 31 Jul 2002 19:12:32 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29548 for ; Wed, 31 Jul 2002 20:12:32 -0600 (MDT) Message-ID: <008001c23900$aab35d60$a86015ac@T23KEMPF> From: "James Kempf" To: Subject: Fw: [mobile-ip] Fast Handover draft: proposed revisions Date: Wed, 31 Jul 2002 19:10:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Which L2 trigger today > > provides such information? > > I'm not aware of any... > I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", Section 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and Section 12.25.3.8, "Handoff Indication". This version is a little old but probably not very far off from the current W-CDMA specification. In Section 11.7, the procedures for mobile controlled and network controlled handover are described. In the mobile controlled case, the mobile sends a layer 2 identifier to the current base station indicating the target base station to which the mobile wants to hand over, and gets back a response indicating whether handover is allowed or denied. In the network controlled case, the current base station sends the same information to the mobile. (Note: "layer 3" in the specification text actually refers to what from the IP viewpoint would be the MAC layer, or layer 2). The network controlled case is used to manage power and cell load, the mobile controlled case is used when the power level on the mobile goes below the specified handoff point. In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP layer, what W-CDMA already does at the MAC layer. Also in either case, the layer 2 information should be sufficient to allow the base station to perform a layer 3 handover without any over the air layer 3 signaling, provided the base station has a way to map the target base station id to an IP address, using Seamoby CARD protocol or a preconfigured table. Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under the NBAP and RNSAP RAN protocols, so this protocol is not seen by the GPRS IP layer. This is, of course, just one example. Can you explain how a wireless protocol would switch the link without providing either the old access point with a link layer identifier of the new or vice versa? Can you supply an example of such a protocol? An exception is make before break. If the layer 2 protocol supports real make before break (not soft handover) like flash OFDM does, none of the fast handover protocols are necessary, since the mobile can do RS/RA on the forward link while receiving its traffic on the backward one. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jul 31 22:16:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24268 for ; Wed, 31 Jul 2002 22:16:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26599; Wed, 31 Jul 2002 19:15:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01950; Wed, 31 Jul 2002 19:15:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g712EeoN021039 for ; Wed, 31 Jul 2002 19:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g712EeiX021038 for mobile-ip-dist; Wed, 31 Jul 2002 19:14:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g712EaoN021028 for ; Wed, 31 Jul 2002 19:14:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02187 for ; Wed, 31 Jul 2002 19:14:41 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22851 for ; Wed, 31 Jul 2002 20:14:40 -0600 (MDT) Message-ID: <008a01c23900$e91e5e60$a86015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Singh Ajoy-ASINGH1" Cc: "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: <3D483F3F.318DE7D4@iprg.nokia.com> Subject: [mobile-ip] Re: Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Wed, 31 Jul 2002 19:12:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > So, my suggestion is that the base protocol > > defines the messages necessary to work on all links > > while it also allows for scenarios such as yours. This > > does not mean that you remove the message from > > the spec. Do you agree ? > > > > AJOY-> I agree with this if you make PrRTAdv as > > an optional message. > > This question is for the WG to decide. What do others > think ? Should we make PrRtAdv an optional message ? It should be optional. > Interop implications ? > We have worked out the necessary interoperability in our implementation of draft 04. We can provide you with the necessary text. jak